Generally, in my code I save the registers in the caller's savearea, then allocate a combined SAVEAREA/WORKAREA that I leave R13 pointing at. If one used BAKR/PR and didn't need any working storage, then your comparison would be valid and cheaper, but if you still need working storage, then BAKR/PR is just overhead.
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:18 PM To: MVS List Server 2 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Subject: 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 <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Christopher Y. Blaicher <cblaic...@syncsort.com> 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 <ASSEMBLER-LIST@LISTSERV.UGA.EDU> 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 <ASSEMBLER-LIST@listserv.uga.edu> on behalf of Peter Relson <rel...@us.ibm.com> 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
