|
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-2025 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.