All you really need to do a "call by value" in ASM is a special Call
macro (say maybe VCALL) that allocates "hidden" space for a copy of the
variable value, copies the original variable, and somehow passes that to
the called program, and a programming rule that says you only invoke
that particular subroutine using the intended interface. You can even
add a special Subroutine entry macro and employ some "tricks" so that
attempts to reference the subroutine name by an ordinary Call macro or
direct reference will fail.
If your only allowed interfaces to the subroutine allows it so see the
value of a variable passed by the caller but not change the
corresponding variable known to the caller, then that IS call by value,
no matter what the underlying implementation in low-level code.
Native machine instructions and standard subroutine linkages may only
support call by reference, but the advantage of a macro assembler is
that you can extend the language through macros and create an enhanced
language that can do so much more. Some notable examples of this are
various implementations using macros that allow use of
structured-programming control constructs and recursive procedures with
dynamic variable storage in Assembly programs.
Joel C Ewing
On 3/27/23 09:13, Bernd Oppolzer wrote:
DCL X BIN FIXED (31);
CALL SUB ((X));
SUB: PROC (P);
DCL P BIN FIXED (31);
END SUB;
The statement CALL SUB ((X));
creates a dummy argument for X (that is, a copy of variable X).
The CALL statement passes THE ADDRESS of that copy to the SUB subroutine.
This is NOT call by value.
The subroutine cannot change X, because it gets the address of the
copy of X
and not the address of X. That is:
call by reference of a dummy argument
and not
call by value
The types of X and P may be different; if so, the dummy argument gets
the type of P.
In this case, no parantheses are required (but a warning message is
issued, if there are
no parentheses). But the mechanism is the same, regardless if the
types match (with parantheses)
or if the types don't match (without parantheses). Only in the case
when the types match and
there are no parantheses, you have a real call by reference where the
subroutine can change
the value of the caller.
This is PL/1 ... other languages don't behave this way. With other
languages, you will get a
problem at runtime, if the types don't match.
Kind regards
Bernd
Am 27.03.2023 um 16:03 schrieb Seymour J Metz:
Why is it important to you that an address not be passed and why do
you believe that a PL/I dummy variable means that the argument was
not passed by value? Languages specify black box behavior, not how
you enforce that behavior.
________________________________________
From: IBM Mainframe Discussion List <[email protected]> on
behalf of Bernd Oppolzer <[email protected]>
Sent: Monday, March 27, 2023 9:55 AM
To: [email protected]
Subject: Re: ASM call by value
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
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
--
Joel C. Ewing
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to [email protected] with the message: INFO IBM-MAIN
