I'm having trouble making reconciling the text and sample code in the manuals. 
What does the chain look like if B and C expect 72-byte save areas and both use 
the upper words of general registers?


--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3

________________________________________
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf 
of Peter Relson [rel...@us.ibm.com]
Sent: Tuesday, January 25, 2022 9:35 AM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters")

Shmuel wrote
<snip>
...I don't understand the issue for running the forward chain, assuming
that all called routines have set the forward pointer, other than
detecting the end of the chain.

If +4 (word 2) is on a word boundary then the save area is either unused
or is 72 bytes. If word 2 is FxSA (C6FxE2C1) then it is a 144-byte save
area; anything else and it is invalid.
</snip>

We have been through this so many times. I don't understand why.

The value in the 2nd word has only a peripheral relationship to the size
of the save area.
It states how the CALLED program saved the CALLER's registers.

For example: if the called program saves the caller's register low halves
only, in the caller-provided 72-byte savearea, then the 2nd word of the
area pointed to by the called program's reg 13 will have an even value.
But it is unknowable whether the called program is itself using a 72-byte
savearea, a 144-byte savearea, or something larger. And thus it is
unknowable whether, looking forward, you need to use the word at +8 or the
doubleword at +136 to locate the "next" savearea to understand how that
savearea's owner saved its caller's registers.

And the answer to Dave Clark's continued asking of the same question
remains the same: the called program cannot "tell" how much storage the
caller provided unless the interface provides a way for the caller to do
so.  And there really is no need to do so. Just as you, as an interface
provider, might choose to provide a separate entry point for a caller in
AMODE 64 than for one in AMODE 31 to avoid complications, you might
provide a separate entry point for a caller passing a 72-byte savearea
than one passing a 144-byte savearea. Or you might just always assume that
the caller provides a 72-byte saverea, save the low halves there, and (if
needed) save the high halves in an area that you obtain upon entry and
identify that you have done so in the 2nd word.

Peter Relson
z/OS Core Technology Design

Reply via email to