Re: BAKR Instruction
On 2018-05-30, at 06:13:04, Tom Marchant wrote: > > But if your callers are all AMODE 24 or 31, and use BASR or BALR to call you, > and the BALR is not the target of an Execute instruction, the linkage > information is adequate for return via BSM. > > In all of these cases, if your caller is AMODE 31, the high bit of R14 will > be 1, > and if your caller is AMODE 24,the high bit will be 0. > However, if the caller uses BAL rather than BALR, the high bit will be 1. > In that limited situation, it is possible to change the return instruction to > BSM before the calling programs are changed to BASSM. -- gil
Re: BAKR Instruction
On Wed, 30 May 2018 07:40:27 -0400, Peter Relson wrote: >One point about "phasing in" BASSM: it does not work in general. Sure, if >you "phase in" by changing all the callers at the same time, that works. That's true Peter. There are cases where the approach that I suggested do not work. Most notably, AMODE 64 callers. But if your callers are all AMODE 24 or 31, and use BASR or BALR to call you, and the BALR is not the target of an Execute instruction, the linkage information is adequate for return via BSM. In all of these cases, if your caller is AMODE 31, the high bit of R14 will be 1, and if your caller is AMODE 24,the high bit will be 0. In that limited situation, it is possible to change the return instruction to BSM before the calling programs are changed to BASSM. -- Tom Marchant
BAKR Instruction
One point about "phasing in" BASSM: it does not work in general. Sure, if you "phase in" by changing all the callers at the same time, that works. That is because the target program, if it wants to protect some potential calling possibilities needs to capture the current AMODE so that the value saved on BAKR and then used on PR returns properly. A typical protocol is this: BSM 14,0 BAKR 14,0 ... PR This works if the call is via BASR/BALR/BRAS/BRASL. This does not work if call is via BASSM. If your routine currently supports entry in AMODE 64 via BASR and uses BAKR/PR, you probably have something like this (because otherwise AMODE 64 will not return properly). The conclusion: you need to know whether the call is via BASSM (or BSM) or not. You can code for either. You cannot code for both (or perhaps you can, but it is not trivial). Peter Relson z/OS Core Technology Design
Re: BAKR Instruction
A fairer comparison would be BAKR/PR versus *all* of the code they replace, including allocating and freeing the save area. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Christopher Y. Blaicher Sent: Tuesday, May 29, 2018 2:12 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: BAKR Instruction A quick test of performance shows that BAKR/PR is about 14 times as expensive as STM/LM. I would say that in in initialization/termination code using BAKR/PR isn't going to hurt you, but I would totally avoid it in record level code. Chris Blaicher Technical Architect Mainframe Development P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com Syncsort Incorporated 2 Blue Hill Plaza #1563 Pearl River, NY 10965 http://secure-web.cisco.com/1X0mfy4VID7QDUXyaHL1ueJtnlfgYmc8sjtccCZgMX3epgL8k1vd7anQG43ATPZ6AG7QdZZbfvSXnZ7IkFvGrWi_hHgyqSHyQNcS7y1SCVb3rDucJsf4rKrn__Es2_or9TPke1DtoRCRON1JjFo94LXnjJmhgHm3T-xHHd9xv1paxVtP7IP6VkjDVe0Ud-0Gsu9MvgJq7DmD499vGREELS0aVb0ATwKQJ6Gela70fVfs9g-5ZzYDhZYFtmexcx2AD1L5rR03neWOTnfiw9C2Znq4p4xl-HedSLx8KtRA9ZZDy1l4IVw54nYMrgbkNZky-2CTneyWyp4-2quboqVDV6a6pVHG9D4HiWf6DtdVUO5heNeyV30njmXk0x-1Fi_MaSX9AhQT7vuTlStF2FEq1owH6sv14eCstOCdPqiZ-39BrBx3v2i--fWG6-6i6jvXW/http%3A%2F%2Fwww.syncsort.com Data quality leader Trillium Software is now a part of Syncsort. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, May 29, 2018 2:00 PM To: MVS List Server 2 Subject: Re: BAKR Instruction *Any* choice of linkage conventions imposes a dependency between the caller and the callee. BTW, this is an example of why I prefer to encapsulate such things in macros. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: Monday, May 28, 2018 5:57 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: BAKR Instruction Some things to think about: -- Recovery routines and retry points are tied to specific linkage stack levels in the general case. Use of BAKR as a linkage can complicate that. -- BAKR/PR is slower than using a typical savearea linkage. -- You might find that use of BAKR by the caller poses an unnecessary dependency between the caller and the callee. Consider the alternative of calling via BASR, and the callee deciding whether to save/restore regs via BAKR/PR or via STMG(+STAM)/LMG(+LAM). Peter Relson z/OS Core Technology Design
Re: BAKR Instruction
On 29/05/18 19:12, Christopher Y. Blaicher wrote: A quick test of performance shows that BAKR/PR is about 14 times as expensive as STM/LM. I would say that in in initialization/termination code using BAKR/PR isn't going to hurt you, but I would totally avoid it in record level code. How expensive is it compared to reading a file record? -- 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: BAKR Instruction
A quick test of performance shows that BAKR/PR is about 14 times as expensive as STM/LM. I would say that in in initialization/termination code using BAKR/PR isn't going to hurt you, but I would totally avoid it in record level code. Chris Blaicher Technical Architect Mainframe Development P: 201-930-8234 | M: 512-627-3803 E: cblaic...@syncsort.com Syncsort Incorporated 2 Blue Hill Plaza #1563 Pearl River, NY 10965 www.syncsort.com Data quality leader Trillium Software is now a part of Syncsort. -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, May 29, 2018 2:00 PM To: MVS List Server 2 Subject: Re: BAKR Instruction *Any* choice of linkage conventions imposes a dependency between the caller and the callee. BTW, this is an example of why I prefer to encapsulate such things in macros. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: Monday, May 28, 2018 5:57 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: BAKR Instruction Some things to think about: -- Recovery routines and retry points are tied to specific linkage stack levels in the general case. Use of BAKR as a linkage can complicate that. -- BAKR/PR is slower than using a typical savearea linkage. -- You might find that use of BAKR by the caller poses an unnecessary dependency between the caller and the callee. Consider the alternative of calling via BASR, and the callee deciding whether to save/restore regs via BAKR/PR or via STMG(+STAM)/LMG(+LAM). Peter Relson z/OS Core Technology Design
Re: BAKR Instruction
*Any* choice of linkage conventions imposes a dependency between the caller and the callee. BTW, this is an example of why I prefer to encapsulate such things in macros. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: Monday, May 28, 2018 5:57 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: BAKR Instruction Some things to think about: -- Recovery routines and retry points are tied to specific linkage stack levels in the general case. Use of BAKR as a linkage can complicate that. -- BAKR/PR is slower than using a typical savearea linkage. -- You might find that use of BAKR by the caller poses an unnecessary dependency between the caller and the callee. Consider the alternative of calling via BASR, and the callee deciding whether to save/restore regs via BAKR/PR or via STMG(+STAM)/LMG(+LAM). Peter Relson z/OS Core Technology Design
Re: BAKR Instruction
One way to find out whether you need those save is to use a linkage that doesn't save them and get a call at 0 dark hundred when things blow up. Unless you know that you don't need to save them, play safe. IMHO. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Dan Greiner Sent: Monday, May 28, 2018 7:49 PM To: ASSEMBLER-LIST@listserv.uga.edu Subject: Re: BAKR Instruction Mr. Relson's warnings on the performance of BAKR/PR warrant some additional comment. 1. A well-tuned subroutine call can limit the number of registers that are saved/restored. BAKR/PR saves/restores all 16 general-purpose registers, and it always saves all 64-bits of the register, even if the program is operating in the 24- or 31-bit addressing mode. Most likely, this will not be observable, but if you're doing it a gazillion times a second, your mileage may vary. 2. BAKR/PR saves the 16 access registers, regardless of whether the program is operating in the AR mode. 3. BAKR/PR saves the program-key mask (PKM), secondary address-space number (SASN), extended-authorization index (EAX), and primary address-space number (PASN), regardless of whether the program gives a hoot about cross-memory operation. If the ASN-and-LX-reuse facility is installed, the primary and secondary-ASTE-instance numbers are also saved/restored. Unless you specifically need these features of BAKR, you might want to look elsewhere. Unlike other program-stack models (e.g., Unix & Linux) where the program can easily (and, perhaps, maliciously) manipulate the contents of the stack, the linkage stack is semi-hidden from the program. Selected portions of the most-recently-created stack entry can be extracted, and a doubleword modifiable area can be modified via ESTA and MSTA, respectively. But this ain't your classic C programming model.
Re: BAKR Instruction
Hi Dan, I'm with Gary... would love a copy of your presentation. Thanks, Russ Russell W. Teubner HostBridge Technology: www.hostbridge.com www.linkedin.com/in/rteubner -Original Message- From: IBM Mainframe Assembler List On Behalf Of Gary Weinhold Sent: Tuesday, May 29, 2018 7:11 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BAKR Instruction Hi, Dan, I hope all continues well with you. Has retirement kept you busy? We hope to see Howard in late June, if he ever answers his emails! Could you send me the powerpoint for this presentation. I have the pdf, but i always appreciated the powerpoint. Regards, Gary On 2018-05-28 2:44 PM, Dan Greiner wrote: > In 2012, I did a presentation at SHARE in Atlanta on the details of the > dual-address-space (DAS) and linkage-stack (LS) architecture which > includes BAKR and PR. Most likely, this contains far more detail than any > sane person would want to know, but it's easier to digest than the > description in the PoO. > > The Assembler List section of the UGA list server doesn't support > attachments or I would have posted it here. If you would like a copy, > please contact me via email, and I'll forward you a PowerPoint file. > (Please don't repost your request here.) 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: BAKR Instruction
In defense of BAKR/PR, please note that while it is a pig (relatively) it is a very useful pig. As mentioned before, in most cases the extra overhead likely won't matter much. We use it in a pretty big code-base that wanders through every mode swing you can think of. It's very useful that when you execute PR, all sins are forgiven. Not having to deal with save areas is a bonus. That said, we don't use it for extremely frequent calls; especially if it turns up as a hot-spot on Strobe. sas
Re: BAKR Instruction
On Mon, 28 May 2018 17:06:14 -0700, Ed Jaffe wrote: >might I respectfully suggest BASSM/BSM >linkage be used instead of BASR/BR? Good advice, IMO. And note that the linkage information provided by BALR and BASR is such that it is safe to use BSM when returning to a calling program that used one of those instructions. Therefore, it is possible to phase in the use of BASSM/BSM into existing code. -- Tom Marchant
Re: BAKR Instruction
Hi, Dan, I hope all continues well with you. Has retirement kept you busy? We hope to see Howard in late June, if he ever answers his emails! Could you send me the powerpoint for this presentation. I have the pdf, but i always appreciated the powerpoint. Regards, Gary On 2018-05-28 2:44 PM, Dan Greiner wrote: In 2012, I did a presentation at SHARE in Atlanta on the details of the dual-address-space (DAS) and linkage-stack (LS) architecture which includes BAKR and PR. Most likely, this contains far more detail than any sane person would want to know, but it's easier to digest than the description in the PoO. The Assembler List section of the UGA list server doesn't support attachments or I would have posted it here. If you would like a copy, please contact me via email, and I'll forward you a PowerPoint file. (Please don't repost your request here.) 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: BAKR Instruction
On 5/28/2018 2:57 PM, Peter Relson wrote: -- You might find that use of BAKR by the caller poses an unnecessary dependency between the caller and the callee. Consider the alternative of calling via BASR, and the callee deciding whether to save/restore regs via BAKR/PR or via STMG(+STAM)/LMG(+LAM). I find that BASR imposes an unnecessary dependency between the caller and callee in that the callee is generally expected to be running in the same AMODE as the caller or at the very least callee's address must be reachable in the caller's current AMODE. I realize BAKR does not set/change AMODE and therefore my suggestion may be slightly off topic but, in this tri-modal, 21st-Century world in which we find ourselves coding, might I respectfully suggest BASSM/BSM linkage be used instead of BASR/BR? That's what we now do *everywhere* for cross-program linking -- we still use BAS/BASR/JAS/JASL for same-program linking -- and have not once (yet) regretted the time spent performing that mass conversion... -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 http://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.
Re: BAKR Instruction
Mr. Relson's warnings on the performance of BAKR/PR warrant some additional comment. 1. A well-tuned subroutine call can limit the number of registers that are saved/restored. BAKR/PR saves/restores all 16 general-purpose registers, and it always saves all 64-bits of the register, even if the program is operating in the 24- or 31-bit addressing mode. Most likely, this will not be observable, but if you're doing it a gazillion times a second, your mileage may vary. 2. BAKR/PR saves the 16 access registers, regardless of whether the program is operating in the AR mode. 3. BAKR/PR saves the program-key mask (PKM), secondary address-space number (SASN), extended-authorization index (EAX), and primary address-space number (PASN), regardless of whether the program gives a hoot about cross-memory operation. If the ASN-and-LX-reuse facility is installed, the primary and secondary-ASTE-instance numbers are also saved/restored. Unless you specifically need these features of BAKR, you might want to look elsewhere. Unlike other program-stack models (e.g., Unix & Linux) where the program can easily (and, perhaps, maliciously) manipulate the contents of the stack, the linkage stack is semi-hidden from the program. Selected portions of the most-recently-created stack entry can be extracted, and a doubleword modifiable area can be modified via ESTA and MSTA, respectively. But this ain't your classic C programming model.
Re: BAKR Instruction
Some things to think about: -- Recovery routines and retry points are tied to specific linkage stack levels in the general case. Use of BAKR as a linkage can complicate that. -- BAKR/PR is slower than using a typical savearea linkage. -- You might find that use of BAKR by the caller poses an unnecessary dependency between the caller and the callee. Consider the alternative of calling via BASR, and the callee deciding whether to save/restore regs via BAKR/PR or via STMG(+STAM)/LMG(+LAM). Peter Relson z/OS Core Technology Design
Re: BAKR Instruction
You want BAKR 0,R15. Read the PoOp (closely) to understand why. sas On 5/27/2018 19:10, esst...@juno.com wrote: Hi, . Question About the BAKR Instruction . ... . Any Ideas as to how to proceed. . Paul D'Angelo . .
Re: BAKR Instruction
Hi, Paul -- In a BAKR R14,R15 instruction, the R14 value is the value to which the branched-to routine will return when it executes the PR. So your statement "Register 14 (operand 1) would contain the next sequential instruction" is correct if you're talking about the value of R14 _before_ the execution of the BAKR. If you want the branched-to routine to return to the instruction after the BAKR, you should code BAKR 0,R15. This will save the instruction after the BAKR as the return value in the linkage stack. Depending on what R14 was set to before the BAKR was executed, this would explain the behavior that you're seeing. The value in the register denoted by operand 1 (in this case R14) is unaffected by the BAKR instruction. HTH, Gary -Original Message- From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On Behalf Of esst...@juno.com Sent: Sunday, May 27, 2018 4:10 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: BAKR Instruction Hi, . Question About the BAKR Instruction . . I thought I understood the BAKR instruction. . I load the address of a load module into Register 15 Then I issue a BAKR R14,R15 . My understanding is that a Linkage stack entry is created And The PSW would be updated with the Address in R15 (operand 2). Register 14 (operand 1) would contain the next sequential instruction. . Do I understand this correctly. . The Sub-routine which was brought into memory via a LOAD does get invoked. . It does not have a BAKR not a SAVE macro as its first instruction. It actually issues an LARL instruction to set a Base Register and then issues a STORAGE OBTAIN to get working storage. . When The Sub-Routine exits and returns to the calling module. It issues a STORAGE Release and a Program Return (PR) instruction. . There is a WTO Identifying the SUB-Routine was entered and another WTO stating the SUB-Routine is exiting. . What it looks like - is the PR instruction returns to the beginning of the Sub-Routine as it goes into a loop producing thousands of wto Entering and Exiting Messages. . Any Ideas as to how to proceed. . Paul D'Angelo . .
BAKR Instruction
Hi, . Question About the BAKR Instruction . . I thought I understood the BAKR instruction. . I load the address of a load module into Register 15 Then I issue a BAKR R14,R15 . My understanding is that a Linkage stack entry is created And The PSW would be updated with the Address in R15 (operand 2). Register 14 (operand 1) would contain the next sequential instruction. . Do I understand this correctly. . The Sub-routine which was brought into memory via a LOAD does get invoked. . It does not have a BAKR not a SAVE macro as its first instruction. It actually issues an LARL instruction to set a Base Register and then issues a STORAGE OBTAIN to get working storage. . When The Sub-Routine exits and returns to the calling module. It issues a STORAGE Release and a Program Return (PR) instruction. . There is a WTO Identifying the SUB-Routine was entered and another WTO stating the SUB-Routine is exiting. . What it looks like - is the PR instruction returns to the beginning of the Sub-Routine as it goes into a loop producing thousands of wto Entering and Exiting Messages. . Any Ideas as to how to proceed. . Paul D'Angelo . .
