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

Follow-Ups:
Replies:

Follow On AppleNews
Return to Archive home page | Return to MIDRANGE.COM home page

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.