|
This almost makes me consider redesigning the modules using %Subst on the variables, rather than BASED data structs. The fields I am sending are 140 Alpha, non-varying. It would make the coding a bit more difficult to write and test, but it sounds like there might be a performance issue. The other thing I am having to do is eval the pointer to the parameter in the C specs, because the compiler doesn't like D pReportLine S * Inz(%Addr(ReportLine)) Even with ReportLine being a parameter passed by Value. So this means that, in addition to moving 140 bytes each module call, I am having to eval a pointer every call also. On Thu, 13 Jan 2005 17:37:29 -0500, Barbara Morris <bmorris@xxxxxxxxxx> wrote: > Jon Paris wrote: > > > > Which is exactly why keeping one pointer per parm and loading it during the > > initialization phase is a good trade off! > > > > Barbara can tell us for sure, if this is true for RPG IV but I'd be > > surprised if it wasn't. > > > > Actually I can't tell for sure. The RPG compiler is just an > intermediate stage in the actual compile. > > The RPG compiler doesn't generate code to load addresses during > initialization and save them in pointers. It generates code to load > addresses as it needs them. But I imagine the optimizating translator > is probably able to do some wizardry with address loading. > > Regarding passing string parameters by value or by const: if you have > varying length parameters, it is almost always better to pass them by > const and copy them to a temp within the procedure (if you need to). > The copy within the procedure will only have to copy the current length > of the varying parameter. > > A thought experiment: > > To pass a string parameter, there are a few of places that data is > copied: > 1. Converting from the passed parameter to a temporary, if the passed > parameter does not match exactly. If the prototyped parameter is > varying length, only the length of the passed parameter has to be > copied. If the prototyped parameter is fixed length, blank padding may > also be required. > 2. Passing the parameter. This is either setting the 16-byte pointer or > copying the entire variable/temporary; if it's a varying length > temporary, the whole temporary must be copied, not just the current > length. > 3. Copying within the procedure if you pass CONST and need to modify it > or take its address. > > Consider the case of passing an x-byte-long parameter (varying or fixed, > doesn't matter) to a FIXED/VARYING 32767 parm, VALUE or CONST, where the > procedure needs to be able to change it. > > Fixed-VALUE | Fixed-CONST | Varying-VALUE | > Varying-CONST > > ---------------+----------------+----------------+---------------- > 1. Conversion x | x | x | x > 2. Passing 32767 | 16 | 32769 | > 16 > 3. Copying 0 | 32767 | 0 | x > > ---------------+----------------+----------------+---------------- > Total x + 32767 | x + 32783 | x + 32769 | > 2x + 16 > > For a few values of x: > x = 1 32768 32784 32770 > 18 > x = 10 32777 32793 32779 > 36 > x = 32766 65533 65549 65535 > 65548 > > If you don't need to modify/%addr within the procedure: > x = 1 32768 17 32770 > 17 > x = 10 32777 26 32779 > 26 > x = 32766 65533 32782 65535 > 32782 > > I don't know if performance tests would show results that conform to > this; this is just a thought-experiment. > > -- > This is the RPG programming on the AS400 / iSeries (RPG400-L) mailing list > To post a message email: RPG400-L@xxxxxxxxxxxx > To subscribe, unsubscribe, or change list options, > visit: http://lists.midrange.com/mailman/listinfo/rpg400-l > or email: RPG400-L-request@xxxxxxxxxxxx > Before posting, please take a moment to review the archives > at http://archive.midrange.com/rpg400-l. > > -- "Enter any 11-digit prime number to continue..."
As an Amazon Associate we earn from qualifying purchases.
This mailing list archive is Copyright 1997-2024 by midrange.com and David Gibbs as a compilation work. Use of the archive is restricted to research of a business or technical nature. Any other uses are prohibited. Full details are available on our policy page. If you have questions about this, please contact [javascript protected email address].
Operating expenses for this site are earned using the Amazon Associate program and Google Adsense.