Re: Service Program Argument Optimization

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.