Re: BASR to AMODE 64
Yes. +4GiB-1/-4Gib for relative branch long. e.g. BRCL. BRC is only +/- 64Kib -- Tom Marchant On Wed, 4 Dec 2019 16:28:40 +, Seymour J Metz wrote: >With a signed offset. > > >-- >Shmuel (Seymour J.) Metz >http://mason.gmu.edu/~smetz3 > > > >From: IBM Mainframe Assembler List on behalf >of Charles Mills >Sent: Wednesday, December 4, 2019 11:22 AM >To: ASSEMBLER-LIST@LISTSERV.UGA.EDU >Subject: Re: BASR to AMODE 64 > >Branch Relative handles an offset up to 4 GiB. > >Charles
Re: BASR to AMODE 64
With a signed offset. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Wednesday, December 4, 2019 11:22 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 Branch Relative handles an offset up to 4 GiB. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, December 3, 2019 2:28 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 > What does CSECT size have to do with base registers? It's no rocket science. The distance between an instruction and its target determines whether a relative instruction is possible. If the distance is too large then you need to access the target via a register.
Re: BASR to AMODE 64
Branch Relative handles an offset up to 4 GiB. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Tuesday, December 3, 2019 2:28 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 > What does CSECT size have to do with base registers? It's no rocket science. The distance between an instruction and its target determines whether a relative instruction is possible. If the distance is too large then you need to access the target via a register.
Re: BASR to AMODE 64
Gil wrote > > ... And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > Are cross-CSECT relative branches supported? That feels like an invitation to disaster: errors that can not be detected before execution. Not a problem. The binder knows about external references and calculates the needed value to be placed within the instruction text. It's not conceptually different than loading a v-con (or EXTRN with A-Con) and branching to it -- if the external reference wasn't resolvable, you'd have gotten a bind-time warning. In both cases the target needs to be known to the assembler as an external reference. Steve Smith wrote It occurred to me that an RMODE SPLIT program could blithely branch back and forth between below and above-the-line CSECTs as long as relative-long branches were used to make the jumps. RMODE SPLIT is the answer to my teaser. That's exactly what can be done, as long as the segments are not RMODE 64 (for which case the difference in location between brancher and branchee can exceed the size representable in the instruction text). Obviously the binder cannot determine the proper instruction text for such a cross-segment branch since it is dependent on where the storage for the two segments lands. This construct is represented by a particular type of relocation entry that the loader resolves when the module is fetched. Peter Relson z/OS Core Technology Design
Re: BASR to AMODE 64 (Baseless code)
I disagree; good practice is to start your code at offset zero and put your data in a LOCTR that goes at the end. But if you want to do it the other way, there is no need to branch around anything. What is the oldest processor you have to support? If you are allowed to use relative, then the size limit is much larger. The Devil is in the details. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Jon Perryman Sent: Monday, December 2, 2019 8:51 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > In the source? Branch around them or use LOCTR? What difference > does it make as long as instructions plus data do not exceed 4Ki? For programs that don't use a base register for the code, good coding practices requires LOCTR be used to place constants at the beginning of your program (with branch around). As long as constants never exceed 4KB, the program won't need to be reworked to free a register. > dissension about whether control block definitions should > precede or follow instructions. > And the former group was biased by experience with languages > which required symbols defined before reference. CB location in the source is not always cosmetic because of the macro language. I've worked on a product that will not assemble with the CB's at the end of source. The cosmetic problem of placing CB's at the beginning is no longer a problem because ISPF and SDSF editor allows lines to be hidden. Just write an edit macro to hide CB definitions. Jon.
Re: BASR to AMODE 64
> What does CSECT size have to do with base registers? It's no rocket science. The distance between an instruction and its target determines whether a relative instruction is possible. If the distance is too large then you need to access the target via a register. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Charles Mills Sent: Monday, December 2, 2019 10:54 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 What does CSECT size have to do with base registers? If I have constants in my CSECT and use "traditional" base/offset branches then I need a base register, no matter how small the CSECT. If I have neither of the above I do not need a base register, no matter how large the CSECT. No argument with your assertion that small is good. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 2, 2019 11:08 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 ObNit If you keep your CSECT to a reasonable size then there is no need for a base register to address the code. But if you have an obscenely large monolithic program you will still need a base register, plus a large bottle of aspirins.
Re: BASR to AMODE 64
I would expect the Binder to detect the error. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Tuesday, December 3, 2019 2:07 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 2019-12-03, at 07:10:42, Peter Relson wrote: > > ... And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > Are cross-CSECT relative branches supported? That feels like an invitation to disaster: errors that can not be detected before execution. -- gil
Re: BASR to AMODE 64 (Baseless code)
If it's large then you'll need three and if it's too long for Load Relative Long then you'll need four. I prefer to break things into smaller assemblies unless there is a good reason to assemble them together. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ngan, Robert Sent: Tuesday, December 3, 2019 4:27 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) We use TWO LOCTR's, one for constants required to be within 4K of the base register and a second for constants only referenced by relative long or long displacement instructions. Useful when your combined constants size exceeds 4K as it moves the "yonder" fields out of the 4K space. I wish there was easy way to aggregate the LTORG literals specifically into pre and (potentially) post 4K LTORGs. Robert Ngan -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jon Perryman Sent: Monday, December 2, 2019 19:51 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > In the source? Branch around them or use LOCTR? What difference > does it make as long as instructions plus data do not exceed 4Ki? For programs that don't use a base register for the code, good coding practices requires LOCTR be used to place constants at the beginning of your program (with branch around). As long as constants never exceed 4KB, the program won't need to be reworked to free a register. > dissension about whether control block definitions should > precede or follow instructions. > And the former group was biased by experience with languages which > required symbols defined before reference. CB location in the source is not always cosmetic because of the macro language. I've worked on a product that will not assemble with the CB's at the end of source. The cosmetic problem of placing CB's at the beginning is no longer a problem because ISPF and SDSF editor allows lines to be hidden. Just write an edit macro to hide CB definitions. Jon. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: BASR to AMODE 64 (Baseless code)
We use TWO LOCTR's, one for constants required to be within 4K of the base register and a second for constants only referenced by relative long or long displacement instructions. Useful when your combined constants size exceeds 4K as it moves the "yonder" fields out of the 4K space. I wish there was easy way to aggregate the LTORG literals specifically into pre and (potentially) post 4K LTORGs. Robert Ngan -Original Message- From: IBM Mainframe Assembler List On Behalf Of Jon Perryman Sent: Monday, December 2, 2019 19:51 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > In the source? Branch around them or use LOCTR? What difference > does it make as long as instructions plus data do not exceed 4Ki? For programs that don't use a base register for the code, good coding practices requires LOCTR be used to place constants at the beginning of your program (with branch around). As long as constants never exceed 4KB, the program won't need to be reworked to free a register. > dissension about whether control block definitions should > precede or follow instructions. > And the former group was biased by experience with languages which > required symbols defined before reference. CB location in the source is not always cosmetic because of the macro language. I've worked on a product that will not assemble with the CB's at the end of source. The cosmetic problem of placing CB's at the beginning is no longer a problem because ISPF and SDSF editor allows lines to be hidden. Just write an edit macro to hide CB definitions. Jon. DXC Technology Company - Headquarters: 1775 Tysons Boulevard, Tysons, Virginia 22102, USA. DXC Technology Company -- This message is transmitted to you by or on behalf of DXC Technology Company or one of its affiliates. It is intended exclusively for the addressee. The substance of this message, along with any attachments, may contain proprietary, confidential or privileged information or information that is otherwise legally exempt from disclosure. Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the intended recipient of this message, you are not authorized to read, print, retain, copy or disseminate any part of this message. If you have received this message in error, please destroy and delete all copies and notify the sender by return e-mail. Regardless of content, this e-mail shall not operate to bind DXC Technology Company or any of its affiliates to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.
Re: BASR to AMODE 64
On 12/3/2019 11:07 AM, Paul Gilmartin wrote: Are cross-CSECT relative branches supported? That feels like an invitation to disaster: errors that can not be detected before execution. They have been supported since z/OS 1.7 or 1.8. Very handy to have!!! -- 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.
Re: BASR to AMODE 64
On 2019-12-03, at 07:10:42, Peter Relson wrote: > > ... And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > Are cross-CSECT relative branches supported? That feels like an invitation to disaster: errors that can not be detected before execution. -- gil
Re: BASR to AMODE 64
...inline... On Tue, Dec 3, 2019 at 9:10 AM Peter Relson wrote: > Steve Smith wrote > > I found that a couple of > IBM AMODE 64 callable routines expect R15 to be set to their EPA, although > most do not. I discovered these when I made the calls using JASL ( > > I trust you are aware that "callable" really does mean using "CALL" > (whether in a HLL or, in assembler, by the CALL macro). Use of any linkage > instruction that is not the default should not be assumed to work unless > the service documents that it is OK to do so. Even when using BRASL as > your linkage instruction, unless you know the requirements of the target, > setting up reg 15 (perhaps via LARL) is often a good idea. Both LARL and > BRASL can have as their operands things not within the same CSECT. The > binder handles most of these cases. The loader handles others as part of > "relocation". And, yes, there are cases were relocation applies even to > use of relative branches. I'll leave that teaser as an exercise for the > readers. > > I'm aware that subroutines have their requirements, and one has to deal with them; that's not really an issue. But it's a pretty obvious argument that IBM's services should be consistent with their guidance on other people's AMODE 64 programs, esp. when it's trivial to do so. JAS/L calls are more efficient, if just for not having to load and then reference R15. Irregardless, I'm not bothered about it. It occurred to me that an RMODE SPLIT program could blithely branch back and forth between below and above-the-line CSECTs as long as relative-long branches were used to make the jumps. Whether that's a good or useful idea, I'm not so sure. Thanks to a clue from John Ehrman a few years ago, I've found that relative branch instructions have all the capabilities of A- & V-cons for linkage and relocation (at least on z/OS, using the Binder). > Keith Moe wrote > > Even when using "baseless" code, I like to keep ONE register as the > base/entry point of the module (plus what ever is needed for constant/data > areas beyond the first 4K). Having a register thus set makes looking at a > dump easier as this base register (90% of the time R12) points to the > current module. Also, when tracing back through the save area chain or > linkage stack, there's a register that is pointing to each module that did > the linkage. > > FWIW, the convention we adopted long ago was that the first > word/doubleword pointed to by the "static area register" contains the > beginning of the module. Thus if you have a convention of which is the > "statreg", your dump reading involves using that register's value to > locate the area that contains the address of the module. Sacrificing a > register, especially for compiled code, can be a big deal > performance-wise. The approach of using LOCTR to have your static data at > the beginning is a good one too, at the minor expense of wasting an > I-cache line. You definitely would not want to take that approach for a > non-reentrant module if doing so meant that that first data could need to > be in both the I-cache and, for write, the D-cache. > My deferred comment is that was a terrible waste of a good register. There are many ways to track what program is executing, and the pointer at the beginning of the static area is a good one. > > > And, of course, R15 is not even loaded with the entry point address for > programs given control in AMODE(64) :-\ > > > That strikes me as thoughtless; bad design. High astonishment > factor and breaks consistency between CALL and JCL EXEC. > > Significant thought was given to this design. We could not find a > reasonable alternative that met all the requirements. The fact that you > made this statement leads me to think that you have not thought of some of > the requirements. I suggest that you look up what the value in reg 15 > means for this case (it should be documented somewhere), and for the other > system-assisted linkage cases. Yes, there's a high astonishment factor. > But use of AMODE 64 itself was totally new and compilers were expected to > do the right thing -- not rely on entry reg 15 for AMODE 64 modules. That > left the assembler users. Perhaps we failed to document this expectation. > There is no problem with (or need for) 'consistency' in this case because > the target is expected not to care if the source did or did not set reg > 15. > > It is documented, and clearly. The problem is knowing when you need to re-read the manual. > Peter Relson > z/OS Core Technology Design > -- sas
Re: BASR to AMODE 64
On Tue, 3 Dec 2019 09:10:42 -0500, Peter Relson wrote: >I suggest that you look up what the value in reg 15 >means for this case (it should be documented somewhere), and for the other >system-assisted linkage cases. It is documented. For example: https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa600/iea3a6_Using_the_LINK_or_LINKX_macro.htm https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa600/iea3a6_Using_the_XCTL_or_XCTLX_macro.htm https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa800/iea3a8_Synchronous_exits__SYNCH_or_SYNCHX_macro_.htm https://www.ibm.com/support/knowledgecenter/SSLTBW_2.3.0/com.ibm.zos.v2r3.ieaa700/iea3a7_Description1.htm -- Tom Marchant
Re: BASR to AMODE 64
Steve Smith wrote I found that a couple of IBM AMODE 64 callable routines expect R15 to be set to their EPA, although most do not. I discovered these when I made the calls using JASL ( I trust you are aware that "callable" really does mean using "CALL" (whether in a HLL or, in assembler, by the CALL macro). Use of any linkage instruction that is not the default should not be assumed to work unless the service documents that it is OK to do so. Even when using BRASL as your linkage instruction, unless you know the requirements of the target, setting up reg 15 (perhaps via LARL) is often a good idea. Both LARL and BRASL can have as their operands things not within the same CSECT. The binder handles most of these cases. The loader handles others as part of "relocation". And, yes, there are cases were relocation applies even to use of relative branches. I'll leave that teaser as an exercise for the readers. Keith Moe wrote Even when using "baseless" code, I like to keep ONE register as the base/entry point of the module (plus what ever is needed for constant/data areas beyond the first 4K). Having a register thus set makes looking at a dump easier as this base register (90% of the time R12) points to the current module. Also, when tracing back through the save area chain or linkage stack, there's a register that is pointing to each module that did the linkage. FWIW, the convention we adopted long ago was that the first word/doubleword pointed to by the "static area register" contains the beginning of the module. Thus if you have a convention of which is the "statreg", your dump reading involves using that register's value to locate the area that contains the address of the module. Sacrificing a register, especially for compiled code, can be a big deal performance-wise. The approach of using LOCTR to have your static data at the beginning is a good one too, at the minor expense of wasting an I-cache line. You definitely would not want to take that approach for a non-reentrant module if doing so meant that that first data could need to be in both the I-cache and, for write, the D-cache. > And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ > That strikes me as thoughtless; bad design. High astonishment factor and breaks consistency between CALL and JCL EXEC. Significant thought was given to this design. We could not find a reasonable alternative that met all the requirements. The fact that you made this statement leads me to think that you have not thought of some of the requirements. I suggest that you look up what the value in reg 15 means for this case (it should be documented somewhere), and for the other system-assisted linkage cases. Yes, there's a high astonishment factor. But use of AMODE 64 itself was totally new and compilers were expected to do the right thing -- not rely on entry reg 15 for AMODE 64 modules. That left the assembler users. Perhaps we failed to document this expectation. There is no problem with (or need for) 'consistency' in this case because the target is expected not to care if the source did or did not set reg 15. Peter Relson z/OS Core Technology Design
Re: BASR to AMODE 64
What does CSECT size have to do with base registers? If I have constants in my CSECT and use "traditional" base/offset branches then I need a base register, no matter how small the CSECT. If I have neither of the above I do not need a base register, no matter how large the CSECT. No argument with your assertion that small is good. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Seymour J Metz Sent: Monday, December 2, 2019 11:08 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 ObNit If you keep your CSECT to a reasonable size then there is no need for a base register to address the code. But if you have an obscenely large monolithic program you will still need a base register, plus a large bottle of aspirins.
Re: BASR to AMODE 64 (Baseless code)
If you begin each module with an eye-catcher then your base register instantly identifies the module. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Keith Moe Sent: Monday, December 2, 2019 11:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) Even when using "baseless" code, I like to keep ONE register as the base/entry point of the module (plus what ever is needed for constant/data areas beyond the first 4K). Having a register thus set makes looking at a dump easier as this base register (90% of the time R12) points to the current module. Also, when tracing back through the save area chain or linkage stack, there's a register that is pointing to each module that did the linkage. Human time is frequently more expensive than computer time and every little trick helps. Someone also mentioned the "old" user of a BALR instruction to set the base register with an offset of 2 (which he didn't like - and neither do I). I started with DOS and TOS in 1966 and you had to do this because no register was set as the main program entry point when you received control. Keith Moe BMC Software On Monday, December 2, 2019, 11:08:31 AM PST, Seymour J Metz wrote: ObNit If you keep your CSECT to a reasonable size then there is no need for a base register to address the code. But if you have an obscenely large monolithic program you will still need a base register, plus a large bottle of aspirins. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Monday, December 2, 2019 11:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 12/2/2019 7:58 AM, Kerry Liles wrote: > Or > > LR 12,15 > USING entrypointname,12 And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ These days, one is expected to issue LARL/USING to your program constants. There is generally no need whatever for base register coverage of the code. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1CmNlLjV6IRG9rviKHLMbp5nRJL54PCArFysj4EbgjECIvpoTo8FSAt-W0t5zZjVF-vUu5S6tiwLCbgX4UxOwwc-Rpf8NRTgGpmVY7Wezr5v8ZCwodpJvBoUpw5myjQTm5r331VZrX6YTyn_hFIw6wNfZhyA750MPczTp3V9YzraBA4vYB7KVkNgvvJlTYuHz89zXrWq3v_hewn7TTr91jbtyUf75SeAekIvCzFkIyM7PIQuFOvFX5MnrC7n_OojOGPumCv_yz8M0EbwAbOAgNIbrf42HgxGGUplfsxTHjddb3JwpCDqKhumRNfhTULltWS1H60XMuPLOp2IT61WKvkoKg6KRXyfrdkfq01v2AP0i-BC_p-s8U8QN2bUaFgGjCdc2pbi5cVOva-YE7ndVr7yeajsew3OXRwAi6fHZ4Hk4GbQYhNduRL-bZnmcBVt5/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: BASR to AMODE 64 (Baseless code)
Some folks eschew the use of literals (I like them!) but if you use literals you end up with data following instructions physically. LOCTR is your friend for making the literals end up at the beginning of the CSECT. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, December 2, 2019 2:56 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 (Baseless code) On 2019-12-02, at 13:02:39, Tom Marchant wrote: > > On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote: > >> Even when using "baseless" code, I like to keep ONE register >> as the base/entry point of the module (plus what ever is >> needed for constant/data areas beyond the first 4K). > > Locating your constants at the beginning of the program allows > you to do that without sacrificing a register. > In the source? Branch around them or use LOCTR? What difference does it make as long as instructions plus data do not exceed 4Ki? Decades ago I belonged to a design team which had intense dissension about whether control block definitions should precede or follow instructions. Some of us thought the data were conceptually more important; others thought the code. And the former group was biased by experience with languages which required symbols defined before reference.
Re: BASR to AMODE 64 (Baseless code)
On Monday, December 2, 2019, 02:56:13 PM PST, Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: > In the source? Branch around them or use LOCTR? What difference > does it make as long as instructions plus data do not exceed 4Ki? For programs that don't use a base register for the code, good coding practices requires LOCTR be used to place constants at the beginning of your program (with branch around). As long as constants never exceed 4KB, the program won't need to be reworked to free a register. > dissension about whether control block definitions should > precede or follow instructions. > And the former group was biased by experience with languages > which required symbols defined before reference. CB location in the source is not always cosmetic because of the macro language. I've worked on a product that will not assemble with the CB's at the end of source. The cosmetic problem of placing CB's at the beginning is no longer a problem because ISPF and SDSF editor allows lines to be hidden. Just write an edit macro to hide CB definitions. Jon.
Re: BASR to AMODE 64
For AMODE64 there is an inconsistency between CALL and supervisor-assisted linkage. The register setup for PGM=foo is the same as for any other ATTACHX of foo. OS/360 loaded R15. DOS/360 did not. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, December 2, 2019 5:42 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 2019-12-02, at 09:48:39, Ed Jaffe wrote: > > On 12/2/2019 7:58 AM, Kerry Liles wrote: >> Or >> >> LR 12,15 >> USING entrypointname,12 > > And, of course, R15 is not even loaded with the entry point address for > programs given control in AMODE(64) :-\ > That strikes me as thoughtless; bad design. High astonishment factor and breaks consistency between CALL and JCL EXEC. But what about bit 63? I've been told that some OSes: CMS? VSE? ancient OS/360? did not guarantee R15. > These days, one is expected to issue LARL/USING to your program constants. > There is generally no need whatever for base register coverage of the code. -- gil
Re: BASR to AMODE 64 (Baseless code)
On 2019-12-02, at 13:02:39, Tom Marchant wrote: > > On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote: > >> Even when using "baseless" code, I like to keep ONE register >> as the base/entry point of the module (plus what ever is >> needed for constant/data areas beyond the first 4K). > > Locating your constants at the beginning of the program allows > you to do that without sacrificing a register. > In the source? Branch around them or use LOCTR? What difference does it make as long as instructions plus data do not exceed 4Ki? Decades ago I belonged to a design team which had intense dissension about whether control block definitions should precede or follow instructions. Some of us thought the data were conceptually more important; others thought the code. And the former group was biased by experience with languages which required symbols defined before reference. -- gil
Re: BASR to AMODE 64
On 2019-12-02, at 09:48:39, Ed Jaffe wrote: > > On 12/2/2019 7:58 AM, Kerry Liles wrote: >> Or >> >> LR 12,15 >> USING entrypointname,12 > > And, of course, R15 is not even loaded with the entry point address for > programs given control in AMODE(64) :-\ > That strikes me as thoughtless; bad design. High astonishment factor and breaks consistency between CALL and JCL EXEC. But what about bit 63? I've been told that some OSes: CMS? VSE? ancient OS/360? did not guarantee R15. > These days, one is expected to issue LARL/USING to your program constants. > There is generally no need whatever for base register coverage of the code. -- gil
Re: BASR to AMODE 64 (Baseless code)
On 12/2/2019 12:02 PM, Tom Marchant wrote: Locating your constants at the beginning of the program allows you to do that without sacrificing a register. Prezactly! That's what we do (using LOCTRs)... -- 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.
Re: BASR to AMODE 64 (Baseless code)
On 12/2/2019 12:02 PM, Tom Marchant wrote: Locating your constants at the beginning of the program allows you to do that without sacrificing a register. Prezactly! That's what we do (using LOCTRs)... -- 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.
Re: BASR to AMODE 64 (Baseless code)
On Mon, 2 Dec 2019 19:27:42 +, Keith Moe wrote: >Even when using "baseless" code, I like to keep ONE register >as the base/entry point of the module (plus what ever is >needed for constant/data areas beyond the first 4K). Locating your constants at the beginning of the program allows you to do that without sacrificing a register. -- Tom Marchant
Re: BASR to AMODE 64 (Baseless code)
Even when using "baseless" code, I like to keep ONE register as the base/entry point of the module (plus what ever is needed for constant/data areas beyond the first 4K). Having a register thus set makes looking at a dump easier as this base register (90% of the time R12) points to the current module. Also, when tracing back through the save area chain or linkage stack, there's a register that is pointing to each module that did the linkage. Human time is frequently more expensive than computer time and every little trick helps. Someone also mentioned the "old" user of a BALR instruction to set the base register with an offset of 2 (which he didn't like - and neither do I). I started with DOS and TOS in 1966 and you had to do this because no register was set as the main program entry point when you received control. Keith Moe BMC Software On Monday, December 2, 2019, 11:08:31 AM PST, Seymour J Metz wrote: ObNit If you keep your CSECT to a reasonable size then there is no need for a base register to address the code. But if you have an obscenely large monolithic program you will still need a base register, plus a large bottle of aspirins. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Monday, December 2, 2019 11:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 12/2/2019 7:58 AM, Kerry Liles wrote: > Or > > LR 12,15 > USING entrypointname,12 And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ These days, one is expected to issue LARL/USING to your program constants. There is generally no need whatever for base register coverage of the code. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1CmNlLjV6IRG9rviKHLMbp5nRJL54PCArFysj4EbgjECIvpoTo8FSAt-W0t5zZjVF-vUu5S6tiwLCbgX4UxOwwc-Rpf8NRTgGpmVY7Wezr5v8ZCwodpJvBoUpw5myjQTm5r331VZrX6YTyn_hFIw6wNfZhyA750MPczTp3V9YzraBA4vYB7KVkNgvvJlTYuHz89zXrWq3v_hewn7TTr91jbtyUf75SeAekIvCzFkIyM7PIQuFOvFX5MnrC7n_OojOGPumCv_yz8M0EbwAbOAgNIbrf42HgxGGUplfsxTHjddb3JwpCDqKhumRNfhTULltWS1H60XMuPLOp2IT61WKvkoKg6KRXyfrdkfq01v2AP0i-BC_p-s8U8QN2bUaFgGjCdc2pbi5cVOva-YE7ndVr7yeajsew3OXRwAi6fHZ4Hk4GbQYhNduRL-bZnmcBVt5/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: BASR to AMODE 64
ObNit If you keep your CSECT to a reasonable size then there is no need for a base register to address the code. But if you have an obscenely large monolithic program you will still need a base register, plus a large bottle of aspirins. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Ed Jaffe Sent: Monday, December 2, 2019 11:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On 12/2/2019 7:58 AM, Kerry Liles wrote: > Or > > LR 12,15 > USING entrypointname,12 And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ These days, one is expected to issue LARL/USING to your program constants. There is generally no need whatever for base register coverage of the code. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1CmNlLjV6IRG9rviKHLMbp5nRJL54PCArFysj4EbgjECIvpoTo8FSAt-W0t5zZjVF-vUu5S6tiwLCbgX4UxOwwc-Rpf8NRTgGpmVY7Wezr5v8ZCwodpJvBoUpw5myjQTm5r331VZrX6YTyn_hFIw6wNfZhyA750MPczTp3V9YzraBA4vYB7KVkNgvvJlTYuHz89zXrWq3v_hewn7TTr91jbtyUf75SeAekIvCzFkIyM7PIQuFOvFX5MnrC7n_OojOGPumCv_yz8M0EbwAbOAgNIbrf42HgxGGUplfsxTHjddb3JwpCDqKhumRNfhTULltWS1H60XMuPLOp2IT61WKvkoKg6KRXyfrdkfq01v2AP0i-BC_p-s8U8QN2bUaFgGjCdc2pbi5cVOva-YE7ndVr7yeajsew3OXRwAi6fHZ4Hk4GbQYhNduRL-bZnmcBVt5/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: BASR to AMODE 64
I just had that discussion on a different forum with a guy who converted a program to AMODE 64 and got surprised by that. "Why was my program loaded at x'FF02', and why do I get a S0C4?" However, that really only applies to system-controlled linkage. Normal linkage can be, and often is used to call AMODE 64 subroutines, but of course, it would be prudent not to count on it. I found that a couple of IBM AMODE 64 callable routines expect R15 to be set to their EPA, although most do not. I discovered these when I made the calls using JASL (if you don't know, yes, the Binder can handle that). sas On Mon, Dec 2, 2019 at 11:48 AM Ed Jaffe wrote: > On 12/2/2019 7:58 AM, Kerry Liles wrote: > > Or > > > > LR 12,15 > > USING entrypointname,12 > > > And, of course, R15 is not even loaded with the entry point address for > programs given control in AMODE(64) :-\ > > These days, one is expected to issue LARL/USING to your program > constants. There is generally no need whatever for base register > coverage of the code.
Re: BASR to AMODE 64
Point taken! Thanks for clarification and I agree about base registers in general. On Dec 2, 2019 11:48 AM, "Ed Jaffe" wrote: > On 12/2/2019 7:58 AM, Kerry Liles wrote: > >> Or >> >> LR 12,15 >> USING entrypointname,12 >> > > > And, of course, R15 is not even loaded with the entry point address for > programs given control in AMODE(64) :-\ > > These days, one is expected to issue LARL/USING to your program constants. > There is generally no need whatever for base register coverage of the code. > > > -- > 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. >
Re: BASR to AMODE 64
On 12/2/2019 7:58 AM, Kerry Liles wrote: Or LR 12,15 USING entrypointname,12 And, of course, R15 is not even loaded with the entry point address for programs given control in AMODE(64) :-\ These days, one is expected to issue LARL/USING to your program constants. There is generally no need whatever for base register coverage of the code. -- 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.
Re: BASR to AMODE 64
Or LR 12,15 USING entrypointname,12 On Mon, 2 Dec 2019 at 10:03, John McKown wrote: > On Mon, Dec 2, 2019 at 8:31 AM Steve Smith wrote: > > > Yep, serious, at least as far as a moot & hypothetical discussion of > > history goes. There are (hypothetically) other ways to handle those > > issues. > > > > Having R15 as the incoming EPA has never been more than a convenience > > anyway. The first example program in my first assembler class (long > before > > MVS/XA, much less relative addressing) used BALR 12,0 to set the base > > address. > > > > I used to do that too. What I didn't like was the offsets from the base was > two bytes less than the offsets in the assembler listing. Therefore I did > two BCTR base,0 instructions after the BALR to "make them correct". > > > > > > > sas > > > > > > -- > > sas > > > > > -- > People in sleeping bags are the soft tacos of the bear world. > Maranatha! <>< > John McKown >
Re: BASR to AMODE 64
On Mon, Dec 2, 2019 at 8:31 AM Steve Smith wrote: > Yep, serious, at least as far as a moot & hypothetical discussion of > history goes. There are (hypothetically) other ways to handle those > issues. > > Having R15 as the incoming EPA has never been more than a convenience > anyway. The first example program in my first assembler class (long before > MVS/XA, much less relative addressing) used BALR 12,0 to set the base > address. > I used to do that too. What I didn't like was the offsets from the base was two bytes less than the offsets in the assembler listing. Therefore I did two BCTR base,0 instructions after the BALR to "make them correct". > > sas > > > -- > sas > -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown
Re: BASR to AMODE 64
Yep, serious, at least as far as a moot & hypothetical discussion of history goes. There are (hypothetically) other ways to handle those issues. Having R15 as the incoming EPA has never been more than a convenience anyway. The first example program in my first assembler class (long before MVS/XA, much less relative addressing) used BALR 12,0 to set the base address. sas On Wed, Nov 27, 2019 at 1:35 PM Jonathan Scott wrote: > Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500 > > > My point is that XA took away 7 bits that were used for various purposes. > > Taking all 8 wouldn't have been a lot more painful. > > > > sas > > Are you serious? The main problem with going from 24-bit to > 32-bit addressing was that the standard linkage convention since > OS/360 used the top bit to indicate the end of a variable length > parameter list (for example via the VL option on CALL) and also > in many cases a fixed length parameter list too, just in case it > might be expanded in future. This usage was very widespread. > > In contrast, many 24-bit programs could be updated to run in > 31-bit addressing mode without any change to the code, > especially once the data management macros such as GET and PUT > were modified to clean the branch address. > > And the use of the high bit for switching between AMODE 24 and > 31 was also very neat. The use of the low bit for AMODE 64 > switching is somewhat less neat in that it means that a > different address value is needed for a mode switching call and > the entry point register does not contain the entry point > address when a mode switching call is used. However, it is > still usable enough in conjunction with relative addressing. > > Jonathan Scott, HLASM > IBM Hursley, UK > -- sas
Re: BASR to AMODE 64
> On 2019-11-27, at 11:24:20, Jonathan Scott wrote: > > Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500 > >> My point is that XA took away 7 bits that were used for various purposes. >> Taking all 8 wouldn't have been a lot more painful. >> >> sas > > Are you serious? > He's serious. During overlap in support I wrote code to run on both 370 and in AMODE 31 on XA. > In contrast, many 24-bit programs could be updated to run in > 31-bit addressing mode without any change to the code, > especially once the data management macros such as GET and PUT > were modified toclean the branch address. > But to "clean the branch address" meant to set bits 1-7 to zero which required that all referenced objects and code reside below the line. And access methods in that day needed to be called from below the line. My bimodal code used BR ,0 do detect the entry AMODE, then set or clear bit 0 of the image of R14 in RSA; BSM to AMODE 24, then return selectively by BR or BSM depending on caller's AMODE. Ugh. -- gil
Re: BASR to AMODE 64
On 2019-11-28, at 07:08:16, Peter Relson wrote: > > > there's a little-known "mini-bar" at the high-end of the 31-bit address > space > > (I'd be grateful if citations of earlier plies included the Sender and Date so I might consult the entire text. And if the (old-fashioned) ">" quotation indicators appeared.) > ... > X'7000' is a value that can be used to initialize a pointer that you > expect not to be used (and if you do use it, it's an error). That value is > better than 0 because (aside from ZAD) the usage of 0 might well "work" > whereas an AMODE 31/64 reference to x'7000' will not. > I applaud that. I'll even suggest that XLC should make that the value of NULL. Of course: o that would require that casts between (void *) and ([long] int) perform data conversion. o Some type punning would not work. But I believe that could conform to ANSI C specification. -- gil
Re: BASR to AMODE 64
there's a little-known "mini-bar" at the high-end of the 31-bit address space True. The x'7000' page of the address space is intentionally not mapped in virtual and accessing that location in an address space (assuming AMODE 31 or 64) will always program check. Maybe some day we'll do the same for the x'00FFF000' page to cover the AMODE 24 case too. Note that the not-mapped page does not apply to a data space. X'7000' is a value that can be used to initialize a pointer that you expect not to be used (and if you do use it, it's an error). That value is better than 0 because (aside from ZAD) the usage of 0 might well "work" whereas an AMODE 31/64 reference to x'7000' will not. While not covering as much, we sometimes use x'7BAD' because it's visually catchy. Peter Relson z/OS Core Technology Design
Re: BASR to AMODE 64
Ref: Your note of Wed, 27 Nov 2019 13:16:33 -0500 > My point is that XA took away 7 bits that were used for various purposes. > Taking all 8 wouldn't have been a lot more painful. > > sas Are you serious? The main problem with going from 24-bit to 32-bit addressing was that the standard linkage convention since OS/360 used the top bit to indicate the end of a variable length parameter list (for example via the VL option on CALL) and also in many cases a fixed length parameter list too, just in case it might be expanded in future. This usage was very widespread. In contrast, many 24-bit programs could be updated to run in 31-bit addressing mode without any change to the code, especially once the data management macros such as GET and PUT were modified to clean the branch address. And the use of the high bit for switching between AMODE 24 and 31 was also very neat. The use of the low bit for AMODE 64 switching is somewhat less neat in that it means that a different address value is needed for a mode switching call and the entry point register does not contain the entry point address when a mode switching call is used. However, it is still usable enough in conjunction with relative addressing. Jonathan Scott, HLASM IBM Hursley, UK
Re: BASR to AMODE 64
Actually, my real point is that XA could have been the transition that got us completely away from "dirty" addresses. And btw, a 'LLG24' instruction would be nice to have. The total cost of changing GET/PUT/READ/WRITE to using SR/ICM must world-wide represent the waste of dozens of dollars in extra CPU time. sas On Wed, Nov 27, 2019 at 1:16 PM Steve Smith wrote: > I must fall back on "I know very little about Intel architecture". They > do have different modes, which are actually more involved than just > addressing. I get the impression some of the older ones have been > abandoned. > > They have far less assembler code to worry about carrying forward. > Regardless, I doubt they support backwards compatibility nearly as well as > MVS and family. > > My point is that XA took away 7 bits that were used for various purposes. > Taking all 8 wouldn't have been a lot more painful. > > sas > > On Wed, Nov 27, 2019 at 1:00 PM Tom Marchant < > 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > >> On Wed, 27 Nov 2019 12:47:44 -0500, Steve Smith wrote: >> >> >Notwithstanding all the expert opinions, from my point of view, XA would >> >have better gone to 32-bit addressing from the get-go. I don't see the >> >benefit of the amode being part of the address. Seems to me it's been a >> >lot of unnecessary complication, and we might have had twice the address >> >space until the advent of z/Arch. I know very little about Intel >> >architecture, but when 32-bit processors came out, they had 32-bit >> >addressing (at least logically). This is, of course, rather moot now. >> >> Do Intel processors support bimodal addressing? Do their designers >> care about compatibility with existing code? >> >> -- >> Tom Marchant >> > > > -- > sas > -- sas
Re: BASR to AMODE 64
I must fall back on "I know very little about Intel architecture". They do have different modes, which are actually more involved than just addressing. I get the impression some of the older ones have been abandoned. They have far less assembler code to worry about carrying forward. Regardless, I doubt they support backwards compatibility nearly as well as MVS and family. My point is that XA took away 7 bits that were used for various purposes. Taking all 8 wouldn't have been a lot more painful. sas On Wed, Nov 27, 2019 at 1:00 PM Tom Marchant < 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > On Wed, 27 Nov 2019 12:47:44 -0500, Steve Smith wrote: > > >Notwithstanding all the expert opinions, from my point of view, XA would > >have better gone to 32-bit addressing from the get-go. I don't see the > >benefit of the amode being part of the address. Seems to me it's been a > >lot of unnecessary complication, and we might have had twice the address > >space until the advent of z/Arch. I know very little about Intel > >architecture, but when 32-bit processors came out, they had 32-bit > >addressing (at least logically). This is, of course, rather moot now. > > Do Intel processors support bimodal addressing? Do their designers > care about compatibility with existing code? > > -- > Tom Marchant > -- sas
Re: BASR to AMODE 64
On 2019-11-27, at 10:26:35, Seymour J Metz wrote: > > TSS/360 used an explicit length at offset -4 from the parameter list, so the > end-of-list bit wasn't an issue. > > The addresses transition from 7FFF_ to 8000_ is a > z/OS issue rather than an architectural issue. > Where is that an "issue" for z/OS? Cite. -- gil
Re: BASR to AMODE 64
On Wed, 27 Nov 2019 12:47:44 -0500, Steve Smith wrote: >Notwithstanding all the expert opinions, from my point of view, XA would >have better gone to 32-bit addressing from the get-go. I don't see the >benefit of the amode being part of the address. Seems to me it's been a >lot of unnecessary complication, and we might have had twice the address >space until the advent of z/Arch. I know very little about Intel >architecture, but when 32-bit processors came out, they had 32-bit >addressing (at least logically). This is, of course, rather moot now. Do Intel processors support bimodal addressing? Do their designers care about compatibility with existing code? -- Tom Marchant
Re: BASR to AMODE 64
Good grief. I really wonder why the BX* instructions don't use logical compares, like I assumed they did. In any case, that quote is almost nonsense, as address wrap-around has been a feature since the dawn of time. 2^31-1 + 1 = 0, for addressing purposes. And yet the BX* instructions treat addresses as 32-bit signed numbers for comparison. I suppose it may have been a compromise on how much silicon could be reused. In any case, there's a little-known "mini-bar" at the high-end of the 31-bit address space in OS/390 ff. Maybe you can do actual wrap-around in a data space. Sounds like maybe you shouldn't :-) Notwithstanding all the expert opinions, from my point of view, XA would have better gone to 32-bit addressing from the get-go. I don't see the benefit of the amode being part of the address. Seems to me it's been a lot of unnecessary complication, and we might have had twice the address space until the advent of z/Arch. I know very little about Intel architecture, but when 32-bit processors came out, they had 32-bit addressing (at least logically). This is, of course, rather moot now. Disclaimer: it's the end of the work week for most Americans. Obviously, this discussion has little practical value. sas On Wed, Nov 27, 2019 at 11:41 AM Tom Marchant < 00a69b48f3bb-dmarc-requ...@listserv.uga.edu> wrote: > ... > > I agree with Peter about the desirability of including AMODE information > along with an address. BXH. The authors of the z/Architecture > POO have not given this quite as careful consideration with > this note: > > > Care must be taken in the 31-bit addressing > mode when a data area in storage is at the rightmost > end of a 31-bit address space and a > BRANCH ON INDEX HIGH (BXH) or BRANCH > ON INDEX LOW OR EQUAL (BXLE) instruction > is used to step upward through the data. Since > the addition and comparison operations performed > during the execution of these instructions > treat the operands as 32-bit signed binary integers, > the value following 2^31 - 1 is not 2^31, which > cannot be represented in that format, but -2^31. >
Re: BASR to AMODE 64
On Wed, 27 Nov 2019 17:26:35 +, Seymour J Metz wrote: >TSS/360 used an explicit length at offset -4 from the parameter list, so the >end-of-list bit wasn't an issue. >The addresses transition from 7FFF_ to 8000_ is a z/OS >issue rather than an architectural issue. I beg to differ with respect to the need for care when using BXHG and BXLEG. Because the values are treated as signed 64-bit integers for the purposes of addition and comparison, the transition from the maximum positive number to the maximum negative number can cause an issue regardless of operating system. -- Tom Marchant
Re: BASR to AMODE 64
TSS/360 used an explicit length at offset -4 from the parameter list, so the end-of-list bit wasn't an issue. The addresses transition from 7FFF_ to 8000_ is a z/OS issue rather than an architectural issue. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List on behalf of Tom Marchant <00a69b48f3bb-dmarc-requ...@listserv.uga.edu> Sent: Wednesday, November 27, 2019 11:41 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: BASR to AMODE 64 On Tue, 26 Nov 2019 10:29:32 -0700, Paul Gilmartin wrote: >I believe the greater accommodation was the hardware architecture's >expanding from 24-bit addressing to only 31 rather than 32 because >software so pervasively uses the sign bit for a flag. I don't think so. I don't have any information from the designers of 370/Extended Architecture either,, but, the System/360 model 67 had a 32-bit addressing mode, determined by bit 4 of the PSW. This bit could be modified by a Set System Mask (SSM) instruction, as well as by LPSW. Both of these are privileged instructions, and there was no way for a problem state program program to change the addressing mode. I agree with Peter about the desirability of including AMODE information along with an address. In addition, there are issues with performing arithmetic operations on addresses. Unsigned arithmetic must be used to do it correctly. The Model 67 Functional Characteristics manual (available on bitsavers) has this note for BXH: When BRANCH ON INDEX HIGH is used for address modification in a 2067 that is equipped with 32-bit addressing and bit 32 is a 1 as a result of address modification, the resulting address will be treated as a negative quantity during the compare process; this can result in an erroneous branch. For that magnitude of address manipulation, care must be taken in the use of this instruction. The description of BXLE doesn't repeat the caution, but references the one for BXH. The authors of the z/Architecture POO have not given this quite as careful consideration with this note: Care must be taken in the 31-bit addressing mode when a data area in storage is at the rightmost end of a 31-bit address space and a BRANCH ON INDEX HIGH (BXH) or BRANCH ON INDEX LOW OR EQUAL (BXLE) instruction is used to step upward through the data. Since the addition and comparison operations performed during the execution of these instructions treat the operands as 32-bit signed binary integers, the value following 2^31 - 1 is not 2^31, which cannot be represented in that format, but -2^31. The instruction does not provide an indication of such overflow. Consequently, some common looping techniques based on the use of these instructions do not work when a data area ends at address 2^31 - 1. This problem is illustrated in a BRANCH ON INDEX LOW OR EQUAL example in Appendix A, “Number Representation and Instruction-Use Examples.” A similar caution applies in the 64-bit addressing mode when data is at the end of a 64-bit address space and BRANCH ON INDEX HIGH (BXHG) or BRANCH ON INDEX LOW OR EQUAL (BXLEG) is used. Actually, the problem with BXHG and BXLEG is not "at the end of a 64-bit address space", but in the middle of the 64-bit address space, when the addresses transition from 7FFF_ to 8000_. -- Tom Marchant
Re: BASR to AMODE 64
On Tue, 26 Nov 2019 10:29:32 -0700, Paul Gilmartin wrote: >I believe the greater accommodation was the hardware architecture's >expanding from 24-bit addressing to only 31 rather than 32 because >software so pervasively uses the sign bit for a flag. I don't think so. I don't have any information from the designers of 370/Extended Architecture either,, but, the System/360 model 67 had a 32-bit addressing mode, determined by bit 4 of the PSW. This bit could be modified by a Set System Mask (SSM) instruction, as well as by LPSW. Both of these are privileged instructions, and there was no way for a problem state program program to change the addressing mode. I agree with Peter about the desirability of including AMODE information along with an address. In addition, there are issues with performing arithmetic operations on addresses. Unsigned arithmetic must be used to do it correctly. The Model 67 Functional Characteristics manual (available on bitsavers) has this note for BXH: When BRANCH ON INDEX HIGH is used for address modification in a 2067 that is equipped with 32-bit addressing and bit 32 is a 1 as a result of address modification, the resulting address will be treated as a negative quantity during the compare process; this can result in an erroneous branch. For that magnitude of address manipulation, care must be taken in the use of this instruction. The description of BXLE doesn't repeat the caution, but references the one for BXH. The authors of the z/Architecture POO have not given this quite as careful consideration with this note: Care must be taken in the 31-bit addressing mode when a data area in storage is at the rightmost end of a 31-bit address space and a BRANCH ON INDEX HIGH (BXH) or BRANCH ON INDEX LOW OR EQUAL (BXLE) instruction is used to step upward through the data. Since the addition and comparison operations performed during the execution of these instructions treat the operands as 32-bit signed binary integers, the value following 2^31 - 1 is not 2^31, which cannot be represented in that format, but -2^31. The instruction does not provide an indication of such overflow. Consequently, some common looping techniques based on the use of these instructions do not work when a data area ends at address 2^31 - 1. This problem is illustrated in a BRANCH ON INDEX LOW OR EQUAL example in Appendix A, “Number Representation and Instruction-Use Examples.” A similar caution applies in the 64-bit addressing mode when data is at the end of a 64-bit address space and BRANCH ON INDEX HIGH (BXHG) or BRANCH ON INDEX LOW OR EQUAL (BXLEG) is used. Actually, the problem with BXHG and BXLEG is not "at the end of a 64-bit address space", but in the middle of the 64-bit address space, when the addresses transition from 7FFF_ to 8000_. -- Tom Marchant
Re: BASR to AMODE 64
I believe the greater accommodation was the hardware architecture's expanding from 24-bit addressing to only 31 rather than 32 because software so pervasively uses the sign bit for a flag. My guess was that "2 GB of addressability is all that anyone could ever possibly need!" Charles
Re: BASR to AMODE 64
z/OS does never allocate virtual addresses from 0x8000 to 0x. Not quite true. Never say never :-) . History: XA architecture in effect introduced the "line", an obvious differentiating point between 24-bit and 31-bit storage at 16M. z/OS (not z/Architecture) introduced the "bar", a differentiating area from 2G to 4G-1, an area that was never "given out" to a requestor (but was perfectly valid in real) for all the reasons that have been mentioned. Then z/OS gave the "bar" to Java. So if you're running in a space that has Java active, your "AMODE 64 when the address has bits 0-31 off and bit 32 on" cases might not get an exception. I believe the greater accommodation was the hardware architecture's expanding from 24-bit addressing to only 31 rather than 32 because software so pervasively uses the sign bit for a flag. I suspect that that was not the reason. More than just the high bit, the entire high byte was used quite pervasively for flags. A remember a binary search algorithm that did just that. One might say that the architects were extremely forward-thinking. They realized the need for "pointer-defined" (namely an address and AMODE in the same field). They knew that the requirement for instructions was halfword boundary. They could have possibly chosen bit 31. But by choosing bit 0, they left bit 31 available (now bit 63) which became useful for indicating AMODE 64. Peter Relson z/OS Core Technology Design
Re: BASR to AMODE 64
> On 2019-11-25, at 09:37:13, John McKown wrote: > > On Mon, Nov 25, 2019 at 10:04 AM Gary Weinhold wrote: >> ... >> There's more to it than that, of course. But the developers of z/OS >> decided that 31-bit programs should be minimally impacted by 64-bit >> addressability. >> > I'd much perfer an S0C4-38 than having a 31 bit address from a non-64 bit > application with the "end of list" bit 32 set accessing some address which > might actually be valid but not the correct page/data. > I believe the greater accommodation was the hardware architecture's expanding from 24-bit addressing to only 31 rather than 32 because software so pervasively uses the sign bit for a flag. -- gil
Re: BASR to AMODE 64
On Sat, 23 Nov 2019 at 01:11, Bernd Oppolzer wrote: > As others have pointed out, the different OSes have different strategies; > z/OS does never allocate virtual addresses from 0x8000 to 0x. > I sometimes wish the Principles of Operation would along those lines avoid to allocate some of the pages in the preface. Somehow reading phrases like "described in Reference [23.] on page xxx." makes me program check each time :-) It would actually be enough to keep such a page blank so that we don't have references to it. Rob
Re: BASR to AMODE 64
On Mon, Nov 25, 2019 at 10:04 AM Gary Weinhold wrote: > Yes, hardware translation uses the translation tables maintained by the > software. If the translation tables indicate a specific virtual page > does not have a corresponding real memory frame, it returns a program > check; it is up to the software how to respond to the program check: > assign a frame, page-in the page from auxiliary memory, return an error > to the program, etc. > > There's more to it than that, of course. But the developers of z/OS > decided that 31-bit programs should be minimally impacted by 64-bit > addressability. > > I'd much perfer an S0C4-38 than having a 31 bit address from a non-64 bit application with the "end of list" bit 32 set accessing some address which might actually be valid but not the correct page/data. -- People in sleeping bags are the soft tacos of the bear world. Maranatha! <>< John McKown
Re: BASR to AMODE 64
Yes, hardware translation uses the translation tables maintained by the software. If the translation tables indicate a specific virtual page does not have a corresponding real memory frame, it returns a program check; it is up to the software how to respond to the program check: assign a frame, page-in the page from auxiliary memory, return an error to the program, etc. There's more to it than that, of course. But the developers of z/OS decided that 31-bit programs should be minimally impacted by 64-bit addressability. On 2019-11-22 5:23 p.m., Paul Gilmartin wrote: > On 2019-11-22, at 08:14:13, Dougie Lawson wrote: >> ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as >> the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we >> were in 24-bit or 31-bit. >> >> So the 64-bit guys decided that the easiest fix was to completely disallow >> any address from 800 through to 8FFF, which is an extremely good >> idea to avoid breaking 31-bit code. >> > Do I understand correctly that enforcement is entirely by > software; those addresses are quite acceptable to the hardware? > >> They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and >> we've seen a few of those with Db2). > -- 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: BASR to AMODE 64
Am 22.11.2019 um 23:23 schrieb Paul Gilmartin: Do I understand correctly that enforcement is entirely by software; those addresses are quite acceptable to the hardware? the translation of the virtual addresses to real addresses is not done by software only; there is some hardware support. The software (the OS) decides, which virtual addresses are valid (and which are not), simply by putting entries for the valid page numbers into the translation tables. The translation itself is supported in part by the hardware (for example: translation lookaside buffers etc.). As others have pointed out, the different OSes have different strategies; z/OS does never allocate virtual addresses from 0x8000 to 0x. The reason is that in AMODE 31 addresses often have the leftmost bit on, which has no meaning, but with AMODE 64, this bit is part of the address and should be zero with valid 31 bit addresses. IBM wanted that nobody uses a valid 31 bit address with the leftmost bit on with AMODE 64 and gets a wrong access (to the address + 0x8000) undetected ... that is, a module that works with AMODE 31 must be fixed to use clean 31 bit addresses to work with AMODE 64, too; it is not sufficient to zero only the left half of the address register. HTH, kind regards Bernd
Re: BASR to AMODE 64
The “dead zone” is an OS-specific restriction. Processes running under Linux on z/Architecture see the whole 64-bit address space, for example. Keven On Fri, Nov 22, 2019 at 4:23 PM -0600, "Paul Gilmartin" <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> wrote: On 2019-11-22, at 08:14:13, Dougie Lawson wrote: > > ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as > the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we > were in 24-bit or 31-bit. > > So the 64-bit guys decided that the easiest fix was to completely disallow > any address from 800 through to 8FFF, which is an extremely good > idea to avoid breaking 31-bit code. > Do I understand correctly that enforcement is entirely by software; those addresses are quite acceptable to the hardware? > They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and > we've seen a few of those with Db2). -- gil
Re: BASR to AMODE 64
On 2019-11-22, at 08:14:13, Dougie Lawson wrote: > > ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as > the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we > were in 24-bit or 31-bit. > > So the 64-bit guys decided that the easiest fix was to completely disallow > any address from 800 through to 8FFF, which is an extremely good > idea to avoid breaking 31-bit code. > Do I understand correctly that enforcement is entirely by software; those addresses are quite acceptable to the hardware? > They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and > we've seen a few of those with Db2). -- gil
Re: BASR to AMODE 64
On Fri, 22 Nov 2019 15:14:13 +, Dougie Lawson wrote: >ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as >the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we >were in 24-bit or 31-bit. > >So the 64-bit guys decided that the easiest fix was to completely disallow >any address from 800 through to 8FFF, which is an extremely good >idea to avoid breaking 31-bit code. Yes, that was true initially for MVS. Some people have erroneously thought that meant that a valid 64-bit address could not have bit 32 on. I have seen code that tested bit 32 as part of a test to determine whether a 64-bit address was valid. Later, the area from 2G to 32G, and still later 2G to 64G was reserved for Java. IIRC the first of these was documented in an announcement letter. > >They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and >we've seen a few of those with Db2). More precisely, PIC 39, 3A and 3B are region translation exceptions. >You'll soon learn you're in the wrong addressing mode with a PIC38. Reset >the 32nd bit before mode switching to 64 and you won't fail that way. That won't help you much. If you are referencing addresses below the bar while running AMODE 64, you need to clear bits 0-32 of your base registers. -- Tom Marchant
Re: BASR to AMODE 64
The original "dead zone" was x'8000 ' to x' '. I think I remember my first IARVx giving me address x' 0001 ', but that was long ago. This has been expanded up to the 32gb uh... border (x' 0008 ') some years ago. Rumor is Java uses this area to have 32gb of addressability using 32-bit (3-bit shifted) pointers. But it was (and is) very wise to avoid using that range. In non-AMODE64 bit 32 is used as a flag, and as the AMODE bit for linking. sas On Fri, Nov 22, 2019 at 10:14 AM Dougie Lawson wrote: > ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as > the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we > were in 24-bit or 31-bit. > > So the 64-bit guys decided that the easiest fix was to completely disallow > any address from 800 through to 8FFF, which is an extremely good > idea to avoid breaking 31-bit code.
Re: BASR to AMODE 64
ABEND0C4 PIC38 is the fun one. You can't step into any 32-bit address as the 32nd bit was reserved by the MVS to MVS/XA change to mark whether we were in 24-bit or 31-bit. So the 64-bit guys decided that the easiest fix was to completely disallow any address from 800 through to 8FFF, which is an extremely good idea to avoid breaking 31-bit code. They added PIC3A and PIC3B for the 64-bit page and segment exceptions (and we've seen a few of those with Db2). You'll soon learn you're in the wrong addressing mode with a PIC38. Reset the 32nd bit before mode switching to 64 and you won't fail that way. You'll find one of the other prog 0004 interrupt codes. Regards, Dougie On Fri, 22 Nov 2019, 13:42 Joseph Reichman, wrote: > My mistake was jumping the gun and not looking at the reason code > > It clearly stated that S0C4 Reason code 38 > Had to do with AMODE 64 when the high order bit of a 31 bit pointer ( > which is not part of the address in amode 31 but is in amode 64 ) it is > best practice to do a LLGTR RX before basring a 31 bit pointer in amode 64 > > My fault I gave to slow down look at the doc before I send an e-mail :( > > > > Joe Reichman > 170-10 73 rd ave > Fresh meadows NY 11366 > > > On Nov 22, 2019, at 7:51 AM, Peter Relson wrote: > > > > I continue not to understand why you repeatedly fail to provide the > > information necessary for the good folks on this list to help you. > > > > > > So I have LOAD a module amode 64 rmode 24 > > > > Your module does not need to match the RMODE of your DCB unless your DCB > > is physically resident in the module, namely your module is not > reentrant. > > > > > > > > After loading I turn the 1 bit to the right off now I have a clean half > > address > > > > Perhaps you didn't do what you thought you did. > > > > > > when I BASR to it bombs and the PSW has the one bit on > > > > > > Show the symptom dump. Show the registers at the time of the error. Show > > the information from the program check. Show something... > > > > Peter Relson > > z/OS Core Technology Design >
Re: BASR to AMODE 64
My mistake was jumping the gun and not looking at the reason code It clearly stated that S0C4 Reason code 38 Had to do with AMODE 64 when the high order bit of a 31 bit pointer ( which is not part of the address in amode 31 but is in amode 64 ) it is best practice to do a LLGTR RX before basring a 31 bit pointer in amode 64 My fault I gave to slow down look at the doc before I send an e-mail :( Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Nov 22, 2019, at 7:51 AM, Peter Relson wrote: > > I continue not to understand why you repeatedly fail to provide the > information necessary for the good folks on this list to help you. > > > So I have LOAD a module amode 64 rmode 24 > > Your module does not need to match the RMODE of your DCB unless your DCB > is physically resident in the module, namely your module is not reentrant. > > > > After loading I turn the 1 bit to the right off now I have a clean half > address > > Perhaps you didn't do what you thought you did. > > > when I BASR to it bombs and the PSW has the one bit on > > > Show the symptom dump. Show the registers at the time of the error. Show > the information from the program check. Show something... > > Peter Relson > z/OS Core Technology Design
Re: BASR to AMODE 64
I continue not to understand why you repeatedly fail to provide the information necessary for the good folks on this list to help you. So I have LOAD a module amode 64 rmode 24 Your module does not need to match the RMODE of your DCB unless your DCB is physically resident in the module, namely your module is not reentrant. After loading I turn the 1 bit to the right off now I have a clean half address Perhaps you didn't do what you thought you did. when I BASR to it bombs and the PSW has the one bit on Show the symptom dump. Show the registers at the time of the error. Show the information from the program check. Show something... Peter Relson z/OS Core Technology Design
Re: BASR to AMODE 64
I understand haven’t program that much in amode 64 Thanks Joe Reichman 170-10 73 rd ave Fresh meadows NY 11366 > On Nov 22, 2019, at 5:50 AM, Jonathan Scott > wrote: > > Ref: Your note of Thu, 21 Nov 2019 22:26:07 -0500 > > BASR doesn't switch AMODE. If you want to switch AMODE you need > to use BASSM (and return using BSM, as the return address will > be odd for AMODE 64). > > If you BASR staying in AMODE 64, the high word of the register > needs to be zero. If you're not clearing it, the effect will > depend on what the caller had in it, which may well be different > in the TEST environment. > >> I have a amode 64 rmode 31 program I would like to do I/O So I have to have >> the DCB below 16mb So I have LOAD a module amode 64 rmode 24 >> >> After loading I turn the 1 bit to the right off now I have a clean half >> address when I BASR to it bombs and the PSW has the one bit on >> >> A funny thing under TEST making a breaking point at the basr it doesn't >> happen > > Jonathan Scott, HLASM > IBM UK, Hursley
Re: BASR to AMODE 64
Ref: Your note of Thu, 21 Nov 2019 22:26:07 -0500 BASR doesn't switch AMODE. If you want to switch AMODE you need to use BASSM (and return using BSM, as the return address will be odd for AMODE 64). If you BASR staying in AMODE 64, the high word of the register needs to be zero. If you're not clearing it, the effect will depend on what the caller had in it, which may well be different in the TEST environment. > I have a amode 64 rmode 31 program I would like to do I/O So I have to have > the DCB below 16mb So I have LOAD a module amode 64 rmode 24 > > After loading I turn the 1 bit to the right off now I have a clean half > address when I BASR to it bombs and the PSW has the one bit on > > A funny thing under TEST making a breaking point at the basr it doesn't > happen Jonathan Scott, HLASM IBM UK, Hursley
Re: BASR to AMODE 64
Or maybe a question instead of a musing? Mike Shaw MVS/QuickRef Support Group Chicago-Soft, Ltd. On Fri, Nov 22, 2019, 1:00 AM Keven wrote: > > > > > The paucity of detail makes answering your inquiry a matter of > inductive supposition. Maybe you should post additional information such > as: > Source code?Assembly listing?ABEND code?SysLog? > > Keven > > > > > > > > > > > > > On Thu, Nov 21, 2019 at 9:26 PM -0600, "Joe Reichman" < > reichman...@gmail.com> wrote: > > > > > > > > > > > Hi > > > > I have a amode 64 rmode 31 program I would like to do I/O So I have to have > the DCB below 16mb So I have LOAD a module amode 64 rmode 24 > > > > After loading I turn the 1 bit to the right off now I have a clean half > address when I BASR to it bombs and the PSW has the one bit on > > > > A funny thing under TEST making a breaking point at the basr it doesn't > happen > > > > >
Re: BASR to AMODE 64
The paucity of detail makes answering your inquiry a matter of inductive supposition. Maybe you should post additional information such as: Source code?Assembly listing?ABEND code?SysLog? Keven On Thu, Nov 21, 2019 at 9:26 PM -0600, "Joe Reichman" wrote: Hi I have a amode 64 rmode 31 program I would like to do I/O So I have to have the DCB below 16mb So I have LOAD a module amode 64 rmode 24 After loading I turn the 1 bit to the right off now I have a clean half address when I BASR to it bombs and the PSW has the one bit on A funny thing under TEST making a breaking point at the basr it doesn't happen
BASR to AMODE 64
Hi I have a amode 64 rmode 31 program I would like to do I/O So I have to have the DCB below 16mb So I have LOAD a module amode 64 rmode 24 After loading I turn the 1 bit to the right off now I have a clean half address when I BASR to it bombs and the PSW has the one bit on A funny thing under TEST making a breaking point at the basr it doesn't happen
BASR
(someone wrote)
"I may be wrong but I have the Impression hat the 360/20 version of
BAS/BASR (that machine's equivalent to BAL/BALR had a different op
code from the current BAS/BASR."
I have assembled BAS and BASR with the Tachyon assemmbler with the
right X'4D' and X'0D' opcodes. I believe these are from the 360/67.
There are some other diagnoses.
I believe one jumps to a specified address in microcode, but the
useful addresses aren't well documented.
More are for the later serial numbers, with microcode in core.
-- glen
Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
None of the existing instructions modifies access registers (AR's). You must use AR specific commands to modify them (e.g. LAM, LAE, SAR). This is good because you must specifically use these instructions to manipulate AR's. 1. It keeps exceptions to how instructions function to a minimum (e.g. LAE always sets AR and LA nevers sets it). 2. Programs are easier to maintain because AR's don't get inadvertently modified (e.g. LA R4,5 doesn't change AR4 to 0). 3. You don't have to worry about macro's and called programs inadvertently modifying access regs. 4. It keeps instruction overhead down (e.g. LA is used alot so adding AR copy adds to it's time). Regards, Jon Perryman. From: John McKown To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Sent: Wed, April 11, 2012 2:32:59 AM Subject: Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ? True, I was thinking of being in secondary addressing mode. Peter Relson has consistently said of home space mode: "Don't even consider it!". So I didn't. It is one of those "forbidden" states unless you've got a lot of internals information. On Wed, 2012-04-11 at 08:26 +, microc...@zoho.com wrote: > Edward Jaffe wrote > > > On 4/10/2012 11:31 AM, McKown, John wrote: > >> But that made me wonder why the z/Architecture does not specify that the > >> contents of the AR register associated with the link register in any of > >> the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and > >> BASSM will be set to 0? > >> > >> Anybody have any idea why these type of instructions don't set the AR? > > > > Unnecessary. Instruction fetch is always from the primary address space. > > No, in Home-space mode instructions are fetched from the HASN. > > Since you can't branch out of the current address space with any of the > instructions you listed, there is no reason to test or manipulate the AR. -- John McKown Maranatha! <><
Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
On 11 April 2012 04:26, wrote: > Edward Jaffe wrote > >> On 4/10/2012 11:31 AM, McKown, John wrote: >>> But that made me wonder why the z/Architecture does not specify that the >>> contents of the AR register associated with the link register in any of >>> the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and >>> BASSM will be set to 0? >>> >>> Anybody have any idea why these type of instructions don't set the AR? >> >> Unnecessary. Instruction fetch is always from the primary address space. > > No, in Home-space mode instructions are fetched from the HASN. Maybe better just to say that instruction fetch addresses are never qualified by an access register. This of course includes instructions fetched by Execute. Tony H.
Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
True, I was thinking of being in secondary addressing mode. Peter Relson has consistently said of home space mode: "Don't even consider it!". So I didn't. It is one of those "forbidden" states unless you've got a lot of internals information. On Wed, 2012-04-11 at 08:26 +, microc...@zoho.com wrote: > Edward Jaffe wrote > > > On 4/10/2012 11:31 AM, McKown, John wrote: > >> But that made me wonder why the z/Architecture does not specify that the > >> contents of the AR register associated with the link register in any of > >> the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and > >> BASSM will be set to 0? > >> > >> Anybody have any idea why these type of instructions don't set the AR? > > > > Unnecessary. Instruction fetch is always from the primary address space. > > No, in Home-space mode instructions are fetched from the HASN. > > Since you can't branch out of the current address space with any of the > instructions you listed, there is no reason to test or manipulate the AR. -- John McKown Maranatha! <><
Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
Edward Jaffe wrote > On 4/10/2012 11:31 AM, McKown, John wrote: >> But that made me wonder why the z/Architecture does not specify that the >> contents of the AR register associated with the link register in any of >> the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and >> BASSM will be set to 0? >> >> Anybody have any idea why these type of instructions don't set the AR? > > Unnecessary. Instruction fetch is always from the primary address space. No, in Home-space mode instructions are fetched from the HASN. Since you can't branch out of the current address space with any of the instructions you listed, there is no reason to test or manipulate the AR.
Re: curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
On 4/10/2012 11:31 AM, McKown, John wrote: But that made me wonder why the z/Architecture does not specify that the contents of the AR register associated with the link register in any of the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and BASSM will be set to 0? Anybody have any idea why these type of instructions don't set the AR? Unnecessary. Instruction fetch is always from the primary address space. -- Edward E Jaffe Phoenix Software International, Inc 831 Parkview Drive North El Segundo, CA 90245 310-338-0400 x318 edja...@phoenixsoftware.com http://www.phoenixsoftware.com/
curiosity: In AR mode, why doesn't BALR/BASR/BRAS/BRASL set the value of the corresponding AR register ?
This was due to my looking at the expansion of the CALL macro after using SYSSTATE ARCHLVL=2. The part of the expansion I was looking at was: BRAS 15,*+8 DC V(epname) L 15,0(15,0) And I immediately wondered by it was L 15,0(15,0) instead of how I am used to it: L 15,0(,15). Then it hit me. 0(15,0) is correct because it used 0 in the base register position, and by so doing was not really using a base, only an index. This caused the load instruction to load from the primary address space whereas 0(0,15) would have used the contents of AR15 when in AR mode, and might access the wrong address space. At least I am guessing that using a base register of 0 ends up effectively using an AR value of 0. But that made me wonder why the z/Architecture does not specify that the contents of the AR register associated with the link register in any of the "branch and link" type instructions: BALR, BASR, BRAS, BRASL, and BASSM will be set to 0? Anybody have any idea why these type of instructions don't set the AR? Also, why the LAE instruction? Why doesn't the LA instruction act like the LAE instruction? If you're stepping through an address like: LA 1,1(,1) then AR1 will be set to AR1, which is effectively doesn't change it. And if your in AR mode, what use is something like LA 1,OFFSET(0,10) do if AR1 is not equal to AR10? Some sort of "parallel address space" containing some sort of "copy" of the contents of the address space addressed by AR10? I.e. is the data accessed by the address OFFSET(0,10) but within a different address space likely to be of any use? I'm so confused! -- John McKown Systems Engineer IV IT Administrative Services Group HealthMarkets(r) 9151 Boulevard 26 * N. Richland Hills * TX 76010 (817) 255-3225 phone * john.mck...@healthmarkets.com * www.HealthMarkets.com Confidentiality Notice: This e-mail message may contain confidential or proprietary information. If you are not the intended recipient, please contact the sender by reply e-mail and destroy all copies of the original message. HealthMarkets(r) is the brand name for products underwritten and issued by the insurance subsidiaries of HealthMarkets, Inc. -The Chesapeake Life Insurance Company(r), Mid-West National Life Insurance Company of TennesseeSM and The MEGA Life and Health Insurance Company.SM
