If I have understood this thread at all, then a slight correction to you last sentence is in order:
. . . each save area indicates how the BACKCHAIN POINTER WAS (not "registers were") stored by the program that created that area. When you create a save area, it is for your callees to use to save. All you can tell them is where YOU stored the backchain, not necessarily where nor how many registers they can save in it. HTH Peter -----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Schmitt, Michael Sent: Monday, January 31, 2022 4:38 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Registers I will recklessly attempt to demonstrate the knowledge acquired from this thread by confidently stating... No, the only thing you know is that if word1 is FxSA something then that save area is at least 144 bytes. For example: I'm program B. I somehow know that Program A gave me a 216 byte save area (F7SA). (Perhaps because I wrote program A). Since I know, somehow, that I was given a 216 save area, I can use it to store the 64 byte registers as well as the access registers. Now I create a save area. I feel like creating it as a 144-byte area (F4SA). I put F7SA in word1 (not F4SA!) because I saved the caller's registers in the caller provided save area in that format. Now I call a program C. Program C sees F7SA in the area it is provided, but it can NOT use it to store access registers. It is only 144 bytes. This is not a programming failure on my part, I am following the save area standards precisely. (The key here is to realize that the only purpose of the FxSA string is so that backchain can be followed; each save area indicates how the registers were stored by the program that created that area.) -----Original Message----- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of Tony Thigpen Sent: Monday, January 31, 2022 3:19 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Registers 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 -- This message and any attachments are intended only for the use of the addressee and may contain information that is privileged and confidential. If the reader of the message is not the intended recipient or an authorized representative of the intended recipient, you are hereby notified that any dissemination of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by e-mail and delete the message and any attachments from your system.
