What is important to me at least: a parameter passing mechanism where
addresses are passed
and the value on the caller's side cannot be altered (because it has
been copied before, like in the
DUMMY argument mechanism of PL/1, for example) it NOT call by value.
You cannot call a true BYVALUE module or function by using such a
parameter passing mechanism.
That is: it is not only important that the caller's variable is not
altered;
it is also important that VALUEs are passed, not addressed. Otherwise
you have some sort of
"restricted" call by reference, which is not the same as call by value.
You are right, of course, that Reg 1 and DSA etc. are details of the
implementation,
only mentioned here to clarify the idea.
Kind regards
Bernd
Am 27.03.2023 um 14:25 schrieb Seymour J Metz:
There's more than one implementation; they all <crosses fingers> enforce the
semantics. Again, what call by value is all about is that the caller's variable in
not altered, regardless of how the compiler enforces that. The whole shtick with R1
and DSA is not part of the semantics.
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on behalf of Bernd
Oppolzer <[email protected]>
Sent: Monday, March 27, 2023 7:10 AM
To: [email protected]
Subject: Re: ASM call by value
Implementation enforces semantics in this case ...
The C implementation (on z/OS at least, but IMO on other platforms as
well) builts a reg1 parameter list
and puts the "value parms" there. With C on z/OS, the reg1 parameter
list resides on the "stack", which
is addressed by reg 13 in the caller's DSA, so that the whole process
remains reentrant.
Then the called prog can, if it wants, change the passed values, which
are in fact local variables,
as seen be the called prog. But nothing is changed from the perspective
of the caller.
This is what call by value is about.
The ASSEMBLER call macro supports this, but only for integer parms, and
not for parameter lists which
dont reside in the caller's CSECT. So we have two issues here:
- no "larger" data types supported
- no support for the reentrant case
HTH,
kind regards
Bernd
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
