Re: Base-less macros
Addressability is much less of an issue than it was on S/360. Just how big are you csects? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Ed Jaffe [edja...@phoenixsoftware.com] Sent: Tuesday, November 9, 2021 1:23 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On 11/9/2021 9:55 AM, Seymour J Metz wrote: > LOCTR may not help with literals, but it can help with macros that generate a > DC. Instead of branching around the constant, put a LOCTR before and after it. There is no guarantee a existing USING is in place for a literal or DC in a given LOCTR. The LARL technique improves certainty considerably, but nothing is as certain as branching around a literal constant. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://secure-web.cisco.com/1PDtnWMdQQmYtXWR_mcf-nKXnjdfCFifFjtZUgQV8jCcndfNiu5XLK8g6rzSe6-4sugmH3Smh22WNj-t9SU0BKMMqus3QdTsCO3gLnvF60habcUjrsLGg-pAYlYfJR1SUEpv5_PeQSGyCzSpNWDpkoYeZi7xqRGjsV08q9ZPorv5NkJej_Nfq71rArW-14ctBOdeZyN035V7nNSjGFzccF-qgW1ZTlnInVq4N9nnkbspJ1pEojwJx1S-JOnIhSFaoXrJxJSQ9jKXheMZZFf40ugrcqOr0Ogd7SAQrrG1ER_5cbpDlyZEiOzDF6C1UZF0FYCvidwqry-K5LmrwUH5347XOOZdAyHqr-2VJep3XryCQBCM2chJZN6bsFvw1tGN5RQCNNuqf1pSpaD9kjeMzVSbr1KRKWK2mGW5XqQW7Y9CrN7KhJRo9yUjY2hu84YzY/https%3A%2F%2Fwww.phoenixsoftware.com%2F This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Base-less macros
On 11/9/2021 9:55 AM, Seymour J Metz wrote: LOCTR may not help with literals, but it can help with macros that generate a DC. Instead of branching around the constant, put a LOCTR before and after it. There is no guarantee a existing USING is in place for a literal or DC in a given LOCTR. The LARL technique improves certainty considerably, but nothing is as certain as branching around a literal constant. -- Phoenix Software International Edward E. Jaffe 831 Parkview Drive North El Segundo, CA 90245 https://www.phoenixsoftware.com/ This e-mail message, including any attachments, appended messages and the information contained therein, is for the sole use of the intended recipient(s). If you are not an intended recipient or have otherwise received this email message in error, any use, dissemination, distribution, review, storage or copying of this e-mail message and the information contained therein is strictly prohibited. If you are not an intended recipient, please contact the sender by reply e-mail and destroy all copies of this email message and do not otherwise utilize or retain this email message or any or all of the information contained therein. Although this email message and any attachments or appended messages are believed to be free of any virus or other defect that might affect any computer system into which it is received and opened, it is the responsibility of the recipient to ensure that it is virus free and no responsibility is accepted by the sender for any loss or damage arising in any way from its opening or use.
Re: Base-less macros
LOCTR may not help with literals, but it can help with macros that generate a DC. Instead of branching around the constant, put a LOCTR before and after it. From: IBM Mainframe Assembler List on behalf of Peter Relson Sent: Tuesday, November 9, 2021 8:43 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros In a huge number of cases, programs using relative branch are not base-less. They have no "code base register" but that does not mean they are base-less. For the most part, z/OS has simply decided that we will not worry about "no base register at all" cases when customers use our macros. We expect addressability to a static area where literals go. So no "code base register" but a "static data base register". I didn't follow how LOCTR would help unless accompanied by LARL. Without the LARL, you still need addressability to the area built from the data within the LOCTR section. And if you have such addressability then you could have your LTORG within that LOCTR-defined area too so that anyone's macros could use literals. Peter Relson z/OS Core Technology Design
Re: Base-less macros
In a huge number of cases, programs using relative branch are not base-less. They have no "code base register" but that does not mean they are base-less. For the most part, z/OS has simply decided that we will not worry about "no base register at all" cases when customers use our macros. We expect addressability to a static area where literals go. So no "code base register" but a "static data base register". I didn't follow how LOCTR would help unless accompanied by LARL. Without the LARL, you still need addressability to the area built from the data within the LOCTR section. And if you have such addressability then you could have your LTORG within that LOCTR-defined area too so that anyone's macros could use literals. Peter Relson z/OS Core Technology Design
Re: Base-less macros
Martin Ward wrote: > > No space is wasted except, possibly, at the origin of the pool, and > > in aligning to the start of the statement following the literal > > pool. > > So this isn't entirely correct: the last segment may have padding bytes. A documentation update was included in APAR PH34824 which among other changes modified that statement to the following: Apart from any alignment padding for literals referenced by relative address, no space is wasted except, possibly, at the origin of the pool, and in aligning to the start of the statement following the literal pool. Such updates are normally completed within a few days, but for some reason this one seems to have gone astray. I have chased it up. Jonathan Scott, HLASM IBM Hursley, UK
Re: Base-less macros
On 09/11/2021 08:53, Jonathan Scott wrote: It is still stored within the last section of the literal pool (because at the time of definition, it is not necessarily known whether it will be referenced by relative address) Given that it has an odd length, it cannot be stored in the forth segment without padding since it would mess up the alignment of the next literal in the segment. On 09/11/2021 01:53, Mark Boonie wrote: No space is wasted except, possibly, at the origin of the pool, and in aligning to the start of the statement following the literal pool. So this isn't entirely correct: the last segment may have padding bytes. -- Martin Dr Martin Ward | Email: mar...@gkc.org.uk | http://www.gkc.org.uk G.K.Chesterton site: http://www.gkc.org.uk/gkc | Erdos number: 4
Re: Base-less macros
APAR PH34824 in March 2021 fixed the LARL loophole; if a literal with odd byte length is referenced by relative address, it is now automatically aligned to a halfword by inserting a padding byte before it if necessary. It is still stored within the last section of the literal pool (because at the time of definition, it is not necessarily known whether it will be referenced by relative address) so there may occasionally be a padding byte within the pool as a result. Jonathan Scott, HLASM IBM Hursley, UK
