You are repeating your claim instead of explaining it. I understood, and
disagreed with, what you claimed the first few times. What I am asking for is
the basis of your claim that when the compiler puts the address of a dummy
variable in the plist it is not a call by value.
In fact, your definition would make call-by-value array parameters impossible
on machines like the B5000 and B6500.
________________________________________
From: IBM Mainframe Discussion List <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
Bernd Oppolzer <bernd.oppol...@t-online.de>
Sent: Monday, March 27, 2023 10:13 AM
To: IBM-MAIN@LISTSERV.UA.EDU
Subject: Re: ASM call by value
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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
> Bernd Oppolzer <bernd.oppol...@t-online.de>
> Sent: Monday, March 27, 2023 9:55 AM
> To: IBM-MAIN@LISTSERV.UA.EDU
> 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 <IBM-MAIN@LISTSERV.UA.EDU> on behalf of
>> Bernd Oppolzer <bernd.oppol...@t-online.de>
>> Sent: Monday, March 27, 2023 7:10 AM
>> To: IBM-MAIN@LISTSERV.UA.EDU
>> 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 lists...@listserv.ua.edu with the message: INFO IBM-MAIN
>
> ----------------------------------------------------------------------
> For IBM-MAIN subscribe / signoff / archive access instructions,
> send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
----------------------------------------------------------------------
For IBM-MAIN subscribe / signoff / archive access instructions,
send email to lists...@listserv.ua.edu with the message: INFO IBM-MAIN
