A positive and even value at offset 4 must be a multiple of 4 or it is invalid.
-- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Wednesday, January 26, 2022 10:04 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Saving Caller's 64-bit Registers (was "...Regsiters") 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. > > -- > Tom Marchant > > On Tue, 25 Jan 2022 21:40:48 -0500, Tony Thigpen <t...@vse2pdf.com> wrote: > >> Tom, >> >> Some issues that make this whole subject confusing. >> >> 1) What is "B's save area"? Is it the the save area used by B when B >> receives control (was allocated by A), or is it the save area allocated >> by B and used by C when C receives control? (Defining 'used' by who uses >> the front part of the save area, such as by a STM 14,12,12(13).) >> [It sounds like the first possibility.] >> >> 2) If reads as if a newly acquired save area is partially propagated by >> the program that acquired the save area and partially by the program >> that is called with R13 pointing to this newly acquired area. And that >> the allocater/caller is actually setting the word 1 literal, the back >> pointer, and maybe filling the end of the area with the high-halfs of >> the registers from when it received control. Yet, the front registers >> are left un-used and will be filled in by the next program to be called. >> If this is the case, then the next program being called will actually >> see the word 1 literal when it receives control. Am I understanding this >> correctly? >> >> >> Tony Thigpen
