The part that still 'bugs me' about all the explanations, is the
statement that the tag does not tell you *anything* about how the area
'was used' or even 'can be used'.
It seems that, for the most part, the literal can tell you *some
things*, because you know how the caller said he was storing some stuff
in the save area. And, because he used a spot, then you know the area is
at least as long as the start of the bytes he said he used.
From this, it seems:
If one of the literals are present, then we 'should' know the minimum
length of this save area because:
a) If it's FxSA, then the forward/backward pointers are at x80-x8F,
thus we can safety STMG R14,R12,8(R13) because that area is before the
forward/backward pointers. We also know that we can store a new forward
pointer at x88.
b) If it's F4SA or F5SA, then it's longer than x90, but we can't use
and don't care about anything after x7F because the caller is using (and
thus owns) everything from x80 on.
c) If it's F7SA or F8SA, then it's longer than xCB because the caller
used xCC-xD3 for storing AR13 and the ASC. It maybe longer than xD8, but
we can't use and don't care about anything after xD8 because the caller
is using (and thus owns) everything from xD8 on. Because he used xCC and
on, we know that we should be able to store ARs in x90-xCB [STAM
AR14,AR12,144(R13)].
Of course, if the caller defines a 144 byte save area, but then sticks
in a F7SA tag, then all bets are off, but this is really a programming
failure in the caller. He has said that he has used xCC-XD3 for storing
his callers ARs, but he lied.
So, *WHY* can't we make these assumptions about a labeled save area?????
Tony Thigpen
Schmitt, Michael wrote on 1/31/22 1:42 PM:
I know we've beaten this to death, but let me try and explain why this is so
hard to get.
The manual says that to save high halves when provided a 72-byte save area, you
can use format 5 (F5SA), and it defines what that save area looks like.
But does it look like that? Maybe, maybe not.
Clearly some parts of it will look like as documented: the FSSA literal, the
64-bit backchain, and the area in which you are saving the calling program's
register high halves.
What the manual doesn't explain is that the rest of the F5SA *might* be as
documented, such as if you call a subprogram that is expecting a 144 byte
Format 4 save area (F4SA) and uses the F5SA to store the 64 bit registers. But,
as explained in this email thread, if you call a program that *does not know
for a fact* that it is receiving a 144-byte or greater save area, then that
program will treat the F5SA area as a 72-byte save area, and thus the layout
will NOT be as it is documented.
When I first read the manual, I thought that made no sense at all, and guessed
that maybe I was supposed to create a chain like this:
Caller 72-byte -> my F5SA -> my new 72-byte > called subprogram
i.e. I'd create 2 save areas, not one. Because that was the only way there
seemed to be to have the save areas match their documented layouts, as well as
the only way to maintain a correct forward pointer chain. (That's another thing
I don't think is documented in the manual: that the forward chain may not be
traversable.)
Posters in this thread have said that the caller just provides the save area
SPACE but the callee determines the layout. That's not strictly true either,
since the caller is definitely determining the format and location of the back
chain pointer.
The other thing that makes it hard to understand is that it seems like for
amode 31 programs, there's few cases where you can actually save the 64-bit
registers in one of the 64-bit formats (F4SA, F7SA, etc.). The fundamental
problem is that you can't really know the size of the save area provided to you.
Posters have said that you just need to document your interface requirements,
and MAKE callers provide a larger save area. But that's not practical. I can't
make LE call me with anything but 72 bytes. It seems like the only use for the
larger save areas in amode 31 is if you are in complete control of both the
calling programs (to make them provide a larger save area) and the programs you
call (so that they know that YOU are providing a larger save area.)
The feeling I have is that the larger save areas were designed for amode 64 and
amode 31 was an afterthought.
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf
Of Mark Boonie
Sent: Saturday, January 29, 2022 4:14 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Saving Caller's 64-bit Registers
* The fact that is so confusing implies that the Assembler Services
Guide is not doing a good job of explaining it. It is hard to
understand because it defies expectations. What you *expect* is that
you have a value that describes the format of a structure, and by
implication, its length.
I can understand that someone might have that expectation before starting
to read about the interface, but once you read how it actually works, it
is up to you to drop your expectation and go with what the documentation
says. You might say to yourself, "Oh, that's the way it works? That
surprises me, but okay." You should not say to yourself, "That can't be
the way it works, so I'll proceed under the assumption the documentation
is incorrect."
Of course, if you feel that the Assembler Services Guide is hard to
understand because it's vague, self-contradictory, incomplete, etc., you
should definitely submit a Reader Comment Form.
- mb
