Tony, The access registers are defined in the F8SA format for consistency with the F7SA format. It is not intended that a program allocate a 288-byte save area and save the access registers starting at x'90'. The intent of F8SA is that a 64-bit program that is passed only a 72-byte save area will use F8SA format if it needs to call a program that needs a 216-byte save area so that it can save the access registers in F7SA format.
Yes, it is true that you can learn something by looking at the second word in a save area. You can also be mislead by what you see there. Your program should not attempt to do that. If your program is linked as AMODE(64), and if it was invoked by ATTACH, LINK, XCTL, or SYNCH, R15 does not contain the entry point address, and you will not be able to examine the second word without altering at least one register. I had many of the same questions that you have 12 years ago and had an extensive email conversation with Peter Relson over the course of several months. Peter rewrote chapter 2 of the MVS Assembler Services Guide for release 1.12 to make it clearer. -- Tom Marchant On Wed, 26 Jan 2022 10:04:42 -0500, Tony Thigpen <t...@vse2pdf.com> wrote: >Tom, > >Sorry, just trying to get this correct. > >First a basic question on F8SA. The AR-regs at offset x'90', are they >AR-regs stored by B or by C? > >Second, I want to ask about your last two paragraphs. > >If B received a 72-byte area and needs to save either 64bit or aregs, it >will need to create either a F5SA and F8SA area. Under these conditions, >B *must* put 'F5SA' and 'F8SA' in the new save area as B has utilized >the tail end of the new save area for the high-halfs. So, when C is >called, it follows that C knows 'for sure' that when it sees the 'F5SA' >and 'F8SA' literals, then it can safely store all it's regs as >double-words starting at offset 8. Is that not true? > >In fact, if 'C' sees any of the know literals at offset 4, it knows that >the caller placed a back-pointer at offset x'80', therefore it knows >that the length of the save area is at least long enough to store all >the regs as double-words starting at offset 8. Is that not also true? > >And, if 'C' sees a positive and even fullword at offset 4, then the only >safe option is to only save the low-half of the regs at offset 8 >because, most likely, it is just an old save are? > >Tony Thigpen > >Tom Marchant wrote on 1/26/22 9:30 AM: >> 1) B's save area is the save area obtained by program B. While B is running, >> B's save area address is in register 13. Any program (or system service that >> requires it) that is called by B will use that save area to save the >> registers upon entry to that program, so that it can restore those registers >> before returning to B. Typically, the area obtained will also contain data >> areas that are used by B and addressed using R13. The first part of that >> storage is B's register save area. >> >> 2) B needs to save the address that was in register 13 at the time B was >> called. That is, the save area owned by the program that called B. When B is >> ready to return to its caller, it loads R13 with the value that it had when >> B was entered. Then it can restore the rest of the registers from the save >> area owned by the program that called B, the one that B used to save its >> caller's registers. >> >> You will notice that the save area does not include a space to save register >> 13. Instead, the newly obtained save area contains the address of the >> previous save area. For a standard save area (originally only called a "Save >> area") it is the second word of the save area. It is a requirement that each >> save area be chained to the higher level save area so that, as each program >> returns to its caller, it can find the previous save area. It is also >> recommended that each save area be chained to the next save area. >> >> For the newer save area formats, the back chain pointer is at offset X'80', >> and it is a doubleword. In fact, a program cannot allocate its save area >> above the bar unless it knows that it will only call programs that will >> receive control in amode 64. >> >> Since the second word of the newer save area formats is not needed for the >> back chain pointer, it seemed like a good idea for the called program to use >> that word to signify the format that it used to save its caller's registers. >> That information is generally not needed by the program when it restores its >> callers registers, but it is helpful to someone who is looking at a dump. >> If the program has multiple entry points as Peter suggested, one that only >> uses a 72-byte save area and one that uses a 144-byte save area, the program >> may need to use the information about how the registers were saves when it >> returns to its caller. >> >> A program that uses the high halves of the registers, but is only passed a >> 72-byte save area has to save the high halves somewhere, but they cannot be >> saved in the caller's save area. That's why F5SA and F8SA are defined. They >> provide space after the save area that will be used by the programs that it >> calls to save the high halves. >> >> Yes, when a program is entered, it can see the value that is at offset 4 >> when it is entered, but that value does not contain information that is >> useful to it. The value at offset 4 does not describe the save area that >> contains it. It describes the format of the previous save area. For example, >> I can write a program that does not use the high half of any register, but >> that will call programs that require a 144-byte save area. I will then save >> my callers in standard, 72-byte format, allocate a 144-byte save area, and >> put the address of the caller's save area in offset 4.
