As someone who has written a fair number of C++-callable z/OS assembler
routines I can assure you that even though it is call-by-value, the callee's
entry R1 points to a list of addresses. Here is working code in assembler that
picks up an integer (R10 is the entry R1 and PARM2 EQU 4).
L R2,PARM2(,R10) Address of Length in R2
L R0,0(,R2) Length in R0
Here's the declaration of the function in C++
extern "OS" { void FREEMAIN(void *address, const unsigned int size); }
(Which, BTW, I guess answers my out-loud musing. Even though it is conceptually
call-by-value, the address of (a copy of, presumably) the packed field is
passed to printf().
In the assembler routine, call by value and call by reference (& notation) look
the same. The only visible difference I know of is whether the list off of R1
points to the variable or a copy of the variable.
Charles
-----Original Message-----
From: IBM Mainframe Discussion List [mailto:[email protected]] On Behalf
Of Bernd Oppolzer
Sent: Wednesday, April 26, 2017 3:20 PM
To: [email protected]
Subject: Re: Can XLC printf() take "%D(*,*)"?
Well, from a technical point of view,
languages like PL/1 (and Fortran, for example), which in their classical form
only supported call by reference, put only addresses in the reg 1 addressed
so-called parameter (address) list. (reg 1 points at the start of a list of
parameter addresses, so that the called routine can access the arguments
specified by the caller on the call statement and maybe change them).
Some additional remarks regarding PL/1: PL/1 often does not point to the
arguments directly from the address in the reg 1 address list, but instead to
descriptor structures, which hold type information about the parameter and a
secondary pointer to the argument, so things are real complicated with PL/1.
And: modern PL/1 supports BYVALUE, too; not only BYREFERENCE.
And NODESCRIPTOR, BTW.
With call by value (which is the only possible parameter mechanism in C), not
addresses but values are put into the reg 1 parameter list, which is not an
address list any more, but a list of values (which can be pointers, of course).
But the values can also be double floats, decimals and even structures, which
all can be greater than 4 bytes. So the old rule that the length of the
parameter list determines the number of parameters (parameter count multiplied
by 4) holds no longer.
The problem that by value parameters are larger than 4 bytes (larger than
addresses) is not new with decimal values; it is already a problem with double
float value parameters (it was present from the beginning of C by value
parameter passing).
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
