Re: Base-less macros
Shmuel wrote: Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytes long; Not true. An example is the longest-existing. That's where the creator of the save area (the target module) identifies that it saved the caller's regs on the linkage stack so placed 'F1SA' at +4. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? Within your application, maybe, as long as it doesn't use F1SA. If it uses F1SA there is no way of knowing if the forward chain is 4 bytes at +8 or 8 bytes at +136.. Once you get into the system, linkage conventions are not necessarily followed (and additional ones are used), for performance and integrity reasons. Peter Relson z/OS Core Technology Design
Re: Base-less macros
> In that scenario, offset 4 of Xs save area will no longer contain > FnSA, and can thus be identified as the forward pointer of a 72-bytesave area. The point that several recent posts have been trying to make is that the contents of word 1 indicate how the registers were saved in the *previous* save area, not this one. You'd have to find the save area *after* X's save area to determine the format of X's save area, and the finding of the next save area is problematic without already knowing the format of X's save area. - mb
Re: Base-less macros
In that scenario, offset 4 of Xs save area will no longer contain FnSA, and can thus be identified as the forward pointer of a 72-byte save area. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Boonie [boo...@us.ibm.com] Sent: Wednesday, December 1, 2021 2:09 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros > The one case where there could be an issue is if the > routine calls both code expecting a 72-byte save area and code > calling a 144-byte area. > > If the linkage conventions are followed, under what circumstances > would you be unable to follow the forward chain with a little bit of work? Didn't you just identify the circumstances? Suppose routine X calls both routine Y and routine Z with a 144-byte save area: - Routine X calls routine Y which is going to use the high-order halves of some registers. Routine Y updates routine X's save area with the saved 64-bit registers and a pointer to routine Y's new save area in location 136. - Routine Y returns to routine X. - Routine X calls routine Z which is only going to use the low-order halves of the registers. Routine Z updates routine X's save area with the saved 32-bit registers and a pointer to routine Z's new save area in word 2. Before routine Z returns, the save area for routine X (the one pointed pointed to by the backward pointer from Z's current save area) has two forward pointers: one to the no longer valid save area for routine Y, and one to the valid save area for routine Z. Scanning forward doesn't allow you to tell which one is correct. Unless by "linkage conventions" you mean calling a routine with a save area that is only as large as that which is required, so that X would need two different save areas for calling Y and Z? - mb
Re: Base-less macros
> The one case where there could be an issue is if the > routine calls both code expecting a 72-byte save area and code > calling a 144-byte area. > > If the linkage conventions are followed, under what circumstances > would you be unable to follow the forward chain with a little bit of work? Didn't you just identify the circumstances? Suppose routine X calls both routine Y and routine Z with a 144-byte save area: - Routine X calls routine Y which is going to use the high-order halves of some registers. Routine Y updates routine X's save area with the saved 64-bit registers and a pointer to routine Y's new save area in location 136. - Routine Y returns to routine X. - Routine X calls routine Z which is only going to use the low-order halves of the registers. Routine Z updates routine X's save area with the saved 32-bit registers and a pointer to routine Z's new save area in word 2. Before routine Z returns, the save area for routine X (the one pointed pointed to by the backward pointer from Z's current save area) has two forward pointers: one to the no longer valid save area for routine Y, and one to the valid save area for routine Z. Scanning forward doesn't allow you to tell which one is correct. Unless by "linkage conventions" you mean calling a routine with a save area that is only as large as that which is required, so that X would need two different save areas for calling Y and Z? - mb
Re: Base-less macros
My "Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions" took into account what Peter wrote. If the caller does not follow the conventions, all bets are off. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Wednesday, December 1, 2021 1:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Nope! Read what Peter wrote. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, December 1, 2021 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- 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: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Nope! Read what Peter wrote. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Wednesday, December 1, 2021 10:27 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- 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: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Assuming that the caller has initialized the save area and subsequently used it in accordance with IBM linkage conventions, offset 4-7 will contain 4 EBCDIC characters ending iin SA only if it is 144 bytest long; the forward link of a 72-byte save area should never be odd. The one case where there could be an issue is if the routine calls both code expecting a 72-byte save area and code calling a 144-byte area. If the linkage conventions are followed, under what circumstances would you be unable to follow the forward chain with a little bit of work? -- 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: Wednesday, December 1, 2021 10:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Thanks for the clarification. I seem to be a slow learner. > It's perfectly fine to use high halves in AMODE 31 People seem to conflate AMODE 64 with the usage of high halves. Writing in AMODE 64 is kind of a big deal (been there, etc.). Using the high halves for arithmetic and such is a piece of cake. > Having a unique entry point for each AMODE can be a good approach Seems like a perfect approach. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Wednesday, December 1, 2021 7:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Charles wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. This point has been made multiple times in this forum and in IBM-Main. And it's a reason why you can only predictably walk a save area chain backwards. You cannot walk it forwards (unless you know what conventions all the parties have employed). Shmuel wrote CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. Not true. +4 in the R13 passed to a routine does not indicate how long the save area is. No comparison can tell that. It is up to the caller to satisfy the linkage requirements, whatever they may be (parameters, save area, environment, etc). A called program may not function properly (may not even be able to detect it is not functioning properly) if that does not happen. Charles wrote > the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Yes, I think that it does make the problem go away. If you know that the caller will always provide 144 bytes, performance-aside, why not just use the 144-byte save area protocol and not worry about it? It's perfectly fine to save high halves in AMODE 31. It's perfectly fine to use high halves in AMODE 31. In many cases, a module that accepts entry in both AMODE 31 and AMODE 64 will choose to run in AMODE 64 (we might call that "CAP64") and thus need to save high halves regardless of the AMODE of the caller. But if you are stuck, for compatibility, with the "old (AMODE 31)" callers passing a 72-byte save area, things are more complicated. Having a unique entry point for each AMODE can be a good approach for such a case. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Fortunately at my shop, all subroutines that "participate" use the one entry macro so everyone is "playing by the rules". It is not up to the caller to establish the size of the RSA, just allocate enough space for some number of RSAs (for nested calls), usually 10-20 72 byte areas (that probably needs to change since that only allows 5-10 144 byte areas), All "top level" programs and some subroutines establish their own RSA (again, usually a stack). There is a legacy version of the same entry macro that is slowly being replaced which is a big reason why there is so much "trust but verify" code. Since I not only have to check to see if the current RSA points to a 64 bit (called from another 64 bit routine) or 31 bit (called from a 31 bit routine), I also need to set the eyecatcher in the RSA this routine will pass to subroutine(s) I call, I decided to keep the 4 character literal "inline" with a branch around. This adds 8 bytes to each entry and 4 bytes to each return macro but memory is cheap. Back in the last century (and a prior employer), I wrote a couple of programs that did a GETMAIN for each RSA needed. These were all batch, low utilization programs so the added overhead wasn't enough to worry about. With the current environment, that would be too much overhead so a largeish (32k) area allocated by the top level program is normally plenty of "stack room". *Mark* On Tue, Nov 30, 2021 at 1:48 PM Gary Weinhold wrote: > From what I understand that you are right. However OP Mark indicates > there is a convention at his shop which allows the calling program (the > presumed allocater of the save area) to indicate to the called program > how large the save area is by using the F4SA eyecatcher. It's a > convention at his shop, but it's no different in my mind from > conventions that use enqueues or Compare and Swap to control access to > code paths. They only work if everyone plays by the rules. > > On 2021-11-30 9:36 a.m., Charles Mills wrote: > > Ah! I have not been clear on the convention. As I read it now, the called > > program puts one of the FnSA strings in its *new* save area to indicate > how > > *it* previously stored the registers in its entry save area. > > > > So the OP's premise is incorrect. A program cannot learn the length or > > format of the incoming save area by examining it (although an FnSA string > > there would give you a clue of what the caller was up to in general). > > > > I am inferring that there is no way for a called program to determine > > programmatically the length or expected format of the incoming save > area. It > > must be agreed upon by the two programs, or phrasing it differently, the > > called program's save area expectations must be documented and respected > by > > the caller. > > > > Am I right, or off (pardon the pun) base? > > > > Charles > > > > > > > Gary Weinhold > Senior Application Architect > DATAKINETICS | Data Performance & Optimization > Phone:+1.613.523.5500 x216 > Email: weinh...@dkl.com > Visit us online at www.DKL.com > E-mail Notification: The information contained in this email and any > attachments is confidential and may be subject to copyright or other > intellectual property protection. If you are not the intended recipient, > you are not authorized to use or disclose this information, and we request > that you notify us by reply mail or telephone and delete the original > message from your mail system. > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto: > ASSEMBLER-LIST@LISTSERV.UGA.EDU] > > On Behalf Of Peter Relson > > Sent: Tuesday, November 30, 2021 5:39 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > Steve Smith wrote: > >> And there are other bizarre ways to return without > >> restoring R14, which is not actually required by documented conventions. > > Only restoring of AR14 and the high half of R14 are required (for > > non-AMODE 64 cases), in general. > > (Although I would guess that there are many violations of preserving the > > high half of R14). > > Some interfaces might define that they preserve R14 completely. Most do > > not. > > > > Mark Hammack wrote > >> I have a macro that switches between a regular (24/31 bit style) > >> save area and an extended (64 bit "F4SA") save area. > > What do you mean by "switches between"? It is fine to use a different > > style than the style your caller was using (as long as the savearea > > provided is big enough to accommodate your needs), without having any > care > > about what was being used by your caller. The string at +4 identifies how > > you saved your caller's registers. > > > > Peter Relson > > z/OS Core Technology Design >
Re: Base-less macros
From what I understand that you are right. However OP Mark indicates there is a convention at his shop which allows the calling program (the presumed allocater of the save area) to indicate to the called program how large the save area is by using the F4SA eyecatcher. It's a convention at his shop, but it's no different in my mind from conventions that use enqueues or Compare and Swap to control access to code paths. They only work if everyone plays by the rules. On 2021-11-30 9:36 a.m., Charles Mills wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. So the OP's premise is incorrect. A program cannot learn the length or format of the incoming save area by examining it (although an FnSA string there would give you a clue of what the caller was up to in general). I am inferring that there is no way for a called program to determine programmatically the length or expected format of the incoming save area. It must be agreed upon by the two programs, or phrasing it differently, the called program's save area expectations must be documented and respected by the caller. Am I right, or off (pardon the pun) base? Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Tuesday, November 30, 2021 5:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Steve Smith wrote: And there are other bizarre ways to return without restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: Base-less macros
On Nov 30, 2021, at 11:51:40, Laddie Hanus wrote: > > How about all of that code written before 64 bit z. I had stuff as old as > 1985 still running in 2017. > The interface specifications should require 31-bit linkage conventions. That should have been explicit ni 1985 to preclude 24-bit. -- gil
Re: Base-less macros
From the conversation, I think this is an internal convention at their shop. They require the callers to put the eyecatcher in to indicate they created/reserved a 144-byte savearea. Callers that don't do that are probably some kind of legacy and can't be assumed to have a 144 byte save area. I gathered the macro was the glue code between various callers and the actual subroutines. On 2021-11-30 1:40 p.m., Paul Gilmartin wrote: On Nov 30, 2021, at 11:21:51, Mark Hammack wrote: If the caller only passes a 72 byte save area (rather than part of a larger save area stack) then I've got bigger problems than how to test and/or set c'F4SA' in the save area. :-) The code of the subroutine should cut the Gordian Knot; take a cue from "UNIX System... Callable Services" and provide dual entry points, e.g.: AMODE (BPX1OPN):31-bit AMODE (BPX4OPN):64-bit -- gil Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system.
Re: Base-less macros
How about all of that code written before 64 bit z. I had stuff as old as 1985 still running in 2017. Laddie Hanus Sent from whatever device I am using. > On Nov 30, 2021, at 12:22 PM, Mark Hammack wrote: > > If the caller only passes a 72 byte save area (rather than part of a larger > save area stack) then I've got bigger problems than how to test and/or set > c'F4SA' in the save area. :-) > > > *Mark* > > >> On Tue, Nov 30, 2021 at 12:14 PM Seymour J Metz wrote: >> >> You could certainly do a normal STM R14,R12,12(R13); 4(R13) is normally >> the back point for 24-bit linkage. >> >> The 72-byte SA only has 15 words left at offset 12; that's not enough for >> that STGM, so you need to test first. >> >> -- >> Shmuel (Seymour J.) Metz >> http://mason.gmu.edu/~smetz3 >> >> >> From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on >> behalf of Mark Hammack [mark.hamm...@gmail.com] >> Sent: Tuesday, November 30, 2021 12:43 PM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: Base-less macros >> >> Couldn't do a "normal" STM R14,R12,4(R13) since that would overlay the area >> to be checked. STGM 14,12,8(13) would probably work in most cases. Either >> the first 72 bytes will be rewritten with the STM or the data is already >> stored. The only issue I see is possibly debugging, trying to decipher the >> RSA chain to figure out what routine was called prior to the current >> routine (had to do that a couple of times). >> >> >> >> *Mark* >> >> >> On Tue, Nov 30, 2021 at 10:13 AM Charles Mills wrote: >> >>>> the caller must provide a large enough area to allow for the 144 byte >>> >>> Does that not make the problem go away? Simply automatically always save >>> the low order halves of the registers, and if the subroutine will be >>> altering the high halves, save those also. Done. The *caller* has no say >> in >>> the save area format. >>> >>> Charles >>> >>> >>> -Original Message- >>> From: IBM Mainframe Assembler List [mailto: >> ASSEMBLER-LIST@LISTSERV.UGA.EDU] >>> On Behalf Of Mark Hammack >>> Sent: Tuesday, November 30, 2021 7:54 AM >>> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >>> Subject: Re: Base-less macros >>> >>> In our case, the caller doesn't "know" whether the called subroutine is >>> base 31 or base 64. So it is up to the called subroutine to "figure out" >>> whether the caller used a 72 byte save area or a 144 byte save area. >>> Parameters to the macro set addressing mode, RSA size, etc. This allows >>> for a 31 bit module to call a 64 bit subroutine and vice versa. That's >>> what I really mean by "switches between". The one caveat is that the >>> caller must provide a large enough area to allow for the 144 byte area. >>> >>> Since some subroutines accept arguments in R0 and/or R1 (and >> unfortunately >>> assume other registers are pre-loaded) those can't be touched before >> being >>> saved. Likewise, if the routine is called from another 64 bit >> subroutine, >>> the high halves of registers are (potentially) in use. However, since >>> (currently) all of our programs run below the bar, using the high half of >>> R14 may be an option. I need to look into using a FPR or AR but the 4 >> byte >>> literal pool works for now. Storing R14 in 8(R13) is not a bad idea >>> either. >>> >>
Re: Base-less macros
On Nov 30, 2021, at 11:21:51, Mark Hammack wrote: > > If the caller only passes a 72 byte save area (rather than part of a larger > save area stack) then I've got bigger problems than how to test and/or set > c'F4SA' in the save area. :-) > The code of the subroutine should cut the Gordian Knot; take a cue from "UNIX System... Callable Services" and provide dual entry points, e.g.: AMODE (BPX1OPN):31-bit AMODE (BPX4OPN):64-bit -- gil
Re: Base-less macros
PL/I F and the OS PL/I "Optimizing" compiler certainly did. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Farley, Peter x23353 [0dc9d8785c29-dmarc-requ...@listserv.uga.edu] Sent: Tuesday, November 30, 2021 12:50 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros And IIRC in ancient days the PL1 runtime used to use word 1 of the RSA for its own purposes. Don’t know if LE and Enterprise PL1 (or Enterprise COBOL for that matter) continued that tradition or not. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 30, 2021 12:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I think it is one of those "better safe than sorry" things. If a prior subroutine call used this RSA in 31 bit mode, then 4(13) should be an address so the low order bit shouldn't be on (in theory). I remember a programmer using the first word of the RSA as temp storage...until some other subroutine (not in our control) either used it for some other reason. Not as bad as using the first 8 bits of an address for flags, but still a headache to correct. *Mark* On Tue, Nov 30, 2021 at 10:53 AM Seymour J Metz wrote: > Do you really need to test all four bytes? A test for 'SA' should be > enough. > > -- > Shmuel (Seymour J.) Metz > https://secure-web.cisco.com/1wByIrL2iO9P9S4db1cCVZXscFQOShonYtI1gJWgpwzr7CYH7vtTpGog3frTQmqikX6ZTLowl4IpW4Iw51hrCkrFYhlHiOwIGDNqo3a5iGtQ6rbHJFpuZdP8guWFzTdvmtt52rCKPUq6k6yBmmqXwFTWDsTq5SR3NoR668gVrK0VgjWnGE25ZJeiwaeBlV0Mpu_FRPt2eRSdo7R_z6VMXBf2aHvK2TnQFB3_P5NXIe_gya8NgtmgCz9Y45Lx1L02zkJDsPO86j_aScdWfditYe6M717aOzLYlV4-zCSbmmRMqf5NDM5b8GR9A0olHB3OQmIkVg-LcS2Ko4pllMt8YA7aAK1P5K4xyzVF7ehQvSuQIKe6Sy2Heg0M5R_QTK63qyvRWZehVa1hZlPKUDXvJovXV66pEcZrEsNcS5cW8DNn1gZQztbMGxpzDWMCRahhAVJOKpAVrwyuuR-36MVln_w/https%3A%2F%2Furldefense.com%2Fv3%2F__http%3A%2F%2Fmason.gmu.edu%2F%2Asmetz3__%3Bfg%21%21Ebr-cpP > eAnfNniQ8HSAI-g_K5b7VKg!fJ-ZGLII6ou2tbp7J5r5YQxS_lMe78f778iGHf8Xyncavn > D8-EgiZR1MVewdjWfyRDQ-iA$ > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on behalf of Mark Hammack [mark.hamm...@gmail.com] > Sent: Tuesday, November 30, 2021 10:53 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine > is base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This > allows for a 31 bit module to call a 64 bit subroutine and vice versa. > That's what I really mean by "switches between". The one caveat is > that the caller must provide a large enough area to allow for the 144 byte > area. > > Since some subroutines accept arguments in R0 and/or R1 (and > unfortunately assume other registers are pre-loaded) those can't be > touched before being saved. Likewise, if the routine is called from > another 64 bit subroutine, the high halves of registers are > (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half > of > R14 may be an option. I need to look into using a FPR or AR but the 4 > byte literal pool works for now. Storing R14 in 8(R13) is not a bad > idea either. > > Thanks! > > > > *Mark*
Re: Base-less macros
If the caller only passes a 72 byte save area (rather than part of a larger save area stack) then I've got bigger problems than how to test and/or set c'F4SA' in the save area. :-) *Mark* On Tue, Nov 30, 2021 at 12:14 PM Seymour J Metz wrote: > You could certainly do a normal STM R14,R12,12(R13); 4(R13) is normally > the back point for 24-bit linkage. > > The 72-byte SA only has 15 words left at offset 12; that's not enough for > that STGM, so you need to test first. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Mark Hammack [mark.hamm...@gmail.com] > Sent: Tuesday, November 30, 2021 12:43 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > Couldn't do a "normal" STM R14,R12,4(R13) since that would overlay the area > to be checked. STGM 14,12,8(13) would probably work in most cases. Either > the first 72 bytes will be rewritten with the STM or the data is already > stored. The only issue I see is possibly debugging, trying to decipher the > RSA chain to figure out what routine was called prior to the current > routine (had to do that a couple of times). > > > > *Mark* > > > On Tue, Nov 30, 2021 at 10:13 AM Charles Mills wrote: > > > > the caller must provide a large enough area to allow for the 144 byte > > > > Does that not make the problem go away? Simply automatically always save > > the low order halves of the registers, and if the subroutine will be > > altering the high halves, save those also. Done. The *caller* has no say > in > > the save area format. > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto: > ASSEMBLER-LIST@LISTSERV.UGA.EDU] > > On Behalf Of Mark Hammack > > Sent: Tuesday, November 30, 2021 7:54 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > In our case, the caller doesn't "know" whether the called subroutine is > > base 31 or base 64. So it is up to the called subroutine to "figure out" > > whether the caller used a 72 byte save area or a 144 byte save area. > > Parameters to the macro set addressing mode, RSA size, etc. This allows > > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > > what I really mean by "switches between". The one caveat is that the > > caller must provide a large enough area to allow for the 144 byte area. > > > > Since some subroutines accept arguments in R0 and/or R1 (and > unfortunately > > assume other registers are pre-loaded) those can't be touched before > being > > saved. Likewise, if the routine is called from another 64 bit > subroutine, > > the high halves of registers are (potentially) in use. However, since > > (currently) all of our programs run below the bar, using the high half of > > R14 may be an option. I need to look into using a FPR or AR but the 4 > byte > > literal pool works for now. Storing R14 in 8(R13) is not a bad idea > > either. > > >
Re: Base-less macros
ObDie Jungfrau von Orleans: "Against stupidity, the gods themselves battle in vain." If someone is violating the linkage conventions, then you're screwed regardless. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Hammack [mark.hamm...@gmail.com] Sent: Tuesday, November 30, 2021 12:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I think it is one of those "better safe than sorry" things. If a prior subroutine call used this RSA in 31 bit mode, then 4(13) should be an address so the low order bit shouldn't be on (in theory). I remember a programmer using the first word of the RSA as temp storage...until some other subroutine (not in our control) either used it for some other reason. Not as bad as using the first 8 bits of an address for flags, but still a headache to correct. *Mark* On Tue, Nov 30, 2021 at 10:53 AM Seymour J Metz wrote: > Do you really need to test all four bytes? A test for 'SA' should be > enough. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Mark Hammack [mark.hamm...@gmail.com] > Sent: Tuesday, November 30, 2021 10:53 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea > either. > > Thanks! > > > > *Mark* > > > On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: > > > Ah! I have not been clear on the convention. As I read it now, the called > > program puts one of the FnSA strings in its *new* save area to indicate > how > > *it* previously stored the registers in its entry save area. > > > > So the OP's premise is incorrect. A program cannot learn the length or > > format of the incoming save area by examining it (although an FnSA string > > there would give you a clue of what the caller was up to in general). > > > > I am inferring that there is no way for a called program to determine > > programmatically the length or expected format of the incoming save area. > > It > > must be agreed upon by the two programs, or phrasing it differently, the > > called program's save area expectations must be documented and respected > by > > the caller. > > > > Am I right, or off (pardon the pun) base? > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto: > ASSEMBLER-LIST@LISTSERV.UGA.EDU > > ] > > On Behalf Of Peter Relson > > Sent: Tuesday, November 30, 2021 5:39 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > Steve Smith wrote: > > >And there are other bizarre ways to return without > > >restoring R14, which is not actually required by documented conventions. > > > > Only restoring of AR14 and the high half of R14 are required (for > > non-AMODE 64 cases), in general. > > (Although I would guess that there are many violations of preserving the > > high half of R14). > > Some interfaces might define that they preserve R14 completely. Most do > > not. > > > > Mark Hammack wrote > > >I have a macro that switches between a regular (24/31 bit style) > > >save area and an extended (64 bit "F4SA") save area. > > > > What do you mean by "switches between"? It is fine to use a different > > style than the style your caller was using (as long as the savearea > > provided is big enough to accommodate your needs), without having any > care > > about what was being used by your caller. The string at +4 identifies how > > you saved your caller's registers. > > > > Peter Relson > > z/OS Core Technology Design > > >
Re: Base-less macros
"STKLANG - Language word" -- https://www.ibm.com/docs/en/zos/2.3.0?topic=conventions-standard-save-area Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Tuesday, November 30, 2021 10:10 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 30, 2021, at 11:02:48, Charles Mills wrote: > > Yes, LE uses word 1 (or word 0 if you will). > Might that be for a static frame pointer, which must be provided For any language supporting nested procedure declarations? > -Original Message- > From: Farley, Peter x23353 > Sent: Tuesday, November 30, 2021 9:51 AM > > And IIRC in ancient days the PL1 runtime used to use word 1 of the RSA for > its own purposes. Don’t know if LE and Enterprise PL1 (or Enterprise COBOL > for that matter) continued that tradition or not. -- gil
Re: Base-less macros
You could certainly do a normal STM R14,R12,12(R13); 4(R13) is normally the back point for 24-bit linkage. The 72-byte SA only has 15 words left at offset 12; that's not enough for that STGM, so you need to test first. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Hammack [mark.hamm...@gmail.com] Sent: Tuesday, November 30, 2021 12:43 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Couldn't do a "normal" STM R14,R12,4(R13) since that would overlay the area to be checked. STGM 14,12,8(13) would probably work in most cases. Either the first 72 bytes will be rewritten with the STM or the data is already stored. The only issue I see is possibly debugging, trying to decipher the RSA chain to figure out what routine was called prior to the current routine (had to do that a couple of times). *Mark* On Tue, Nov 30, 2021 at 10:13 AM Charles Mills wrote: > > the caller must provide a large enough area to allow for the 144 byte > > Does that not make the problem go away? Simply automatically always save > the low order halves of the registers, and if the subroutine will be > altering the high halves, save those also. Done. The *caller* has no say in > the save area format. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Mark Hammack > Sent: Tuesday, November 30, 2021 7:54 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea > either. >
Re: Base-less macros
Although debuggers and post-mortem traces will not love you for it, right? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen Sent: Tuesday, November 30, 2021 9:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros You don't have to always save ALL the registers. No matter what the caller provides, you can always do a STMG 14,4,8(13) STG 13,64(13) because it fits in the standard 72 byte minimal save area. After the STMG, you can then decide if the caller passed a larger area or you can just acquire a larger save area yourself and store everything "correctly" in it. Of course, if your routine can be written to only use R13-R4, you can just do your work and return back. After processing is done, you can then restore everything from the larger area, then restore 14-5 from the original save are, then return back. (Just don't use the RETURN macro.) Tony Thigpen Mark Hammack wrote on 11/30/21 10:53 AM: > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea either. > > Thanks! > > > > *Mark* > > > On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: > >> Ah! I have not been clear on the convention. As I read it now, the called >> program puts one of the FnSA strings in its *new* save area to indicate how >> *it* previously stored the registers in its entry save area. >> >> So the OP's premise is incorrect. A program cannot learn the length or >> format of the incoming save area by examining it (although an FnSA string >> there would give you a clue of what the caller was up to in general). >> >> I am inferring that there is no way for a called program to determine >> programmatically the length or expected format of the incoming save area. >> It >> must be agreed upon by the two programs, or phrasing it differently, the >> called program's save area expectations must be documented and respected by >> the caller. >> >> Am I right, or off (pardon the pun) base? >> >> Charles >> >> >> -----Original Message- >> From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU >> ] >> On Behalf Of Peter Relson >> Sent: Tuesday, November 30, 2021 5:39 AM >> To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >> Subject: Re: Base-less macros >> >> Steve Smith wrote: >>> And there are other bizarre ways to return without >>> restoring R14, which is not actually required by documented conventions. >> >> Only restoring of AR14 and the high half of R14 are required (for >> non-AMODE 64 cases), in general. >> (Although I would guess that there are many violations of preserving the >> high half of R14). >> Some interfaces might define that they preserve R14 completely. Most do >> not. >> >> Mark Hammack wrote >>> I have a macro that switches between a regular (24/31 bit style) >>> save area and an extended (64 bit "F4SA") save area. >> >> What do you mean by "switches between"? It is fine to use a different >> style than the style your caller was using (as long as the savearea >> provided is big enough to accommodate your needs), without having any care >> about what was being used by your caller. The string at +4 identifies how >> you saved your caller's registers. >> >> Peter Relson >> z/OS Core Technology Design >>
Re: Base-less macros
You don't have to always save ALL the registers. No matter what the caller provides, you can always do a STMG 14,4,8(13) STG 13,64(13) because it fits in the standard 72 byte minimal save area. After the STMG, you can then decide if the caller passed a larger area or you can just acquire a larger save area yourself and store everything "correctly" in it. Of course, if your routine can be written to only use R13-R4, you can just do your work and return back. After processing is done, you can then restore everything from the larger area, then restore 14-5 from the original save are, then return back. (Just don't use the RETURN macro.) Tony Thigpen Mark Hammack wrote on 11/30/21 10:53 AM: In our case, the caller doesn't "know" whether the called subroutine is base 31 or base 64. So it is up to the called subroutine to "figure out" whether the caller used a 72 byte save area or a 144 byte save area. Parameters to the macro set addressing mode, RSA size, etc. This allows for a 31 bit module to call a 64 bit subroutine and vice versa. That's what I really mean by "switches between". The one caveat is that the caller must provide a large enough area to allow for the 144 byte area. Since some subroutines accept arguments in R0 and/or R1 (and unfortunately assume other registers are pre-loaded) those can't be touched before being saved. Likewise, if the routine is called from another 64 bit subroutine, the high halves of registers are (potentially) in use. However, since (currently) all of our programs run below the bar, using the high half of R14 may be an option. I need to look into using a FPR or AR but the 4 byte literal pool works for now. Storing R14 in 8(R13) is not a bad idea either. Thanks! *Mark* On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. So the OP's premise is incorrect. A program cannot learn the length or format of the incoming save area by examining it (although an FnSA string there would give you a clue of what the caller was up to in general). I am inferring that there is no way for a called program to determine programmatically the length or expected format of the incoming save area. It must be agreed upon by the two programs, or phrasing it differently, the called program's save area expectations must be documented and respected by the caller. Am I right, or off (pardon the pun) base? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU ] On Behalf Of Peter Relson Sent: Tuesday, November 30, 2021 5:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Steve Smith wrote: And there are other bizarre ways to return without restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: Base-less macros
And IIRC in ancient days the PL1 runtime used to use word 1 of the RSA for its own purposes. Don’t know if LE and Enterprise PL1 (or Enterprise COBOL for that matter) continued that tradition or not. Peter -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 30, 2021 12:37 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I think it is one of those "better safe than sorry" things. If a prior subroutine call used this RSA in 31 bit mode, then 4(13) should be an address so the low order bit shouldn't be on (in theory). I remember a programmer using the first word of the RSA as temp storage...until some other subroutine (not in our control) either used it for some other reason. Not as bad as using the first 8 bits of an address for flags, but still a headache to correct. *Mark* On Tue, Nov 30, 2021 at 10:53 AM Seymour J Metz wrote: > Do you really need to test all four bytes? A test for 'SA' should be > enough. > > -- > Shmuel (Seymour J.) Metz > https://urldefense.com/v3/__http://mason.gmu.edu/*smetz3__;fg!!Ebr-cpP > eAnfNniQ8HSAI-g_K5b7VKg!fJ-ZGLII6ou2tbp7J5r5YQxS_lMe78f778iGHf8Xyncavn > D8-EgiZR1MVewdjWfyRDQ-iA$ > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on behalf of Mark Hammack [mark.hamm...@gmail.com] > Sent: Tuesday, November 30, 2021 10:53 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine > is base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This > allows for a 31 bit module to call a 64 bit subroutine and vice versa. > That's what I really mean by "switches between". The one caveat is > that the caller must provide a large enough area to allow for the 144 byte > area. > > Since some subroutines accept arguments in R0 and/or R1 (and > unfortunately assume other registers are pre-loaded) those can't be > touched before being saved. Likewise, if the routine is called from > another 64 bit subroutine, the high halves of registers are > (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half > of > R14 may be an option. I need to look into using a FPR or AR but the 4 > byte literal pool works for now. Storing R14 in 8(R13) is not a bad > idea either. > > Thanks! > > > > *Mark* > > > On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: > > > Ah! I have not been clear on the convention. As I read it now, the > > called program puts one of the FnSA strings in its *new* save area > > to indicate > how > > *it* previously stored the registers in its entry save area. > > > > So the OP's premise is incorrect. A program cannot learn the length > > or format of the incoming save area by examining it (although an > > FnSA string there would give you a clue of what the caller was up to in > > general). > > > > I am inferring that there is no way for a called program to > > determine programmatically the length or expected format of the incoming > > save area. > > It > > must be agreed upon by the two programs, or phrasing it differently, > > the called program's save area expectations must be documented and > > respected > by > > the caller. > > > > Am I right, or off (pardon the pun) base? > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto: > ASSEMBLER-LIST@LISTSERV.UGA.EDU > > ] > > On Behalf Of Peter Relson > > Sent: Tuesday, November 30, 2021 5:39 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > Steve Smith wrote: > > >And there are other bizarre ways to return without restoring R14, > > >which is not actually required by documented conventions. > > > > Only restoring of AR14 and the high half of R14 are required (for > > non-AMODE 64 cases), in general. > > (Although I would guess that there are many violations of preserving > > the high half of R14). > > Some interfaces might define that they preserve R14 completely. Most > > do not. > > > > Mark Hammack wrote > > >I have a macro that switches between a regular (24/31 bit style) > > >save area and an extended (64 bit "F4SA") save area. > > > > What do you mean by &qu
Re: Base-less macros
I *think* this is based on a flawed premise. Read what I wrote at 9:37 EST and correct me if I am wrong. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 30, 2021 9:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Couldn't do a "normal" STM R14,R12,4(R13) since that would overlay the area to be checked. STGM 14,12,8(13) would probably work in most cases. Either the first 72 bytes will be rewritten with the STM or the data is already stored. The only issue I see is possibly debugging, trying to decipher the RSA chain to figure out what routine was called prior to the current routine (had to do that a couple of times). *Mark* On Tue, Nov 30, 2021 at 10:13 AM Charles Mills wrote: > > the caller must provide a large enough area to allow for the 144 byte > > Does that not make the problem go away? Simply automatically always save > the low order halves of the registers, and if the subroutine will be > altering the high halves, save those also. Done. The *caller* has no say in > the save area format. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Mark Hammack > Sent: Tuesday, November 30, 2021 7:54 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea > either. >
Re: Base-less macros
Couldn't do a "normal" STM R14,R12,4(R13) since that would overlay the area to be checked. STGM 14,12,8(13) would probably work in most cases. Either the first 72 bytes will be rewritten with the STM or the data is already stored. The only issue I see is possibly debugging, trying to decipher the RSA chain to figure out what routine was called prior to the current routine (had to do that a couple of times). *Mark* On Tue, Nov 30, 2021 at 10:13 AM Charles Mills wrote: > > the caller must provide a large enough area to allow for the 144 byte > > Does that not make the problem go away? Simply automatically always save > the low order halves of the registers, and if the subroutine will be > altering the high halves, save those also. Done. The *caller* has no say in > the save area format. > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Mark Hammack > Sent: Tuesday, November 30, 2021 7:54 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea > either. >
Re: Base-less macros
I think it is one of those "better safe than sorry" things. If a prior subroutine call used this RSA in 31 bit mode, then 4(13) should be an address so the low order bit shouldn't be on (in theory). I remember a programmer using the first word of the RSA as temp storage...until some other subroutine (not in our control) either used it for some other reason. Not as bad as using the first 8 bits of an address for flags, but still a headache to correct. *Mark* On Tue, Nov 30, 2021 at 10:53 AM Seymour J Metz wrote: > Do you really need to test all four bytes? A test for 'SA' should be > enough. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Mark Hammack [mark.hamm...@gmail.com] > Sent: Tuesday, November 30, 2021 10:53 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > In our case, the caller doesn't "know" whether the called subroutine is > base 31 or base 64. So it is up to the called subroutine to "figure out" > whether the caller used a 72 byte save area or a 144 byte save area. > Parameters to the macro set addressing mode, RSA size, etc. This allows > for a 31 bit module to call a 64 bit subroutine and vice versa. That's > what I really mean by "switches between". The one caveat is that the > caller must provide a large enough area to allow for the 144 byte area. > > Since some subroutines accept arguments in R0 and/or R1 (and unfortunately > assume other registers are pre-loaded) those can't be touched before being > saved. Likewise, if the routine is called from another 64 bit subroutine, > the high halves of registers are (potentially) in use. However, since > (currently) all of our programs run below the bar, using the high half of > R14 may be an option. I need to look into using a FPR or AR but the 4 byte > literal pool works for now. Storing R14 in 8(R13) is not a bad idea > either. > > Thanks! > > > > *Mark* > > > On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: > > > Ah! I have not been clear on the convention. As I read it now, the called > > program puts one of the FnSA strings in its *new* save area to indicate > how > > *it* previously stored the registers in its entry save area. > > > > So the OP's premise is incorrect. A program cannot learn the length or > > format of the incoming save area by examining it (although an FnSA string > > there would give you a clue of what the caller was up to in general). > > > > I am inferring that there is no way for a called program to determine > > programmatically the length or expected format of the incoming save area. > > It > > must be agreed upon by the two programs, or phrasing it differently, the > > called program's save area expectations must be documented and respected > by > > the caller. > > > > Am I right, or off (pardon the pun) base? > > > > Charles > > > > > > -Original Message- > > From: IBM Mainframe Assembler List [mailto: > ASSEMBLER-LIST@LISTSERV.UGA.EDU > > ] > > On Behalf Of Peter Relson > > Sent: Tuesday, November 30, 2021 5:39 AM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > Steve Smith wrote: > > >And there are other bizarre ways to return without > > >restoring R14, which is not actually required by documented conventions. > > > > Only restoring of AR14 and the high half of R14 are required (for > > non-AMODE 64 cases), in general. > > (Although I would guess that there are many violations of preserving the > > high half of R14). > > Some interfaces might define that they preserve R14 completely. Most do > > not. > > > > Mark Hammack wrote > > >I have a macro that switches between a regular (24/31 bit style) > > >save area and an extended (64 bit "F4SA") save area. > > > > What do you mean by "switches between"? It is fine to use a different > > style than the style your caller was using (as long as the savearea > > provided is big enough to accommodate your needs), without having any > care > > about what was being used by your caller. The string at +4 identifies how > > you saved your caller's registers. > > > > Peter Relson > > z/OS Core Technology Design > > >
Re: Base-less macros
On Nov 30, 2021, at 10:07:51, Gary Weinhold wrote: > > Actually the 24-bit architecture wasn't the legacy problem as much as > not restricting the leading byte of a fullword (whether in memory or > registers) that the hardware would interpret as an address. That led to > the use of the high-order bit to denote a 31-bit address, which led to > the missing 2G in the 64-bit architecture. > That's only a software constraint. Linux is pure 64-bit and uses that 2GiB with no concerns. Using the rightmost bit introduces another ambiguity. ENTRY usually identifies a code address, which must be even, so that bit is available to indicare AMODE 64. However, ENTRY might identify a data address, which might be even or odd. However, if the CSECT is marked AMODE 64, Binder will set that bit, regardless. The programmer must be mindful not to define an ENTRY at an odd data address. -- gil
Re: Base-less macros
CHSI 6(r13),C'SA' Should be adequate to test whether the caller has a long save area. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Tuesday, November 30, 2021 9:36 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. So the OP's premise is incorrect. A program cannot learn the length or format of the incoming save area by examining it (although an FnSA string there would give you a clue of what the caller was up to in general). I am inferring that there is no way for a called program to determine programmatically the length or expected format of the incoming save area. It must be agreed upon by the two programs, or phrasing it differently, the called program's save area expectations must be documented and respected by the caller. Am I right, or off (pardon the pun) base? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Tuesday, November 30, 2021 5:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Steve Smith wrote: >And there are other bizarre ways to return without >restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote >I have a macro that switches between a regular (24/31 bit style) >save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Actually the 24-bit architecture wasn't the legacy problem as much as not restricting the leading byte of a fullword (whether in memory or registers) that the hardware would interpret as an address. That led to the use of the high-order bit to denote a 31-bit address, which led to the missing 2G in the 64-bit architecture. On 2021-11-30 11:57 a.m., Charles Mills wrote: I remember well. It was very much about saving storage. Storage was precious. Main memory sizes were measured in kilobytes, not megabytes or gigabytes. There was no virtual storage, so main memory size was very much a limiting factor -- not just to performance, as it is now, but an absolute limit on what program and how many programs one could run at once. Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Ward Sent: Tuesday, November 30, 2021 8:52 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 30/11/2021 16:36, Paul Gilmartin wrote: Didn't IBM do that? Doesn't mean that it was a good idea :-) "The 64-bit IBM zSeries (2001) still supports 24-bit mode, 40-plus years later. Why did 24-bit happen? I’m told that it was all for the sake of one low-cost early model, the 360/30, where 32 bits would have run slower because it had 8-bit data paths. These were last shipped more than 30 years ago. Were they worth the decades of extra headaches?" John R. Mashey, "The Long Road to 64 Bits" ACM Queue, 4, 8, October 2006 https://queue.acm.org/detail.cfm?id=1165766
Re: Base-less macros
I remember well. It was very much about saving storage. Storage was precious. Main memory sizes were measured in kilobytes, not megabytes or gigabytes. There was no virtual storage, so main memory size was very much a limiting factor -- not just to performance, as it is now, but an absolute limit on what program and how many programs one could run at once. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Martin Ward Sent: Tuesday, November 30, 2021 8:52 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 30/11/2021 16:36, Paul Gilmartin wrote: > Didn't IBM do that? Doesn't mean that it was a good idea :-) "The 64-bit IBM zSeries (2001) still supports 24-bit mode, 40-plus years later. Why did 24-bit happen? I’m told that it was all for the sake of one low-cost early model, the 360/30, where 32 bits would have run slower because it had 8-bit data paths. These were last shipped more than 30 years ago. Were they worth the decades of extra headaches?" John R. Mashey, "The Long Road to 64 Bits" ACM Queue, 4, 8, October 2006 https://queue.acm.org/detail.cfm?id=1165766 -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Base-less macros
Do you really need to test all four bytes? A test for 'SA' should be enough. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Hammack [mark.hamm...@gmail.com] Sent: Tuesday, November 30, 2021 10:53 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros In our case, the caller doesn't "know" whether the called subroutine is base 31 or base 64. So it is up to the called subroutine to "figure out" whether the caller used a 72 byte save area or a 144 byte save area. Parameters to the macro set addressing mode, RSA size, etc. This allows for a 31 bit module to call a 64 bit subroutine and vice versa. That's what I really mean by "switches between". The one caveat is that the caller must provide a large enough area to allow for the 144 byte area. Since some subroutines accept arguments in R0 and/or R1 (and unfortunately assume other registers are pre-loaded) those can't be touched before being saved. Likewise, if the routine is called from another 64 bit subroutine, the high halves of registers are (potentially) in use. However, since (currently) all of our programs run below the bar, using the high half of R14 may be an option. I need to look into using a FPR or AR but the 4 byte literal pool works for now. Storing R14 in 8(R13) is not a bad idea either. Thanks! *Mark* On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: > Ah! I have not been clear on the convention. As I read it now, the called > program puts one of the FnSA strings in its *new* save area to indicate how > *it* previously stored the registers in its entry save area. > > So the OP's premise is incorrect. A program cannot learn the length or > format of the incoming save area by examining it (although an FnSA string > there would give you a clue of what the caller was up to in general). > > I am inferring that there is no way for a called program to determine > programmatically the length or expected format of the incoming save area. > It > must be agreed upon by the two programs, or phrasing it differently, the > called program's save area expectations must be documented and respected by > the caller. > > Am I right, or off (pardon the pun) base? > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU > ] > On Behalf Of Peter Relson > Sent: Tuesday, November 30, 2021 5:39 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > Steve Smith wrote: > >And there are other bizarre ways to return without > >restoring R14, which is not actually required by documented conventions. > > Only restoring of AR14 and the high half of R14 are required (for > non-AMODE 64 cases), in general. > (Although I would guess that there are many violations of preserving the > high half of R14). > Some interfaces might define that they preserve R14 completely. Most do > not. > > Mark Hammack wrote > >I have a macro that switches between a regular (24/31 bit style) > >save area and an extended (64 bit "F4SA") save area. > > What do you mean by "switches between"? It is fine to use a different > style than the style your caller was using (as long as the savearea > provided is big enough to accommodate your needs), without having any care > about what was being used by your caller. The string at +4 identifies how > you saved your caller's registers. > > Peter Relson > z/OS Core Technology Design >
Re: Base-less macros
On 30/11/2021 16:36, Paul Gilmartin wrote: Didn't IBM do that? Doesn't mean that it was a good idea :-) "The 64-bit IBM zSeries (2001) still supports 24-bit mode, 40-plus years later. Why did 24-bit happen? I’m told that it was all for the sake of one low-cost early model, the 360/30, where 32 bits would have run slower because it had 8-bit data paths. These were last shipped more than 30 years ago. Were they worth the decades of extra headaches?" John R. Mashey, "The Long Road to 64 Bits" ACM Queue, 4, 8, October 2006 https://queue.acm.org/detail.cfm?id=1165766 -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Base-less macros
On Nov 30, 2021, at 09:10:03, Martin Ward wrote: > > On 30/11/2021 15:53, Mark Hammack wrote: >> using the high half of R14 may be an option. ... > > Does anyone still remember the problems caused by clever > programmers using the top 8 bits of a 24 bit address to store data > Didn't IBM do that? > when the code had to be ported to 31 bit mode? > ... requiring that I put bridge code to various OS interfaces below the line in early XA days. > "Those that fail to learn from history are doomed to repeat it." -- gil
Re: Base-less macros
That's exactly what I was thinking about using "may" :-). Just because it is below the bar today doesn't mean it won't be in a few years (after I retire). I'm not a fan of someone looking at the code in the future and saying "why the did they do that!". *Mark* On Tue, Nov 30, 2021 at 10:10 AM Martin Ward wrote: > On 30/11/2021 15:53, Mark Hammack wrote: > > using the high half of R14 may be an option. ... > > Does anyone still remember the problems caused by clever > programmers using the top 8 bits of a 24 bit address to store data > when the code had to be ported to 31 bit mode? > > "Those that fail to learn from history are doomed to repeat it." > > -- > Martin > > Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk > G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4 >
Re: Base-less macros
> the caller must provide a large enough area to allow for the 144 byte Does that not make the problem go away? Simply automatically always save the low order halves of the registers, and if the subroutine will be altering the high halves, save those also. Done. The *caller* has no say in the save area format. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 30, 2021 7:54 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros In our case, the caller doesn't "know" whether the called subroutine is base 31 or base 64. So it is up to the called subroutine to "figure out" whether the caller used a 72 byte save area or a 144 byte save area. Parameters to the macro set addressing mode, RSA size, etc. This allows for a 31 bit module to call a 64 bit subroutine and vice versa. That's what I really mean by "switches between". The one caveat is that the caller must provide a large enough area to allow for the 144 byte area. Since some subroutines accept arguments in R0 and/or R1 (and unfortunately assume other registers are pre-loaded) those can't be touched before being saved. Likewise, if the routine is called from another 64 bit subroutine, the high halves of registers are (potentially) in use. However, since (currently) all of our programs run below the bar, using the high half of R14 may be an option. I need to look into using a FPR or AR but the 4 byte literal pool works for now. Storing R14 in 8(R13) is not a bad idea either.
Re: Base-less macros
On 30/11/2021 15:53, Mark Hammack wrote: using the high half of R14 may be an option. ... Does anyone still remember the problems caused by clever programmers using the top 8 bits of a 24 bit address to store data when the code had to be ported to 31 bit mode? "Those that fail to learn from history are doomed to repeat it." -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Base-less macros
In our case, the caller doesn't "know" whether the called subroutine is base 31 or base 64. So it is up to the called subroutine to "figure out" whether the caller used a 72 byte save area or a 144 byte save area. Parameters to the macro set addressing mode, RSA size, etc. This allows for a 31 bit module to call a 64 bit subroutine and vice versa. That's what I really mean by "switches between". The one caveat is that the caller must provide a large enough area to allow for the 144 byte area. Since some subroutines accept arguments in R0 and/or R1 (and unfortunately assume other registers are pre-loaded) those can't be touched before being saved. Likewise, if the routine is called from another 64 bit subroutine, the high halves of registers are (potentially) in use. However, since (currently) all of our programs run below the bar, using the high half of R14 may be an option. I need to look into using a FPR or AR but the 4 byte literal pool works for now. Storing R14 in 8(R13) is not a bad idea either. Thanks! *Mark* On Tue, Nov 30, 2021 at 8:37 AM Charles Mills wrote: > Ah! I have not been clear on the convention. As I read it now, the called > program puts one of the FnSA strings in its *new* save area to indicate how > *it* previously stored the registers in its entry save area. > > So the OP's premise is incorrect. A program cannot learn the length or > format of the incoming save area by examining it (although an FnSA string > there would give you a clue of what the caller was up to in general). > > I am inferring that there is no way for a called program to determine > programmatically the length or expected format of the incoming save area. > It > must be agreed upon by the two programs, or phrasing it differently, the > called program's save area expectations must be documented and respected by > the caller. > > Am I right, or off (pardon the pun) base? > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU > ] > On Behalf Of Peter Relson > Sent: Tuesday, November 30, 2021 5:39 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > Steve Smith wrote: > >And there are other bizarre ways to return without > >restoring R14, which is not actually required by documented conventions. > > Only restoring of AR14 and the high half of R14 are required (for > non-AMODE 64 cases), in general. > (Although I would guess that there are many violations of preserving the > high half of R14). > Some interfaces might define that they preserve R14 completely. Most do > not. > > Mark Hammack wrote > >I have a macro that switches between a regular (24/31 bit style) > >save area and an extended (64 bit "F4SA") save area. > > What do you mean by "switches between"? It is fine to use a different > style than the style your caller was using (as long as the savearea > provided is big enough to accommodate your needs), without having any care > about what was being used by your caller. The string at +4 identifies how > you saved your caller's registers. > > Peter Relson > z/OS Core Technology Design >
Re: Base-less macros
Ah! I have not been clear on the convention. As I read it now, the called program puts one of the FnSA strings in its *new* save area to indicate how *it* previously stored the registers in its entry save area. So the OP's premise is incorrect. A program cannot learn the length or format of the incoming save area by examining it (although an FnSA string there would give you a clue of what the caller was up to in general). I am inferring that there is no way for a called program to determine programmatically the length or expected format of the incoming save area. It must be agreed upon by the two programs, or phrasing it differently, the called program's save area expectations must be documented and respected by the caller. Am I right, or off (pardon the pun) base? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Peter Relson Sent: Tuesday, November 30, 2021 5:39 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Steve Smith wrote: >And there are other bizarre ways to return without >restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote >I have a macro that switches between a regular (24/31 bit style) >save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Steve Smith wrote: >And there are other bizarre ways to return without >restoring R14, which is not actually required by documented conventions. Only restoring of AR14 and the high half of R14 are required (for non-AMODE 64 cases), in general. (Although I would guess that there are many violations of preserving the high half of R14). Some interfaces might define that they preserve R14 completely. Most do not. Mark Hammack wrote >I have a macro that switches between a regular (24/31 bit style) >save area and an extended (64 bit "F4SA") save area. What do you mean by "switches between"? It is fine to use a different style than the style your caller was using (as long as the savearea provided is big enough to accommodate your needs), without having any care about what was being used by your caller. The string at +4 identifies how you saved your caller's registers. Peter Relson z/OS Core Technology Design
Re: Base-less macros
As per the FPR usage thread, you could also save GR(s) to FP registers 0 thru 7. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Charles Mills Sent: Monday, November 29, 2021 18:03 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I did not think about how this had to happen before you had saved any registers. (Same issue for @Gary's suggestion, which is basically equivalent to mine.) If there is no register that your linkage conventions imply do not need to be saved (R0?) then you could temporarily save a register at 12(R13). That is available no matter what the format. Wastes a storage access, of course. You could save R14 there in whatever is the "expected" format of the save area. If you guessed right then no need to save it again. If "old style" is the most common situation, then you might do the whole R14,R12,12(R13) nine yards and if you got it right then you are mostly done. Steve Smith's suggestion of AR0 is interesting. Never thought about that ... Charles
Re: Base-less macros
I did not think about how this had to happen before you had saved any registers. (Same issue for @Gary's suggestion, which is basically equivalent to mine.) If there is no register that your linkage conventions imply do not need to be saved (R0?) then you could temporarily save a register at 12(R13). That is available no matter what the format. Wastes a storage access, of course. You could save R14 there in whatever is the "expected" format of the save area. If you guessed right then no need to save it again. If "old style" is the most common situation, then you might do the whole R14,R12,12(R13) nine yards and if you got it right then you are mostly done. Steve Smith's suggestion of AR0 is interesting. Never thought about that ... Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Charles Mills Sent: Monday, November 29, 2021 3:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros LLILF and C? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Monday, November 29, 2021 2:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros So an interesting dilemma: I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. Before saving the registers, I am checking whether the current save area is old (24/31 bit) or new (64 bit) save area. The original code used CLC =C'F4SA',4(R13) to check (since it is all our code, I don't need to worry about the other 64 bit save area formats). However, that implies a literal pool within 4k of the subroutine entry point (R15 at this point). I could add a 4 byte literal to the macro and then branch around it. The other option I thought of which removes the necessity of a base register is to use CLHHSI 4(R13),C'F4'/JNE .../CLHHSI 6(R13),C'SA'/JNE ... However, this is confusing and since there are multiple points in the macro where I need the F4SA literal, I'll probably go with door number one. If only there were 20 bit displacement options for CLC and MVC...(LRL, LARL, LAY, etc. have come in handy for reducing the number of LTORGS in the programs, especially for =A(address) type literals). *Mark* On Mon, Nov 29, 2021 at 4:06 PM Seymour J Metz wrote: > "When control is returned to your control section from the called control > section, registers 2-14 contain the same information they contained when > control was passed, as long as system conventions are followed." > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com] > Sent: Monday, November 29, 2021 3:57 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > The assembler services guide doesn't specify what is in (bottom half of) > R14 upon return. > Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the > low-order bit set. > > Robert > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Paul Gilmartin > Sent: Monday, November 29, 2021 14:01 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: > > > > DON'T DO THAT! > > I had to find/redo all our code that did this when our subroutine > return logic was changed to use a BIC instruction. > > > Which of you violated standard linkage conventions? > > My understanding is that R14 is expected to point to the instruction after > the CALL; R15 to the ENTRY point. Either may be changed by an embedded > CALL and should be treated as volatile. RETURN should use LM to retrieve > the value of R14, etc. > > > > -Original Message- > > From: Steve Smith > > Sent: Thursday, November 25, 2021 13:49 > > > > My suggestion of using R14 for the base was because it's already set by > the call to the subroutine. > > -- gil >
Re: Base-less macros
Well, I messed up CLRL... it is not an SS-like instruction. If you really can't afford to trash half of any general register, AR0 is a convenient hidey-hole. It's the appendix of z/Arch, as it appears to have no functional purpose. If AR0 can't be trashed, then surely you can borrow a FPR. If not, then may God have mercy on your soul. sas On Mon, Nov 29, 2021 at 6:43 PM Steve Smith wrote: > CLRL 04(r13),=C'F4SA' ...you have USING issues, but as long as LTORG is > within +/- 2G, no problem. > > I'd go with > LLIHF 0,C'F4SA' > CLHF 0,4(R13) > or > LFH 0,4(R13) > CLIH 0,C'F4SA' > > So many ways to skin the cat. > > As usual, not tested, subject to typos, memory checks, etc. > > sas > > On Mon, Nov 29, 2021 at 6:27 PM Charles Mills wrote: > >> LLILF and C? >> >> Charles >> >>
Re: Base-less macros
CLRL 04(r13),=C'F4SA' ...you have USING issues, but as long as LTORG is within +/- 2G, no problem. I'd go with LLIHF 0,C'F4SA' CLHF 0,4(R13) or LFH 0,4(R13) CLIH 0,C'F4SA' So many ways to skin the cat. As usual, not tested, subject to typos, memory checks, etc. sas On Mon, Nov 29, 2021 at 6:27 PM Charles Mills wrote: > LLILF and C? > > Charles > >
Re: Base-less macros
LLILF and C? Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Monday, November 29, 2021 2:52 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros So an interesting dilemma: I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. Before saving the registers, I am checking whether the current save area is old (24/31 bit) or new (64 bit) save area. The original code used CLC =C'F4SA',4(R13) to check (since it is all our code, I don't need to worry about the other 64 bit save area formats). However, that implies a literal pool within 4k of the subroutine entry point (R15 at this point). I could add a 4 byte literal to the macro and then branch around it. The other option I thought of which removes the necessity of a base register is to use CLHHSI 4(R13),C'F4'/JNE .../CLHHSI 6(R13),C'SA'/JNE ... However, this is confusing and since there are multiple points in the macro where I need the F4SA literal, I'll probably go with door number one. If only there were 20 bit displacement options for CLC and MVC...(LRL, LARL, LAY, etc. have come in handy for reducing the number of LTORGS in the programs, especially for =A(address) type literals). *Mark* On Mon, Nov 29, 2021 at 4:06 PM Seymour J Metz wrote: > "When control is returned to your control section from the called control > section, registers 2-14 contain the same information they contained when > control was passed, as long as system conventions are followed." > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com] > Sent: Monday, November 29, 2021 3:57 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > The assembler services guide doesn't specify what is in (bottom half of) > R14 upon return. > Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the > low-order bit set. > > Robert > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Paul Gilmartin > Sent: Monday, November 29, 2021 14:01 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: > > > > DON'T DO THAT! > > I had to find/redo all our code that did this when our subroutine > return logic was changed to use a BIC instruction. > > > Which of you violated standard linkage conventions? > > My understanding is that R14 is expected to point to the instruction after > the CALL; R15 to the ENTRY point. Either may be changed by an embedded > CALL and should be treated as volatile. RETURN should use LM to retrieve > the value of R14, etc. > > > > -Original Message- > > From: Steve Smith > > Sent: Thursday, November 25, 2021 13:49 > > > > My suggestion of using R14 for the base was because it's already set by > the call to the subroutine. > > -- gil >
Re: Base-less macros
Can you temporarily save one register, load it register with the 4(R13) and use a CFI? On 2021-11-29 5:51 p.m., Mark Hammack wrote: So an interesting dilemma: I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. Before saving the registers, I am checking whether the current save area is old (24/31 bit) or new (64 bit) save area. The original code used CLC =C'F4SA',4(R13) to check (since it is all our code, I don't need to worry about the other 64 bit save area formats). However, that implies a literal pool within 4k of the subroutine entry point (R15 at this point). I could add a 4 byte literal to the macro and then branch around it. The other option I thought of which removes the necessity of a base register is to use CLHHSI 4(R13),C'F4'/JNE .../CLHHSI 6(R13),C'SA'/JNE ... However, this is confusing and since there are multiple points in the macro where I need the F4SA literal, I'll probably go with door number one. If only there were 20 bit displacement options for CLC and MVC...(LRL, LARL, LAY, etc. have come in handy for reducing the number of LTORGS in the programs, especially for =A(address) type literals). *Mark* On Mon, Nov 29, 2021 at 4:06 PM Seymour J Metz wrote: "When control is returned to your control section from the called control section, registers 2-14 contain the same information they contained when control was passed, as long as system conventions are followed." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com] Sent: Monday, November 29, 2021 3:57 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros The assembler services guide doesn't specify what is in (bottom half of) R14 upon return. Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the low-order bit set. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, November 29, 2021 14:01 To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: DON'T DO THAT! I had to find/redo all our code that did this when our subroutine return logic was changed to use a BIC instruction. Which of you violated standard linkage conventions? My understanding is that R14 is expected to point to the instruction after the CALL; R15 to the ENTRY point. Either may be changed by an embedded CALL and should be treated as volatile. RETURN should use LM to retrieve the value of R14, etc. -Original Message- From: Steve Smith Sent: Thursday, November 25, 2021 13:49 My suggestion of using R14 for the base was because it's already set by the call to the subroutine. -- gil
Re: Base-less macros
So an interesting dilemma: I have a macro that switches between a regular (24/31 bit style) save area and an extended (64 bit "F4SA") save area. Before saving the registers, I am checking whether the current save area is old (24/31 bit) or new (64 bit) save area. The original code used CLC =C'F4SA',4(R13) to check (since it is all our code, I don't need to worry about the other 64 bit save area formats). However, that implies a literal pool within 4k of the subroutine entry point (R15 at this point). I could add a 4 byte literal to the macro and then branch around it. The other option I thought of which removes the necessity of a base register is to use CLHHSI 4(R13),C'F4'/JNE .../CLHHSI 6(R13),C'SA'/JNE ... However, this is confusing and since there are multiple points in the macro where I need the F4SA literal, I'll probably go with door number one. If only there were 20 bit displacement options for CLC and MVC...(LRL, LARL, LAY, etc. have come in handy for reducing the number of LTORGS in the programs, especially for =A(address) type literals). *Mark* On Mon, Nov 29, 2021 at 4:06 PM Seymour J Metz wrote: > "When control is returned to your control section from the called control > section, registers 2-14 contain the same information they contained when > control was passed, as long as system conventions are followed." > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com] > Sent: Monday, November 29, 2021 3:57 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > The assembler services guide doesn't specify what is in (bottom half of) > R14 upon return. > Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the > low-order bit set. > > Robert > > -Original Message- > From: IBM Mainframe Assembler List On > Behalf Of Paul Gilmartin > Sent: Monday, November 29, 2021 14:01 > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: > > > > DON'T DO THAT! > > I had to find/redo all our code that did this when our subroutine > return logic was changed to use a BIC instruction. > > > Which of you violated standard linkage conventions? > > My understanding is that R14 is expected to point to the instruction after > the CALL; R15 to the ENTRY point. Either may be changed by an embedded > CALL and should be treated as volatile. RETURN should use LM to retrieve > the value of R14, etc. > > > > -Original Message- > > From: Steve Smith > > Sent: Thursday, November 25, 2021 13:49 > > > > My suggestion of using R14 for the base was because it's already set by > the call to the subroutine. > > -- gil >
Re: Base-less macros
"When control is returned to your control section from the called control section, registers 2-14 contain the same information they contained when control was passed, as long as system conventions are followed " I see nothing wrong with BIC for returning from an AMODE 64 caller with an F4SA. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Monday, November 29, 2021 4:59 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Using R14 as a temporary code base after a call isn't going to work in those cases. I'd never heard about using BIC to return (nor can I see much reason for it). And there are other bizarre ways to return without restoring R14, which is not actually required by documented conventions. For BASSM, I suppose you could just change it to USING *+1,R14, depending on how that suits your sensibilities. Anyway, thanks both for pointing those out. Nevertheless, there's hardly any reason to ban it entirely. Everything has caveats. Any suggested code is provided without any warranty, and it's up to a competent programmer to decide if & how it may or may not fit into his or her program. And you might want to test it once or twice. sas On Mon, Nov 29, 2021 at 3:58 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > The assembler services guide doesn't specify what is in (bottom half of) > R14 upon return. > Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the > low-order bit set. > > Robert > >
Re: Base-less macros
"When control is returned to your control section from the called control section, registers 2-14 contain the same information they contained when control was passed, as long as system conventions are followed." -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ngan, Robert (DXC Luxoft) [robert.n...@dxc.com] Sent: Monday, November 29, 2021 3:57 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros The assembler services guide doesn't specify what is in (bottom half of) R14 upon return. Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the low-order bit set. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, November 29, 2021 14:01 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: > > DON'T DO THAT! > I had to find/redo all our code that did this when our subroutine return > logic was changed to use a BIC instruction. > Which of you violated standard linkage conventions? My understanding is that R14 is expected to point to the instruction after the CALL; R15 to the ENTRY point. Either may be changed by an embedded CALL and should be treated as volatile. RETURN should use LM to retrieve the value of R14, etc. > -Original Message- > From: Steve Smith > Sent: Thursday, November 25, 2021 13:49 > > My suggestion of using R14 for the base was because it's already set by the > call to the subroutine. -- gil
Re: Base-less macros
Using R14 as a temporary code base after a call isn't going to work in those cases. I'd never heard about using BIC to return (nor can I see much reason for it). And there are other bizarre ways to return without restoring R14, which is not actually required by documented conventions. For BASSM, I suppose you could just change it to USING *+1,R14, depending on how that suits your sensibilities. Anyway, thanks both for pointing those out. Nevertheless, there's hardly any reason to ban it entirely. Everything has caveats. Any suggested code is provided without any warranty, and it's up to a competent programmer to decide if & how it may or may not fit into his or her program. And you might want to test it once or twice. sas On Mon, Nov 29, 2021 at 3:58 PM Ngan, Robert (DXC Luxoft) < robert.n...@dxc.com> wrote: > The assembler services guide doesn't specify what is in (bottom half of) > R14 upon return. > Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the > low-order bit set. > > Robert > >
Re: Base-less macros
The assembler services guide doesn't specify what is in (bottom half of) R14 upon return. Also, on return to an AMODE(64) routine via BASSM/BSM, R14 would have the low-order bit set. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Paul Gilmartin Sent: Monday, November 29, 2021 14:01 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: > > DON'T DO THAT! > I had to find/redo all our code that did this when our subroutine return > logic was changed to use a BIC instruction. > Which of you violated standard linkage conventions? My understanding is that R14 is expected to point to the instruction after the CALL; R15 to the ENTRY point. Either may be changed by an embedded CALL and should be treated as volatile. RETURN should use LM to retrieve the value of R14, etc. > -Original Message- > From: Steve Smith > Sent: Thursday, November 25, 2021 13:49 > > My suggestion of using R14 for the base was because it's already set by the > call to the subroutine. -- gil
Re: Base-less macros
On Nov 29, 2021, at 12:41:51, Ngan, Robert (DXC Luxoft) wrote: > > DON'T DO THAT! > I had to find/redo all our code that did this when our subroutine return > logic was changed to use a BIC instruction. > Which of you violated standard linkage conventions? My understanding is that R14 is expected to point to the instruction after the CALL; R15 to the ENTRY point. Either may be changed by an embedded CALL and should be treated as volatile. RETURN should use LM to retrieve the value of R14, etc. > -Original Message- > From: Steve Smith > Sent: Thursday, November 25, 2021 13:49 > > My suggestion of using R14 for the base was because it's already set by the > call to the subroutine. -- gil
Re: Base-less macros
DON'T DO THAT! I had to find/redo all our code that did this when our subroutine return logic was changed to use a BIC instruction. Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Steve Smith Sent: Thursday, November 25, 2021 13:49 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros My suggestion of using R14 for the base was because it's already set by the call to the subroutine. sas On Thu, Nov 25, 2021 at 2:32 PM Gary Weinhold wrote: > The performance consideration I think would be the loading of R14 > immediately before its use in the branch instruction. Moving it up a > couple instructions may help. > >
Re: Base-less macros
On Nov 25, 2021, at 12:49:20, Steve Smith wrote: > > My suggestion of using R14 for the base was because it's already set by the > call to the subroutine. > RR15? (BALR 14,15) -- gil
Re: Base-less macros
I typically encapsulate such things in macros with a sensitivity to the architectural level. The downside is that it makes the macro more cluttered. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Thursday, November 25, 2021 2:11 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Nice job and thanks for correction on branch to table. One thing to point out especially with mainframe assembly is just to be sure when generating instructions that the proper instruction facilities are installed other wise S0C1. Best regards, Jeremy From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: Thursday, November 25, 2021 8:31 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. It could be shorter, and B BRTAB(R15) is not baseless. How about CIJL R15,0,RC_MINUS CIJH R15,MAXRC,RC_GT_MAX LARL R14,BRTAN B 0(R14,R15) How does the performance compare using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Wednesday, November 24, 2021 8:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12 --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Base-less macros
My suggestion of using R14 for the base was because it's already set by the call to the subroutine. sas On Thu, Nov 25, 2021 at 2:32 PM Gary Weinhold wrote: > The performance consideration I think would be the loading of R14 > immediately before its use in the branch instruction. Moving it up a > couple instructions may help. > >
Re: Base-less macros
The performance consideration I think would be the loading of R14 immediately before its use in the branch instruction. Moving it up a couple instructions may help. On 2021-11-25 2:11 p.m., Jeremy Schwartz wrote: Nice job and thanks for correction on branch to table. One thing to point out especially with mainframe assembly is just to be sure when generating instructions that the proper instruction facilities are installed other wise S0C1. Best regards, Jeremy Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: Thursday, November 25, 2021 8:31 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. It could be shorter, and B BRTAB(R15) is not baseless. How about CIJL R15,0,RC_MINUS CIJH R15,MAXRC,RC_GT_MAX LARL R14,BRTAN B 0(R14,R15) How does the performance compare using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Wednesday, November 24, 2021 8:44 PM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12 --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Base-less macros
Nice job and thanks for correction on branch to table. One thing to point out especially with mainframe assembly is just to be sure when generating instructions that the proper instruction facilities are installed other wise S0C1. Best regards, Jeremy From: IBM Mainframe Assembler List on behalf of Seymour J Metz Sent: Thursday, November 25, 2021 8:31 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. It could be shorter, and B BRTAB(R15) is not baseless. How about CIJL R15,0,RC_MINUS CIJH R15,MAXRC,RC_GT_MAX LARL R14,BRTAN B 0(R14,R15) How does the performance compare using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Wednesday, November 24, 2021 8:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12 --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Base-less macros
> using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. I think modern Z chips are smart enough to "know" that those ,0 branch instructions are always instruction-sequence no-ops. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Thursday, November 25, 2021 6:32 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros It could be shorter, and B BRTAB(R15) is not baseless. How about CIJL R15,0,RC_MINUS CIJH R15,MAXRC,RC_GT_MAX LARL R14,BRTAN B 0(R14,R15) How does the performance compare using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Wednesday, November 24, 2021 8:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12
Re: Base-less macros
It could be shorter, and B BRTAB(R15) is not baseless. How about CIJL R15,0,RC_MINUS CIJH R15,MAXRC,RC_GT_MAX LARL R14,BRTAN B 0(R14,R15) How does the performance compare using BCTR R14,0 rather than the LARL? It's shorter, but is a suppressed branch. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Jeremy Schwartz [115e2ee20c83-dmarc-requ...@listserv.uga.edu] Sent: Wednesday, November 24, 2021 8:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12
Re: Base-less macros
Here's another form of branch table combining compare and branches. Just thought it was interesting and one reason why I love assembler. So many possibilities. XR R0,R0 INCREMENT = 0 LR R1,R0 BCTR R1,0SET COMPARE = -1 JXLE R15,R0,LBL_RC_MINUS Label taken if <= -1 LA R1,MAX_RC SET COMPARE = MAX_RC JXH R15,R0,LBL_RC_GT_MAXLabel taken if > MAX_RC B BRTAB(R15) BRTAB DS 0H JLABEL_RC0 JLABEL_RC4 JLABEL_RC8 JLABEL_RC12 -Original Message- From: IBM Mainframe Assembler List On Behalf Of Seymour J Metz Sent: Tuesday, November 23, 2021 17:12 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros CAUTION: This message was sent from outside the company. Do not click links or open attachments unless you recognize the sender and know the content is safe. In light of subsequent messages, yes. From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Tuesday, November 23, 2021 1:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I think Martin is really commenting that if you only have 3 branch possibilities, then the overhead of the validation is greater than just doing three Test-and-branch instruction pairs. I don't know about others, but I don't usually use a branch table unless I have 8 or more values. Many of my branch tables have 100+ entries. Tony Thigpen Seymour J Metz wrote on 11/23/21 12:31 PM: > ? > > What is a shorter way to do the error checking? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] > on behalf of Martin Ward [mar...@gkc.org.uk] > Sent: Tuesday, November 23, 2021 12:27 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > On 23/11/2021 17:12, Seymour J Metz wrote: >>LTR R15,R15 >>JMBADIX >>CHI R15,LIMIT >>JHBADIX >>TML R15,3 >>JNZ BADIX >>J *+4(R15) >> BRTABEQU * >>J RC0ROUTINE >>J RC4ROUTINE >>J RC8ROUTINE >> LIMITEQU *-BRTAB > > Three test and branch instruction pairs plus two unconditional branch > instructions, all to avoid executing a sequence of up to three test > and branch instruction pairs :-) > > -- > Martin > > Dr Martin Ward | Email: mar...@gkc.org.uk | > http://secure-web.cisco.com/1Pzh0mz_8aE1yk4Zn65QdgWKxjXTYuplR0LTSWVThm > 5eBwv_XGYMaTUu-chekxBfi6Q9025E8Qko7Tv2AfAq4VKpPXZJATEnvK9yfCADRqS-MqJ- > 9CwXhQPcVAUaaVJisVYqePQcB1EgYhTEXUg6EMsRZGoSZYmbdXVC6DKXq6U8r16EOSntjB > Uqgbf2JkfOl98-JPqYFjgE8_O2ukkHD0bNk7EcYVFjZpL1RJqnISm5qT4Y1PLZTFqF7W4R > LN3SouhBZKmQy9KILd6gufPlqfnEZ6XXLr886LHYJ7D4RI2pkwR_tUPju4DD8dBYH0dI5v > bdm4BN1zPlh0lAnJdlARc5rcXUCQ658_9kIqdQ2ssUV8SW7IqhNvqBrN5QJARIDeNc6W-Q > -LfKdo7Pk9GyTpPv0B3hR9SkveNdRnWPBZDBmkTzbbHhclfSRqf0xnmsZ/http%3A%2F%2 > Fwww.gkc.org.uk G.K.Chesterton site: > http://secure-web.cisco.com/1OoGY6MPQRndcjIvC1a1r8dwvjRs0IiXumRn9B23l7 > Qi4vovkS4Ad8DCdEzjy7ZIxLBepUzkEB_3bndzCEBbgp6ItZFwrsQSie-z0aU7oWtR4pD- > YS5UwnfKWFfEM53hm7XEj8GMpX_xgRvBYE6TI0wql6IHyekYniK7_TXAPyRNm18FqTVb_E > Xc24xGkuM4ixs2eE2TlFlZFIZKuIvQCgjZs600JXzVB2Caqp-MsKzLomt4z2p5Y3oxjZF9 > k0tWw8BKgGSN-e2OHTuv1dZfxbT7sMdFq0_P0TneTPOkY5JnRjmQK04uRe9mgyNatqGClU > iwzLK4C7cShMxI2X-pM21gz0CRfnAG77jKiBGCgCVy-6Qak1MF7G9FPhX9rdPIB8sOIEru > uQuHWc0VVU9Ps4UvPqQIKmmIbtqJ76rIR9-r-TwsRyxErjP4aJaZlW7MQ/http%3A%2F%2 > Fwww.gkc.org.uk%2Fgkc | Erdos number: 4 > --- NOTICE: This email and all attachments are confidential, may be proprietary, and may be privileged or otherwise protected from disclosure. They are intended solely for the individual or entity to whom the email is addressed. However, mistakes sometimes happen in addressing emails. If you believe that you are not an intended recipient, please stop reading immediately. Do not copy, forward, or rely on the contents in any way. Notify the sender and/or Imperva, Inc. by telephone at +1 (650) 832-6006 and then delete or destroy any copy of this email and its attachments. The sender reserves and asserts all rights to confidentiality, as well as any privileges that may apply. Any disclosure, copying, distribution or action taken or omitted to be taken by an unintended recipient in reliance on this message is prohibited and may be unlawful. Please consider the environment before printing this email.
Re: Base-less macros
We got rid of all of this form of branch tables way back when, after IBM added a new RC for the OPEN macro (i.e. 16 for RLS), and our code jumped beyond the branch table into the RC=0 code! Robert -Original Message- From: IBM Mainframe Assembler List On Behalf Of Steve Smith Sent: Tuesday, November 23, 2021 10:21 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros ...some BASR R14, or JAS R14, etc. USING *,R14 B *+4(R15) DROP R14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE sas
Re: Base-less macros
In light of subsequent messages, yes. From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Tuesday, November 23, 2021 1:33 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros I think Martin is really commenting that if you only have 3 branch possibilities, then the overhead of the validation is greater than just doing three Test-and-branch instruction pairs. I don't know about others, but I don't usually use a branch table unless I have 8 or more values. Many of my branch tables have 100+ entries. Tony Thigpen Seymour J Metz wrote on 11/23/21 12:31 PM: > ? > > What is a shorter way to do the error checking? > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Martin Ward [mar...@gkc.org.uk] > Sent: Tuesday, November 23, 2021 12:27 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > On 23/11/2021 17:12, Seymour J Metz wrote: >>LTR R15,R15 >>JMBADIX >>CHI R15,LIMIT >>JHBADIX >>TML R15,3 >>JNZ BADIX >>J *+4(R15) >> BRTABEQU * >>J RC0ROUTINE >>J RC4ROUTINE >>J RC8ROUTINE >> LIMITEQU *-BRTAB > > Three test and branch instruction pairs plus two unconditional > branch instructions, all to avoid executing a sequence > of up to three test and branch instruction pairs :-) > > -- > Martin > > Dr Martin Ward | Email: mar...@gkc.org.uk | > http://secure-web.cisco.com/1Pzh0mz_8aE1yk4Zn65QdgWKxjXTYuplR0LTSWVThm5eBwv_XGYMaTUu-chekxBfi6Q9025E8Qko7Tv2AfAq4VKpPXZJATEnvK9yfCADRqS-MqJ-9CwXhQPcVAUaaVJisVYqePQcB1EgYhTEXUg6EMsRZGoSZYmbdXVC6DKXq6U8r16EOSntjBUqgbf2JkfOl98-JPqYFjgE8_O2ukkHD0bNk7EcYVFjZpL1RJqnISm5qT4Y1PLZTFqF7W4RLN3SouhBZKmQy9KILd6gufPlqfnEZ6XXLr886LHYJ7D4RI2pkwR_tUPju4DD8dBYH0dI5vbdm4BN1zPlh0lAnJdlARc5rcXUCQ658_9kIqdQ2ssUV8SW7IqhNvqBrN5QJARIDeNc6W-Q-LfKdo7Pk9GyTpPv0B3hR9SkveNdRnWPBZDBmkTzbbHhclfSRqf0xnmsZ/http%3A%2F%2Fwww.gkc.org.uk > G.K.Chesterton site: > http://secure-web.cisco.com/1OoGY6MPQRndcjIvC1a1r8dwvjRs0IiXumRn9B23l7Qi4vovkS4Ad8DCdEzjy7ZIxLBepUzkEB_3bndzCEBbgp6ItZFwrsQSie-z0aU7oWtR4pD-YS5UwnfKWFfEM53hm7XEj8GMpX_xgRvBYE6TI0wql6IHyekYniK7_TXAPyRNm18FqTVb_EXc24xGkuM4ixs2eE2TlFlZFIZKuIvQCgjZs600JXzVB2Caqp-MsKzLomt4z2p5Y3oxjZF9k0tWw8BKgGSN-e2OHTuv1dZfxbT7sMdFq0_P0TneTPOkY5JnRjmQK04uRe9mgyNatqGClUiwzLK4C7cShMxI2X-pM21gz0CRfnAG77jKiBGCgCVy-6Qak1MF7G9FPhX9rdPIB8sOIEruuQuHWc0VVU9Ps4UvPqQIKmmIbtqJ76rIR9-r-TwsRyxErjP4aJaZlW7MQ/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc > | Erdos number: 4 >
Re: Base-less macros
I like that for short tables, and it's also shorter than using a branch table when you take error checking into account. For long tables the branch tables is still more efficient and, IMHO, clearer. From: IBM Mainframe Assembler List on behalf of Ngan, Robert (DXC Luxoft) Sent: Tuesday, November 23, 2021 2:44 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or even simpler: CLIJE R15,0,RC0ROUTINE CLIJE R15,4,RC4ROUTINE CLIJE R15,8,RC8ROUTINE CLIJE R15,12,RC12ROUTINE J UnexpectedRC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Pieter Wiid Sent: Tuesday, November 23, 2021 12:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://clicktime.symantec.com/34azrGaNF3hyxgii8E2dVoc6xU?u=https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Base-less macros
RE: Base-less macros Seymour J Metz Tue 11/23/2021 12:48 PM > Maybe I missed something? Actually, I did; the LARL is necessary. Sorry. > I had started to use: It would have been correct with an ALR or LA rather than an L. > they're cleaner than trying to use the select structured macro (IMO). chacun à son goût -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Mark Hammack [mark.hamm...@gmail.com] Sent: Tuesday, November 23, 2021 12:36 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Thanks everyone! Seymour, I don't see anywhere that Branch Relative on Condition takes an "index register". Maybe I missed something? Charles, the macro I wrote has bounds checking (one of the reasons I wrote it was because I found the potential for exactly the problem you mention). I may have gotten mixed up. I had started to use: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 DC A(RC0ROUTINE) DCA(RC4ROUTINE) DCA(RC8ROUTINE) and confused myself. I'm not real big on branch tables myself but they're cleaner than trying to use the select structured macro (IMO). Also, my intent was to hide a lot of the branch table weaknesses. From a LOOONG time ago, the original IBM C compiler implemented branch tables for switch/case. Steve, I need to investigate BAS. Thought about BAL but guess I never "equated" the two. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c)
Re: Base-less macros
I vote for this one! Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Tuesday, November 23, 2021 11:44 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or even simpler: CLIJE R15,0,RC0ROUTINE CLIJE R15,4,RC4ROUTINE CLIJE R15,8,RC8ROUTINE CLIJE R15,12,RC12ROUTINE J UnexpectedRC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Pieter Wiid Sent: Tuesday, November 23, 2021 12:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://clicktime.symantec.com/34azrGaNF3hyxgii8E2dVoc6xU?u=https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Base-less macros
So yes, typically a branch table for return codes is going to be in the order of 6 (0,4,8,12,16,20) and anything else would be handled by the "you shouldn't be here" case. 95% of the time CIJE 15,0,RC0ROUTINE/CIJE 15,4,RC4ROUTINE/etc. would work just fine (I like that idea, especially when implemented as a macro). But, we do have cases with many branch targets, not as many as Tony's but still in the 10-20 range. In those cases. you are just as likely to have to traverse the entire list as the first entry making performance a possible issue. This really stems out of a copy/paste error that I mentioned in the thread about ASMPUT. Someone copied a branch relative instruction from one subroutine to another and forgot to change the target address. In coming up with potential "solutions" (to avoid the issue in the future), one idea I had was to create label and branch macros that would enforce a "unique to this subroutine" rule. They worked fine but then I came across the branch table. I try to avoid using conditional assembly in open code so was working on a branch table structure that worked with the aforementioned label and branch macros. Thanks again for the input! *Mark* On Tue, Nov 23, 2021 at 12:34 PM Tony Thigpen wrote: > I think Martin is really commenting that if you only have 3 branch > possibilities, then the overhead of the validation is greater than just > doing three Test-and-branch instruction pairs. > > I don't know about others, but I don't usually use a branch table unless > I have 8 or more values. Many of my branch tables have 100+ entries. > > Tony Thigpen > > Seymour J Metz wrote on 11/23/21 12:31 PM: > > ? > > > > What is a shorter way to do the error checking? > > > > > > -- > > Shmuel (Seymour J.) Metz > > http://mason.gmu.edu/~smetz3 > > > > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Martin Ward [mar...@gkc.org.uk] > > Sent: Tuesday, November 23, 2021 12:27 PM > > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > > Subject: Re: Base-less macros > > > > On 23/11/2021 17:12, Seymour J Metz wrote: > >>LTR R15,R15 > >>JMBADIX > >>CHI R15,LIMIT > >>JHBADIX > >>TML R15,3 > >>JNZ BADIX > >>J *+4(R15) > >> BRTABEQU * > >>J RC0ROUTINE > >>J RC4ROUTINE > >>J RC8ROUTINE > >> LIMITEQU *-BRTAB > > > > Three test and branch instruction pairs plus two unconditional > > branch instructions, all to avoid executing a sequence > > of up to three test and branch instruction pairs :-) > > > > -- > > Martin > > > > Dr Martin Ward | Email: mar...@gkc.org.uk | > http://secure-web.cisco.com/1Pzh0mz_8aE1yk4Zn65QdgWKxjXTYuplR0LTSWVThm5eBwv_XGYMaTUu-chekxBfi6Q9025E8Qko7Tv2AfAq4VKpPXZJATEnvK9yfCADRqS-MqJ-9CwXhQPcVAUaaVJisVYqePQcB1EgYhTEXUg6EMsRZGoSZYmbdXVC6DKXq6U8r16EOSntjBUqgbf2JkfOl98-JPqYFjgE8_O2ukkHD0bNk7EcYVFjZpL1RJqnISm5qT4Y1PLZTFqF7W4RLN3SouhBZKmQy9KILd6gufPlqfnEZ6XXLr886LHYJ7D4RI2pkwR_tUPju4DD8dBYH0dI5vbdm4BN1zPlh0lAnJdlARc5rcXUCQ658_9kIqdQ2ssUV8SW7IqhNvqBrN5QJARIDeNc6W-Q-LfKdo7Pk9GyTpPv0B3hR9SkveNdRnWPBZDBmkTzbbHhclfSRqf0xnmsZ/http%3A%2F%2Fwww.gkc.org.uk > > G.K.Chesterton site: > http://secure-web.cisco.com/1OoGY6MPQRndcjIvC1a1r8dwvjRs0IiXumRn9B23l7Qi4vovkS4Ad8DCdEzjy7ZIxLBepUzkEB_3bndzCEBbgp6ItZFwrsQSie-z0aU7oWtR4pD-YS5UwnfKWFfEM53hm7XEj8GMpX_xgRvBYE6TI0wql6IHyekYniK7_TXAPyRNm18FqTVb_EXc24xGkuM4ixs2eE2TlFlZFIZKuIvQCgjZs600JXzVB2Caqp-MsKzLomt4z2p5Y3oxjZF9k0tWw8BKgGSN-e2OHTuv1dZfxbT7sMdFq0_P0TneTPOkY5JnRjmQK04uRe9mgyNatqGClUiwzLK4C7cShMxI2X-pM21gz0CRfnAG77jKiBGCgCVy-6Qak1MF7G9FPhX9rdPIB8sOIEruuQuHWc0VVU9Ps4UvPqQIKmmIbtqJ76rIR9-r-TwsRyxErjP4aJaZlW7MQ/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc > | Erdos number: 4 > > >
Re: Base-less macros
* To make Seymour happy,... I certainly do like that comment, Just for the record- there are lots of comments like this in all kind of programs for all kind of purposes: * since Martin insisted: here is whatever. Best Martin
Re: Base-less macros
Oops, I didn't notice Pieter's response. Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Ngan, Robert (DXC Luxoft) Sent: Tuesday, November 23, 2021 13:44 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or even simpler: CLIJE R15,0,RC0ROUTINE CLIJE R15,4,RC4ROUTINE CLIJE R15,8,RC8ROUTINE CLIJE R15,12,RC12ROUTINE J UnexpectedRC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Pieter Wiid Sent: Tuesday, November 23, 2021 12:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://clicktime.symantec.com/34azrGaNF3hyxgii8E2dVoc6xU?u=https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Base-less macros
Or even simpler: CLIJE R15,0,RC0ROUTINE CLIJE R15,4,RC4ROUTINE CLIJE R15,8,RC8ROUTINE CLIJE R15,12,RC12ROUTINE J UnexpectedRC Robert Ngan DXC Luxoft -Original Message- From: IBM Mainframe Assembler List On Behalf Of Pieter Wiid Sent: Tuesday, November 23, 2021 12:29 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://clicktime.symantec.com/34azrGaNF3hyxgii8E2dVoc6xU?u=https%3A%2F%2Fwww.avast.com%2Fantivirus
Re: Base-less macros
I think Martin is really commenting that if you only have 3 branch possibilities, then the overhead of the validation is greater than just doing three Test-and-branch instruction pairs. I don't know about others, but I don't usually use a branch table unless I have 8 or more values. Many of my branch tables have 100+ entries. Tony Thigpen Seymour J Metz wrote on 11/23/21 12:31 PM: ? What is a shorter way to do the error checking? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Martin Ward [mar...@gkc.org.uk] Sent: Tuesday, November 23, 2021 12:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 23/11/2021 17:12, Seymour J Metz wrote: LTR R15,R15 JMBADIX CHI R15,LIMIT JHBADIX TML R15,3 JNZ BADIX J *+4(R15) BRTABEQU * J RC0ROUTINE J RC4ROUTINE J RC8ROUTINE LIMITEQU *-BRTAB Three test and branch instruction pairs plus two unconditional branch instructions, all to avoid executing a sequence of up to three test and branch instruction pairs :-) -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://secure-web.cisco.com/1Pzh0mz_8aE1yk4Zn65QdgWKxjXTYuplR0LTSWVThm5eBwv_XGYMaTUu-chekxBfi6Q9025E8Qko7Tv2AfAq4VKpPXZJATEnvK9yfCADRqS-MqJ-9CwXhQPcVAUaaVJisVYqePQcB1EgYhTEXUg6EMsRZGoSZYmbdXVC6DKXq6U8r16EOSntjBUqgbf2JkfOl98-JPqYFjgE8_O2ukkHD0bNk7EcYVFjZpL1RJqnISm5qT4Y1PLZTFqF7W4RLN3SouhBZKmQy9KILd6gufPlqfnEZ6XXLr886LHYJ7D4RI2pkwR_tUPju4DD8dBYH0dI5vbdm4BN1zPlh0lAnJdlARc5rcXUCQ658_9kIqdQ2ssUV8SW7IqhNvqBrN5QJARIDeNc6W-Q-LfKdo7Pk9GyTpPv0B3hR9SkveNdRnWPBZDBmkTzbbHhclfSRqf0xnmsZ/http%3A%2F%2Fwww.gkc.org.uk G.K.Chesterton site: http://secure-web.cisco.com/1OoGY6MPQRndcjIvC1a1r8dwvjRs0IiXumRn9B23l7Qi4vovkS4Ad8DCdEzjy7ZIxLBepUzkEB_3bndzCEBbgp6ItZFwrsQSie-z0aU7oWtR4pD-YS5UwnfKWFfEM53hm7XEj8GMpX_xgRvBYE6TI0wql6IHyekYniK7_TXAPyRNm18FqTVb_EXc24xGkuM4ixs2eE2TlFlZFIZKuIvQCgjZs600JXzVB2Caqp-MsKzLomt4z2p5Y3oxjZF9k0tWw8BKgGSN-e2OHTuv1dZfxbT7sMdFq0_P0TneTPOkY5JnRjmQK04uRe9mgyNatqGClUiwzLK4C7cShMxI2X-pM21gz0CRfnAG77jKiBGCgCVy-6Qak1MF7G9FPhX9rdPIB8sOIEruuQuHWc0VVU9Ps4UvPqQIKmmIbtqJ76rIR9-r-TwsRyxErjP4aJaZlW7MQ/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc | Erdos number: 4
Re: Base-less macros
Or CIJE R15,0,RC0ROUTINE ...etc -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Watkins, Doug Sent: Tuesday, 23 November 2021 20:00 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) -- This email has been checked for viruses by Avast antivirus software. https://www.avast.com/antivirus
Re: Base-less macros
Alternatively, consider the BRANCH INDIRECT ON CONDITION (BIC) instruction (available on the z14). The second operand of BIC is an 8-byte location in memory from which the branch address is fetched. BIC was designed to assist Java in returning from a garbage collection operation, where the return address is an 8-byte entry in the program stack, and there isn't another register besides the stack pointer available. However, if you can structure the program such that a branch table comprises 8-byte addresses in memory, BIC is useful, e.g., * R15 assumed to contain table index as a multiple of 8. * To make Seymour happy, validate R15 if not a trusted value. LARL 14,BR_TABLE BI0(14,15) BI is the extended mnemonic for BIC with mask of F. ... BR_TABLE DCAD(CURLEY) DCAD(MOE) DCAD(LARRY)
Re: Base-less macros
Mark, Another vote for not using branch tables, for all the reasons already mentioned. This is what I do... CHI R15,0 JE RC0ROUTINE CHI R15,4 JE RC4ROUTINE CHI R15,8 JE RC8ROUTINE etc. I understand you might be concerned about performance if you have dozens of return codes, the higher ones are returned frequently, and the routine from which control is being returned is called many, many times over. However, that is not a concern for my application. Regards, Doug -Original Message- From: IBM Mainframe Assembler List On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 10:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: [EXTERNAL] Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c)
Re: Base-less macros
Thanks everyone! Seymour, I don't see anywhere that Branch Relative on Condition takes an "index register". Maybe I missed something? Charles, the macro I wrote has bounds checking (one of the reasons I wrote it was because I found the potential for exactly the problem you mention). I may have gotten mixed up. I had started to use: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 DC A(RC0ROUTINE) DCA(RC4ROUTINE) DCA(RC8ROUTINE) and confused myself. I'm not real big on branch tables myself but they're cleaner than trying to use the select structured macro (IMO). Also, my intent was to hide a lot of the branch table weaknesses. From a LOOONG time ago, the original IBM C compiler implemented branch tables for switch/case. Steve, I need to investigate BAS. Thought about BAL but guess I never "equated" the two. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) On Tue, Nov 23, 2021 at 11:13 AM Seymour J Metz wrote: > The problem isn't branch tables; the problem is code that doesn't validate > its input. > > LTR R15,R15 > JMBADIX > CHI R15,LIMIT > JHBADIX > TML R15,3 > JNZ BADIX > J *+4(R15) > BRTABEQU * > J RC0ROUTINE > J RC4ROUTINE > J RC8ROUTINE > LIMITEQU *-BRTAB > > > > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Charles Mills [charl...@mcn.org] > Sent: Tuesday, November 23, 2021 11:24 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > Should that second instruction be an LA? > > I quit using branch tables. I know, they are useful, but IMHO wild > branches are the worst of bugs, and so I have eschewed branch tables. > > The architecture could use a new instruction "branch relative indexed" or > JI. So then your original code would become > > JI *+4(15) > JRC0ROUTINE > JRC4ROUTINE > JRC8ROUTINE > > Charles > > > -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Mark Hammack > Sent: Tuesday, November 23, 2021 7:42 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > So as a related question, I started working on a 'baseless' version of a > branch table macro I wrote years ago. I have it working but was curious > what other people have done. > > In 'based' code, it typically generates something like: > > B *+4(15) > BRC0ROUTINE > BRC4ROUTINE > BRC8ROUTINE > etc. > > The best I could come up with for 'baseless' code is: > > LARL 14,*+((48+32+16)/8) > L 14,0(15,14) > BR 14 > JRC0ROUTINE > JRC4ROUTINE > JRC8ROUTINE > > As to the specific question asked in the thread, I recently ran into an > issue where a macro expanded by a couple of bytes which threw the literals > out of the 4k 'base'. The way I took care of *most* of the issue was to go > with immediate, long displacement or relative instructions as much as > possible which all but eliminated the need for an LTORG or at least reduced > the need for multiple LTORGs in the program. >
Re: Base-less macros
? What is a shorter way to do the error checking? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Martin Ward [mar...@gkc.org.uk] Sent: Tuesday, November 23, 2021 12:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 23/11/2021 17:12, Seymour J Metz wrote: > LTR R15,R15 > JMBADIX > CHI R15,LIMIT > JHBADIX > TML R15,3 > JNZ BADIX > J *+4(R15) > BRTABEQU * > J RC0ROUTINE > J RC4ROUTINE > J RC8ROUTINE > LIMITEQU *-BRTAB Three test and branch instruction pairs plus two unconditional branch instructions, all to avoid executing a sequence of up to three test and branch instruction pairs :-) -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://secure-web.cisco.com/1Pzh0mz_8aE1yk4Zn65QdgWKxjXTYuplR0LTSWVThm5eBwv_XGYMaTUu-chekxBfi6Q9025E8Qko7Tv2AfAq4VKpPXZJATEnvK9yfCADRqS-MqJ-9CwXhQPcVAUaaVJisVYqePQcB1EgYhTEXUg6EMsRZGoSZYmbdXVC6DKXq6U8r16EOSntjBUqgbf2JkfOl98-JPqYFjgE8_O2ukkHD0bNk7EcYVFjZpL1RJqnISm5qT4Y1PLZTFqF7W4RLN3SouhBZKmQy9KILd6gufPlqfnEZ6XXLr886LHYJ7D4RI2pkwR_tUPju4DD8dBYH0dI5vbdm4BN1zPlh0lAnJdlARc5rcXUCQ658_9kIqdQ2ssUV8SW7IqhNvqBrN5QJARIDeNc6W-Q-LfKdo7Pk9GyTpPv0B3hR9SkveNdRnWPBZDBmkTzbbHhclfSRqf0xnmsZ/http%3A%2F%2Fwww.gkc.org.uk G.K.Chesterton site: http://secure-web.cisco.com/1OoGY6MPQRndcjIvC1a1r8dwvjRs0IiXumRn9B23l7Qi4vovkS4Ad8DCdEzjy7ZIxLBepUzkEB_3bndzCEBbgp6ItZFwrsQSie-z0aU7oWtR4pD-YS5UwnfKWFfEM53hm7XEj8GMpX_xgRvBYE6TI0wql6IHyekYniK7_TXAPyRNm18FqTVb_EXc24xGkuM4ixs2eE2TlFlZFIZKuIvQCgjZs600JXzVB2Caqp-MsKzLomt4z2p5Y3oxjZF9k0tWw8BKgGSN-e2OHTuv1dZfxbT7sMdFq0_P0TneTPOkY5JnRjmQK04uRe9mgyNatqGClUiwzLK4C7cShMxI2X-pM21gz0CRfnAG77jKiBGCgCVy-6Qak1MF7G9FPhX9rdPIB8sOIEruuQuHWc0VVU9Ps4UvPqQIKmmIbtqJ76rIR9-r-TwsRyxErjP4aJaZlW7MQ/http%3A%2F%2Fwww.gkc.org.uk%2Fgkc | Erdos number: 4
Re: Base-less macros
Still needs error checking on the low order bits. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Gary Weinhold [weinh...@dkl.com] Sent: Tuesday, November 23, 2021 12:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros How about fixing the problem you had with branch tables and introducing a new instruction JIC (branch relative indexed conditional)? JIC *+4(15),nn J RC0ROUTINE J RC4ROUTINE J RC8ROUTINE J RCERR_RTN Where nn is an immediate value hw that limits the value of RC and Jumps to *+4+(nn+4) if it is exceeded (last valid entry + 4) On 2021-11-23 11:24 a.m., Charles Mills wrote: > Should that second instruction be an LA? > > I quit using branch tables. I know, they are useful, but IMHO wild branches > are the worst of bugs, and so I have eschewed branch tables. > > The architecture could use a new instruction "branch relative indexed" or JI. > So then your original code would become > > JI *+4(15) > JRC0ROUTINE > JRC4ROUTINE > JRC8ROUTINE > > Charles > > > Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at http://secure-web.cisco.com/1Y1C7sTOZeugzGiFxXvjwJZdi_UTTwDN8wHtHeAawQMxyJnVQV01aV2fTbtQ358te4_9Dii-YSy-nvkDVZ0gnofUuXDXaUcMUlthJlqZvfke0ZfrB5ArOV4nUthd2eiGYKXcGf0VJxwYWimn7UyM3HNuwFLHvydH2tpG5oHSpGioHqqZrfM1ID10hDod6BsNyR2UZ2nAaMARKTGs3d5hJhRncsNX5RfPML-BnAuUdM5LuV0bads7x6QJlJQaCv9Rc1n9soWQedbBjxRR809MT50J1NX4SA-MiKYfU9BfgDPCR6XSpoHNujPnnljx-TMmlm-5KLKN-Uz5xUAoMeNHx9KZ-lT-nDb-76WmI0oofCmHtWSz4zXCx1cRdr2D3WAgl_cKFgD3c62nV1Ct1lJhIwC5Rc-wmWc0dUlqhgmT6LRVXWWay8QxH-ZwPrfy9jGor/http%3A%2F%2Fwww.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- > From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] > On Behalf Of Mark Hammack > Sent: Tuesday, November 23, 2021 7:42 AM > To:ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: Base-less macros > > So as a related question, I started working on a 'baseless' version of a > branch table macro I wrote years ago. I have it working but was curious > what other people have done. > > In 'based' code, it typically generates something like: > > B *+4(15) > BRC0ROUTINE > BRC4ROUTINE > BRC8ROUTINE > etc. > > The best I could come up with for 'baseless' code is: > > LARL 14,*+((48+32+16)/8) > L 14,0(15,14) > BR 14 > JRC0ROUTINE > JRC4ROUTINE > JRC8ROUTINE > > As to the specific question asked in the thread, I recently ran into an > issue where a macro expanded by a couple of bytes which threw the literals > out of the 4k 'base'. The way I took care of *most* of the issue was to go > with immediate, long displacement or relative instructions as much as > possible which all but eliminated the need for an LTORG or at least reduced > the need for multiple LTORGs in the program.
Re: Base-less macros
On 23/11/2021 17:12, Seymour J Metz wrote: LTR R15,R15 JMBADIX CHI R15,LIMIT JHBADIX TML R15,3 JNZ BADIX J *+4(R15) BRTABEQU * J RC0ROUTINE J RC4ROUTINE J RC8ROUTINE LIMITEQU *-BRTAB Three test and branch instruction pairs plus two unconditional branch instructions, all to avoid executing a sequence of up to three test and branch instruction pairs :-) -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Base-less macros
How about fixing the problem you had with branch tables and introducing a new instruction JIC (branch relative indexed conditional)? JIC *+4(15),nn J RC0ROUTINE J RC4ROUTINE J RC8ROUTINE J RCERR_RTN Where nn is an immediate value hw that limits the value of RC and Jumps to *+4+(nn+4) if it is exceeded (last valid entry + 4) On 2021-11-23 11:24 a.m., Charles Mills wrote: Should that second instruction be an LA? I quit using branch tables. I know, they are useful, but IMHO wild branches are the worst of bugs, and so I have eschewed branch tables. The architecture could use a new instruction "branch relative indexed" or JI. So then your original code would become JI *+4(15) JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE Charles Gary Weinhold Senior Application Architect DATAKINETICS | Data Performance & Optimization Phone:+1.613.523.5500 x216 Email: weinh...@dkl.com Visit us online at www.DKL.com E-mail Notification: The information contained in this email and any attachments is confidential and may be subject to copyright or other intellectual property protection. If you are not the intended recipient, you are not authorized to use or disclose this information, and we request that you notify us by reply mail or telephone and delete the original message from your mail system. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 7:42 AM To:ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program.
Re: Base-less macros
The problem isn't branch tables; the problem is code that doesn't validate its input. LTR R15,R15 JMBADIX CHI R15,LIMIT JHBADIX TML R15,3 JNZ BADIX J *+4(R15) BRTABEQU * J RC0ROUTINE J RC4ROUTINE J RC8ROUTINE LIMITEQU *-BRTAB -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Charles Mills [charl...@mcn.org] Sent: Tuesday, November 23, 2021 11:24 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Should that second instruction be an LA? I quit using branch tables. I know, they are useful, but IMHO wild branches are the worst of bugs, and so I have eschewed branch tables. The architecture could use a new instruction "branch relative indexed" or JI. So then your original code would become JI *+4(15) JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 7:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program.
Re: Base-less macros
Should that second instruction be an LA? I quit using branch tables. I know, they are useful, but IMHO wild branches are the worst of bugs, and so I have eschewed branch tables. The architecture could use a new instruction "branch relative indexed" or JI. So then your original code would become JI *+4(15) JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Mark Hammack Sent: Tuesday, November 23, 2021 7:42 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program.
Re: Base-less macros
Mark, (I do not really get the replacement-code. Maybe I did not look long enough) My solution to your problem: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE is this: LR15,=A(RC0ROUTINE,RC4ROUTINE,RC8ROUTINE)(15) BR R15 Preserves R14 (but eats up space in literal-pool) -- Martin
Re: Base-less macros
...some BASR R14, or JAS R14, etc. USING *,R14 B *+4(R15) DROP R14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE sas
Re: Base-less macros
So as a related question, I started working on a 'baseless' version of a branch table macro I wrote years ago. I have it working but was curious what other people have done. In 'based' code, it typically generates something like: B *+4(15) BRC0ROUTINE BRC4ROUTINE BRC8ROUTINE etc. The best I could come up with for 'baseless' code is: LARL 14,*+((48+32+16)/8) L 14,0(15,14) BR 14 JRC0ROUTINE JRC4ROUTINE JRC8ROUTINE As to the specific question asked in the thread, I recently ran into an issue where a macro expanded by a couple of bytes which threw the literals out of the 4k 'base'. The way I took care of *most* of the issue was to go with immediate, long displacement or relative instructions as much as possible which all but eliminated the need for an LTORG or at least reduced the need for multiple LTORGs in the program. *Mark Hammack* Systemware, Inc. Senior z/OS Developer mark.hamm...@gmail.com 214-478-0955 (c) On Sun, Nov 7, 2021 at 6:25 PM Tony Thigpen wrote: > I finally am to the point where I no longer need to worry about specific > customers having hardware that does not support relative instructions, > so I am updating some macros I provide to be baseless. > > What is the 'preferred' approach to macro generated constants? In the > past, I have used both inline constants that I branch around, and ltorg > literals (=c'x'). > > In the past, I have been bitten by using ltorg literals and the client > did not put a LTORG after my macro causing a 'no active base register' > issue. So, I am thinking inline with a BRAS is better. > > Maybe there is another approach that I missed? > > Suggestions? > > Tony Thigpen >
Re: Base-less macros
This draft document, entitled Register Constraint Relief 2021, coincidentally addresses the subject of Base-less/Base-free Macros. See references to Base Address Register (BAR) 15 and relative addressing for all base/displacement operands.. https://docs.google.com/document/d/19O8Z-H3XcgiDWOI_zO4NM8JnRHllGn91sFTDtgQ39bc/edit?usp=sharing OREXXMan Would you rather pass data in move mode (*nix piping) or locate mode (Pipes) or via disk (JCL)? Why do you think you rarely see *nix commands with more than a dozen filters, while Pipelines specifications are commonly over 100s of stages, and 1000s of stages are not uncommon. REXX is the new C. On Wed, Nov 10, 2021 at 3:02 AM Jonathan Scott wrote: > The documentation update for APAR PH34824, for the alignment of > literals referenced by relative address, has now been completed. > > https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=instruction-literal-pool > > It seems it was overlooked after being transferred from our old > request tool to the new - a case of "falling between two tools". > > Jonathan Scott, HLASM > IBM Hursley, UK >
Re: Avoiding SIIS - (Was Base-less macros)
Wendell wrote: > From Tony's explanation concerning moving the TR command to the data area via LOCTR, can I surmise that it might be counter-productive to do so--that leaving the TR and EX commands in consecutive memory is more efficient? My $0.02 is that I'm not so sure about the "do it once with length of 1, then do it for real with EX" approach, but what is mentioned in the Kevin Shum paper that Tony referenced is that you want the target of the EX instruction "close" to the EX itself, so that the target instruction might already be in the i-cache and won't have to be fetched. I usually try to place it like this: SUBROUTINE_1DS0H ... EXR2,EX_TARGET ... BRR14 . EX_TARGET MVC 0(*-*,R3),0(R4) . SUBROUTINE_2DS0H ... so that the EX target isn't in a data area, but is "close" to the EX itself. == Adam Johanson R Software Engineer adam.johan...@broadcom.com -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Re: Avoiding SIIS - (Was Base-less macros)
Sorry, senior moment. But it will do it twice, and the double traslate of the the first byte is probably not what you want. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Keith Moe [ke...@sbcglobal.net] Sent: Thursday, November 11, 2021 4:51 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Avoiding SIIS - (Was Base-less macros) Actually the inline TR/EX will do the TR the first time for ONE byte, not 256, followed by the EX of the specified length. Keith Moe BMC Software On Thursday, November 11, 2021, 01:44:07 PM PST, Seymour J Metz wrote: There are bigger problems than cache in that example; the EX/TR will translate twice, the first time with a length of 256. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Harminc [t...@harminc.com] Sent: Wednesday, November 10, 2021 11:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Avoiding SIIS - (Was Base-less macros) On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell <09624390d784-dmarc-requ...@listserv.uga.edu> wrote: > > I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could > someone please explain what happens to the D- and I-cache in these situations? I can tell you my understanding, but it's certainly not definitive. I just read the books that the people who really know write. Most probably none of these examples does a SIIS, but there isn't enough information to be 100% sure. I will assume that none of R14 in examples 1 and 2, or R5 in example 3, points anywhere near the code you are showing. I will also assume that a cache line is 256 bytes, as it is on all recent machines. (You can use the unprivileged ECAG instruction to ask the machine what the I- and D- cache line sizes are. But of course you can't take that run-time information and turn it back into input to the assembler. A Just In Time compiler, e.g. for Java could do and probably does do that.) > Example 1: > TxtTRNullTR0(*-*,R14),NoNulls > EX R5,*-6 No SIIS. The fetch of the target of EX/EXRL is defined to be an instruction fetch, so chances are the TR and the EX are in the same I-cache line, in which case that is the only I-cache line in use locally. If the TR happens to end on a cache line boundary, then fetching the EX will bring in another I-cache line. The line containing the TR is unlikely to be discarded, because it was just used. The two operands of TR could involve as many as two D-cache lines each, or as few as one in total, depending on where the operands lie. > Example 2: > PgmConst LOCTR , > TxtTRNullTR0(*-*,R14),NoNulls > PgmCodeLOCTR , > EX R5,TxtTRNull No SIIS. Almost the same as example 1, but the TR and EX are more likely to be in different cache lines because they're more likely to be further apart. You don't show it, but if the PgmConst area contains data as well as the TR instruction, then referencing that data will bring it into a D-cache line. It's not wrong to have this situation, and any performance hit should come only from the fact of having the same bytes in two cache lines, and therefore excluding some other info. I don't believe there is any direct interaction as long as nobody stores into either area. But note that that includes any code that stores into any part of the cache line, and that in turn includes code that may not be executed in a given case but that has been fetched and analysed as part of branch prediction. > Example 3: > GENCB BLK=ACB,AM=VSAM,MACRF=(KEY,DIR,SEQ,IN), > LOC=ANY,RMODE31=ALL, > MF=(G,(R5),GENCBLN) > +GENCBLN EQU 56LENGTH OF PARM LIST AREA USED > +CNOP 0,4 > +BAL 15,*+44BRANCH OVER CONSTANTS > +DCAL1(160)BLOCK TYPE CODE > +DCAL1(1)FUNCTION TYPE CODE > (16 "DC" lines removed) > +DCAL2(0) RESERVED@ > +DCB'1000' > +LR1,R5 POINT TO PARAMETER LIST AREA > +MVC 16(40,1),0(15) MOVE ACES TO AREA No SIIS. Some of the 40 bytes after the BAL 15,*+44 are likely to be in both kinds of cache line after MVC executes. Still no problem - again as long as nobody is storing into any part of the data that lives in the cache line. Oh - and after typing all that, here's the quote I've been looking for from the IBM Z / LinuxONE System Processor Optimization Primer that was mentioned here a few months ago: "No performance concern is expected with read-only copies of the same cache line
Re: Avoiding SIIS - (Was Base-less macros)
Actually the inline TR/EX will do the TR the first time for ONE byte, not 256, followed by the EX of the specified length. Keith Moe BMC Software On Thursday, November 11, 2021, 01:44:07 PM PST, Seymour J Metz wrote: There are bigger problems than cache in that example; the EX/TR will translate twice, the first time with a length of 256. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Harminc [t...@harminc.com] Sent: Wednesday, November 10, 2021 11:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Avoiding SIIS - (Was Base-less macros) On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell <09624390d784-dmarc-requ...@listserv.uga.edu> wrote: > > I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could > someone please explain what happens to the D- and I-cache in these situations? I can tell you my understanding, but it's certainly not definitive. I just read the books that the people who really know write. Most probably none of these examples does a SIIS, but there isn't enough information to be 100% sure. I will assume that none of R14 in examples 1 and 2, or R5 in example 3, points anywhere near the code you are showing. I will also assume that a cache line is 256 bytes, as it is on all recent machines. (You can use the unprivileged ECAG instruction to ask the machine what the I- and D- cache line sizes are. But of course you can't take that run-time information and turn it back into input to the assembler. A Just In Time compiler, e.g. for Java could do and probably does do that.) > Example 1: > TxtTRNull TR 0(*-*,R14),NoNulls > EX R5,*-6 No SIIS. The fetch of the target of EX/EXRL is defined to be an instruction fetch, so chances are the TR and the EX are in the same I-cache line, in which case that is the only I-cache line in use locally. If the TR happens to end on a cache line boundary, then fetching the EX will bring in another I-cache line. The line containing the TR is unlikely to be discarded, because it was just used. The two operands of TR could involve as many as two D-cache lines each, or as few as one in total, depending on where the operands lie. > Example 2: > PgmConst LOCTR , > TxtTRNull TR 0(*-*,R14),NoNulls > PgmCode LOCTR , > EX R5,TxtTRNull No SIIS. Almost the same as example 1, but the TR and EX are more likely to be in different cache lines because they're more likely to be further apart. You don't show it, but if the PgmConst area contains data as well as the TR instruction, then referencing that data will bring it into a D-cache line. It's not wrong to have this situation, and any performance hit should come only from the fact of having the same bytes in two cache lines, and therefore excluding some other info. I don't believe there is any direct interaction as long as nobody stores into either area. But note that that includes any code that stores into any part of the cache line, and that in turn includes code that may not be executed in a given case but that has been fetched and analysed as part of branch prediction. > Example 3: > GENCB BLK=ACB,AM=VSAM,MACRF=(KEY,DIR,SEQ,IN), > LOC=ANY,RMODE31=ALL, > MF=(G,(R5),GENCBLN) > +GENCBLN EQU 56 LENGTH OF PARM LIST AREA USED > + CNOP 0,4 > + BAL 15,*+44 BRANCH OVER CONSTANTS > + DC AL1(160) BLOCK TYPE CODE > + DC AL1(1) FUNCTION TYPE CODE > (16 "DC" lines removed) > + DC AL2(0) RESERVED @ > + DC B'1000' > + LR 1,R5 POINT TO PARAMETER LIST AREA > + MVC 16(40,1),0(15) MOVE ACES TO AREA No SIIS. Some of the 40 bytes after the BAL 15,*+44 are likely to be in both kinds of cache line after MVC executes. Still no problem - again as long as nobody is storing into any part of the data that lives in the cache line. Oh - and after typing all that, here's the quote I've been looking for from the IBM Z / LinuxONE System Processor Optimization Primer that was mentioned here a few months ago: "No performance concern is expected with read-only copies of the same cache line in both the instruction and data caches. The SIIS inefficiency occurs when the processor detects the same line is in both the instruction and data caches and the data cache's copy is potentially to be updated (including any conditional paths not expected to be executed), at which point an expensive cache synchronization action is needed. So long as both copies of the line in the instruction and data caches remain identical, the synchronization action does not oc
Re: Avoiding SIIS - (Was Base-less macros)
There are bigger problems than cache in that example; the EX/TR will translate twice, the first time with a length of 256. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Harminc [t...@harminc.com] Sent: Wednesday, November 10, 2021 11:53 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Avoiding SIIS - (Was Base-less macros) On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell <09624390d784-dmarc-requ...@listserv.uga.edu> wrote: > > I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could > someone please explain what happens to the D- and I-cache in these situations? I can tell you my understanding, but it's certainly not definitive. I just read the books that the people who really know write. Most probably none of these examples does a SIIS, but there isn't enough information to be 100% sure. I will assume that none of R14 in examples 1 and 2, or R5 in example 3, points anywhere near the code you are showing. I will also assume that a cache line is 256 bytes, as it is on all recent machines. (You can use the unprivileged ECAG instruction to ask the machine what the I- and D- cache line sizes are. But of course you can't take that run-time information and turn it back into input to the assembler. A Just In Time compiler, e.g. for Java could do and probably does do that.) > Example 1: > TxtTRNull TR0(*-*,R14),NoNulls > EX R5,*-6 No SIIS. The fetch of the target of EX/EXRL is defined to be an instruction fetch, so chances are the TR and the EX are in the same I-cache line, in which case that is the only I-cache line in use locally. If the TR happens to end on a cache line boundary, then fetching the EX will bring in another I-cache line. The line containing the TR is unlikely to be discarded, because it was just used. The two operands of TR could involve as many as two D-cache lines each, or as few as one in total, depending on where the operands lie. > Example 2: > PgmConst LOCTR , > TxtTRNull TR0(*-*,R14),NoNulls > PgmCodeLOCTR , > EX R5,TxtTRNull No SIIS. Almost the same as example 1, but the TR and EX are more likely to be in different cache lines because they're more likely to be further apart. You don't show it, but if the PgmConst area contains data as well as the TR instruction, then referencing that data will bring it into a D-cache line. It's not wrong to have this situation, and any performance hit should come only from the fact of having the same bytes in two cache lines, and therefore excluding some other info. I don't believe there is any direct interaction as long as nobody stores into either area. But note that that includes any code that stores into any part of the cache line, and that in turn includes code that may not be executed in a given case but that has been fetched and analysed as part of branch prediction. > Example 3: > GENCB BLK=ACB,AM=VSAM,MACRF=(KEY,DIR,SEQ,IN), > LOC=ANY,RMODE31=ALL, > MF=(G,(R5),GENCBLN) > +GENCBLN EQU 56LENGTH OF PARM LIST AREA USED > + CNOP 0,4 > + BAL 15,*+44 BRANCH OVER CONSTANTS > + DCAL1(160)BLOCK TYPE CODE > + DCAL1(1)FUNCTION TYPE CODE > (16 "DC" lines removed) > + DCAL2(0) RESERVED@ > + DCB'1000' > + LR1,R5 POINT TO PARAMETER LIST AREA > + MVC 16(40,1),0(15) MOVE ACES TO AREA No SIIS. Some of the 40 bytes after the BAL 15,*+44 are likely to be in both kinds of cache line after MVC executes. Still no problem - again as long as nobody is storing into any part of the data that lives in the cache line. Oh - and after typing all that, here's the quote I've been looking for from the IBM Z / LinuxONE System Processor Optimization Primer that was mentioned here a few months ago: "No performance concern is expected with read-only copies of the same cache line in both the instruction and data caches. The SIIS inefficiency occurs when the processor detects the same line is in both the instruction and data caches and the data cache's copy is potentially to be updated (including any conditional paths not expected to be executed), at which point an expensive cache synchronization action is needed. So long as both copies of the line in the instruction and data caches remain identical, the synchronization action does not occur, and there should be no performance penalty." > (Please forgive the formatting - it's tough to line things up in a > proportional font.) Virtually impossible. I see some of your lines well aligned; others not so much. But it's not uncomfortable to read, so thanks for taking the trouble. Tony H.
Re: Avoiding SIIS - (Was Base-less macros)
A CLC/EX or MVC/EX sequence is okay, albeit inefficient, but a TR/EX sequence would be bad news. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Wendell Lovewell [09624390d784-dmarc-requ...@listserv.uga.edu] Sent: Thursday, November 11, 2021 12:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Avoiding SIIS - (Was Base-less macros) Adam & Tony--thanks for the good explanations. >From Tony's explanation concerning moving the TR command to the data area via >LOCTR, can I surmise that it might be counter-productive to do so--that >leaving the TR and EX commands in consecutive memory is more efficient? > Example 2: > PgmConst LOCTR , > TxtTRNull TR0(*-*,R14),NoNulls > PgmCodeLOCTR , > EX R5,TxtTRNull In case anyone else is interested... https://www.ibm.com/support/pages/system/files/inline-files/siis_coding_examples_v2.pdf contains these guidelines: Contains some examples and guidelines: The following are general coding guidelines which should be followed to write well-formed Assembler code. • Don’t mix or interleave in instructions / executable code any data or operands which are the target of store or update operations. • Generate dummy areas of separation in a sufficient length at those locations where instruction and data/operands are adjacent to each other. An Assembler statement of the type: Label DC XL256’00’ can be used to brute force this objective. Of course, there are smarter ways to separate Instruction cache lines from data cache lines based on knowledge of the cache line boundaries. • Guarantee the 4k page alignment of any Assembler load module via the BINDER/LINKAGE Editor control statement PAGE: //LKED.SYSIN DD * PAGE DRIVER NAME DRIVER(R) • Where possible write to a re-entrant standard. Thanks again, Wendell
Re: Avoiding SIIS - (Was Base-less macros)
Adam & Tony--thanks for the good explanations. From Tony's explanation concerning moving the TR command to the data area via LOCTR, can I surmise that it might be counter-productive to do so--that leaving the TR and EX commands in consecutive memory is more efficient? > Example 2: > PgmConst LOCTR , > TxtTRNull TR0(*-*,R14),NoNulls > PgmCodeLOCTR , > EX R5,TxtTRNull In case anyone else is interested... https://www.ibm.com/support/pages/system/files/inline-files/siis_coding_examples_v2.pdf contains these guidelines: Contains some examples and guidelines: The following are general coding guidelines which should be followed to write well-formed Assembler code. • Don’t mix or interleave in instructions / executable code any data or operands which are the target of store or update operations. • Generate dummy areas of separation in a sufficient length at those locations where instruction and data/operands are adjacent to each other. An Assembler statement of the type: Label DC XL256’00’ can be used to brute force this objective. Of course, there are smarter ways to separate Instruction cache lines from data cache lines based on knowledge of the cache line boundaries. • Guarantee the 4k page alignment of any Assembler load module via the BINDER/LINKAGE Editor control statement PAGE: //LKED.SYSIN DD * PAGE DRIVER NAME DRIVER(R) • Where possible write to a re-entrant standard. Thanks again, Wendell
Re: Avoiding SIIS - (Was Base-less macros)
If size isn't a problem: "skel64" is csect name: * Round start of data to next 256-byte boundary to separate from ipipe zArchorg skel64+(((*+256)-skel64)/256)*256 LTORG
Re: Avoiding SIIS - (Was Base-less macros)
On Wed, 10 Nov 2021 at 11:45, Wendell Lovewell <09624390d784-dmarc-requ...@listserv.uga.edu> wrote: > > I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could > someone please explain what happens to the D- and I-cache in these situations? I can tell you my understanding, but it's certainly not definitive. I just read the books that the people who really know write. Most probably none of these examples does a SIIS, but there isn't enough information to be 100% sure. I will assume that none of R14 in examples 1 and 2, or R5 in example 3, points anywhere near the code you are showing. I will also assume that a cache line is 256 bytes, as it is on all recent machines. (You can use the unprivileged ECAG instruction to ask the machine what the I- and D- cache line sizes are. But of course you can't take that run-time information and turn it back into input to the assembler. A Just In Time compiler, e.g. for Java could do and probably does do that.) > Example 1: > TxtTRNull TR0(*-*,R14),NoNulls > EX R5,*-6 No SIIS. The fetch of the target of EX/EXRL is defined to be an instruction fetch, so chances are the TR and the EX are in the same I-cache line, in which case that is the only I-cache line in use locally. If the TR happens to end on a cache line boundary, then fetching the EX will bring in another I-cache line. The line containing the TR is unlikely to be discarded, because it was just used. The two operands of TR could involve as many as two D-cache lines each, or as few as one in total, depending on where the operands lie. > Example 2: > PgmConst LOCTR , > TxtTRNull TR0(*-*,R14),NoNulls > PgmCodeLOCTR , > EX R5,TxtTRNull No SIIS. Almost the same as example 1, but the TR and EX are more likely to be in different cache lines because they're more likely to be further apart. You don't show it, but if the PgmConst area contains data as well as the TR instruction, then referencing that data will bring it into a D-cache line. It's not wrong to have this situation, and any performance hit should come only from the fact of having the same bytes in two cache lines, and therefore excluding some other info. I don't believe there is any direct interaction as long as nobody stores into either area. But note that that includes any code that stores into any part of the cache line, and that in turn includes code that may not be executed in a given case but that has been fetched and analysed as part of branch prediction. > Example 3: > GENCB BLK=ACB,AM=VSAM,MACRF=(KEY,DIR,SEQ,IN), > LOC=ANY,RMODE31=ALL, > MF=(G,(R5),GENCBLN) > +GENCBLN EQU 56LENGTH OF PARM LIST AREA USED > + CNOP 0,4 > + BAL 15,*+44 BRANCH OVER CONSTANTS > + DCAL1(160)BLOCK TYPE CODE > + DCAL1(1)FUNCTION TYPE CODE > (16 "DC" lines removed) > + DCAL2(0) RESERVED@ > + DCB'1000' > + LR1,R5 POINT TO PARAMETER LIST AREA > + MVC 16(40,1),0(15) MOVE ACES TO AREA No SIIS. Some of the 40 bytes after the BAL 15,*+44 are likely to be in both kinds of cache line after MVC executes. Still no problem - again as long as nobody is storing into any part of the data that lives in the cache line. Oh - and after typing all that, here's the quote I've been looking for from the IBM Z / LinuxONE System Processor Optimization Primer that was mentioned here a few months ago: "No performance concern is expected with read-only copies of the same cache line in both the instruction and data caches. The SIIS inefficiency occurs when the processor detects the same line is in both the instruction and data caches and the data cache's copy is potentially to be updated (including any conditional paths not expected to be executed), at which point an expensive cache synchronization action is needed. So long as both copies of the line in the instruction and data caches remain identical, the synchronization action does not occur, and there should be no performance penalty." > (Please forgive the formatting - it's tough to line things up in a > proportional font.) Virtually impossible. I see some of your lines well aligned; others not so much. But it's not uncomfortable to read, so thanks for taking the trouble. Tony H.
Re: Avoiding SIIS - (Was Base-less macros)
For current processors, 256 bytes. Some IBMers talking with us on these topics suggested a macro called NEXTCLB, which inserts some space depending on some address arithmetic. IMO, if you use this, you could adjust it later if a future processor requires more. (256 is a constant used inside NEXTCLB). HTH, kind regards Bernd Am 10.11.2021 um 19:05 schrieb Schmitt, Michael: How do you ensure that your storage areas are far enough away from the code to not be in the instruction cache line, when your data isn't in GETMAIN storage? You can mitigate by putting constants in between, but how do you know if that's enough?
Re: Avoiding SIIS - (Was Base-less macros)
How do you ensure that your storage areas are far enough away from the code to not be in the instruction cache line, when your data isn't in GETMAIN storage? You can mitigate by putting constants in between, but how do you know if that's enough?
Re: Avoiding SIIS - (Was Base-less macros)
For the first 2 examples, those are not SIIS violations because no modification of storage takes place. The modification of the instruction happens in the core itself (I once heard it called the "instruction register" where this happens... I can't verify the validity of that statement). In the 3rd example, it depends on where R5 is pointing as to whether or not that's a SIIS violation. If where R5 points to contains instructions "close by", then yes. If it's a data-only area, then it's not a SIIS violation. To be a SIIS violation, you have to modify storage in the same CPU cache line where instructions reside. If the 3rd example didn't use MF= and modified the parmlist generated inline by the macro, then yes, that would be a SIIS violation as you're modifying storage that's intermixed with instructions. == Adam Johanson R Software Engineer adam.johan...@broadcom.com -- This electronic communication and the information and any files transmitted with it, or attached to it, are confidential and are intended solely for the use of the individual or entity to whom it is addressed and may contain information that is confidential, legally privileged, protected by privacy laws, or otherwise restricted from disclosure to anyone else. If you are not the intended recipient or the person responsible for delivering the e-mail to the intended recipient, you are hereby notified that any use, copying, distributing, dissemination, forwarding, printing, or copying of this e-mail is strictly prohibited. If you received this e-mail in error, please return the e-mail to the sender, delete it from your computer, and destroy any printed copy of it.
Avoiding SIIS - (Was Base-less macros)
I'm reluctant to admit this, but I'm still unclear about SIIS issues. Could someone please explain what happens to the D- and I-cache in these situations? Example 1: TxtTRNull TR0(*-*,R14),NoNulls EX R5,*-6 Example 2: PgmConst LOCTR , TxtTRNull TR0(*-*,R14),NoNulls PgmCodeLOCTR , EX R5,TxtTRNull Example 3: GENCB BLK=ACB,AM=VSAM,MACRF=(KEY,DIR,SEQ,IN), LOC=ANY,RMODE31=ALL, MF=(G,(R5),GENCBLN) +GENCBLN EQU 56LENGTH OF PARM LIST AREA USED + CNOP 0,4 + BAL 15,*+44 BRANCH OVER CONSTANTS + DCAL1(160)BLOCK TYPE CODE + DCAL1(1)FUNCTION TYPE CODE (16 "DC" lines removed) + DCAL2(0) RESERVED@ + DCB'1000' + LR1,R5 POINT TO PARAMETER LIST AREA + MVC 16(40,1),0(15) MOVE ACES TO AREA (Please forgive the formatting - it's tough to line things up in a proportional font.) Thanks, Wendell
Re: Base-less macros
The documentation update for APAR PH34824, for the alignment of literals referenced by relative address, has now been completed. https://www.ibm.com/docs/en/hla-and-tf/1.6?topic=instruction-literal-pool It seems it was overlooked after being transferred from our old request tool to the new - a case of "falling between two tools". Jonathan Scott, HLASM IBM Hursley, UK
Re: Base-less macros
If you provide the option of specifying labels or literals, it is up to the end user to provide addressability to the literals. I would not be against a keyword such as PERFORMANCE=CRAP to force the data items inline so that no end-user data area is needed. On Mon, 8 Nov 2021 09:09:42 +0100 Bernd Oppolzer wrote: :>IMHO, if you are a macro provider and have no control on the environment :>provided by the open code (which comes from the customer's programmer), :>the literal approach is more dangerous, because it assumes that the :>programmer :>will provide space and addressibility for the literals. :> :>Doing LTORG yourself cannot work, as you mentioned already, because you :>risk :>to activate literals collected by the client's open code. This will lead :>to problems, IMO. :> :>This said, I would try to avoid constant definitions in such macros, if :>possible. :>Use instructions with immediate operands instead. :> :>If you absolutely need constants, then in a baseless environment you :>must IMO :>establish a temporary base register, for example using register 1, 14 or :>15, :>which you maybe change anyway during your macro expansion. :> :>The answers of some other posters which relate to general program layout :>don't :>really help in this situation, because you cannot control this when you :>simply :>provide a (third party) macro used by the customer's application :>programmers. :> :>HTH, kind regards :> :>Bernd :> :> :>Am 08.11.2021 um 01:25 schrieb Tony Thigpen: :>> I finally am to the point where I no longer need to worry about :>> specific customers having hardware that does not support relative :>> instructions, so I am updating some macros I provide to be baseless. :>> :>> What is the 'preferred' approach to macro generated constants? In the :>> past, I have used both inline constants that I branch around, and :>> ltorg literals (=c'x'). :>> :>> In the past, I have been bitten by using ltorg literals and the client :>> did not put a LTORG after my macro causing a 'no active base register' :>> issue. So, I am thinking inline with a BRAS is better. :>> :>> Maybe there is another approach that I missed? :>> :>> Suggestions? :>> :>> Tony Thigpen -- Binyamin Dissen http://www.dissensoftware.com Director, Dissen Software, Bar & Grill - Israel
Re: Base-less macros
Addressability is much less of an issue than it was on S/360. Just how big are you csects? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ed Jaffe [edja...@phoenixsoftware.com] Sent: Tuesday, November 9, 2021 1:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 11/9/2021 9:55 AM, Seymour J Metz wrote: > LOCTR may not help with literals, but it can help with macros that generate a > DC. Instead of branching around the constant, put a LOCTR before and after it. There is no guarantee a existing USING is in place for a literal or DC in a given LOCTR. The LARL technique improves certainty considerably, but nothing is as certain as branching around a literal constant. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1PDtnWMdQQmYtXWR_mcf-nKXnjdfCFifFjtZUgQV8jCcndfNiu5XLK8g6rzSe6-4sugmH3Smh22WNj-t9SU0BKMMqus3QdTsCO3gLnvF60habcUjrsLGg-pAYlYfJR1SUEpv5_PeQSGyCzSpNWDpkoYeZi7xqRGjsV08q9ZPorv5NkJej_Nfq71rArW-14ctBOdeZyN035V7nNSjGFzccF-qgW1ZTlnInVq4N9nnkbspJ1pEojwJx1S-JOnIhSFaoXrJxJSQ9jKXheMZZFf40ugrcqOr0Ogd7SAQrrG1ER_5cbpDlyZEiOzDF6C1UZF0FYCvidwqry-K5LmrwUH5347XOOZdAyHqr-2VJep3XryCQBCM2chJZN6bsFvw1tGN5RQCNNuqf1pSpaD9kjeMzVSbr1KRKWK2mGW5XqQW7Y9CrN7KhJRo9yUjY2hu84YzY/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Base-less macros
On 11/9/2021 9:55 AM, Seymour J Metz wrote: LOCTR may not help with literals, but it can help with macros that generate a DC. Instead of branching around the constant, put a LOCTR before and after it. There is no guarantee a existing USING is in place for a literal or DC in a given LOCTR. The LARL technique improves certainty considerably, but nothing is as certain as branching around a literal constant. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
