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 (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 (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 (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 (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.
