Re: Base-less macros
So Jonathan doesn't have to respond: > And LA R1,-CL128'x' on a 128 byte boundary? >From the Language Reference: Each literal pool has five segments into which the literals are stored (a) in the order that the literals are specified, and (b) according to their assembled lengths, which, for each literal, is the total explicit or implied length: - The first segment contains all literal constants whose assembled lengths are a multiple of 16. - The second segment contains those whose assembled lengths are a multiple of 8, but not of 16. - The third segment contains those whose assembled lengths are a multiple of 4, but not a multiple of 8. - The fourth segment contains those whose assembled lengths are even, but not a multiple of 4. - The fifth segment contains all the remaining literal constants whose assembled lengths are odd. Since each literal pool is aligned on a SECTALGN alignment, this guarantees that all literals in the second segment are doubleword aligned; in the third segment, fullword aligned; and, in the fourth, halfword aligned. The minimum value of SECALGN [sic] is doubleword, so quadword alignment is not guaranteed. 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. - mb
Re: Base-less macros
We leave that as an exercise for the student. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, November 8, 2021 4:24 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 8, 2021, at 16:42:40, Charles Mills wrote: > > Are the rules special for literals? > > Yes. Literals have always aligned on a "multiple-of-length-power2" boundary. > =CL8... will be on a doubleword. > And LA R1,-CL128'x' on a 128 byte boundary? >> What if you want a speciic length?: >> LARL R3,=CL5'ABCDE-' > > You can't always get what you want. -- Mick Jagger > > CL5'whatever' is a 5-byte literal. -- gil
Re: Base-less macros
On Nov 8, 2021, at 16:42:40, Charles Mills wrote: > > Are the rules special for literals? > > Yes. Literals have always aligned on a "multiple-of-length-power2" boundary. > =CL8... will be on a doubleword. > And LA R1,-CL128'x' on a 128 byte boundary? >> What if you want a speciic length?: >> LARL R3,=CL5'ABCDE-' > > You can't always get what you want. -- Mick Jagger > > CL5'whatever' is a 5-byte literal. -- gil
Re: Base-less macros
Are the rules special for literals? Yes. Literals have always aligned on a "multiple-of-length-power2" boundary. =CL8... will be on a doubleword. > What if you want a speciic length?: >LARL R3,=CL5'ABCDE-' You can't always get what you want. -- Mick Jagger CL5'whatever' is a 5-byte literal. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Monday, November 8, 2021 1:18 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 8, 2021, at 13:57:10, Melvyn Maltz wrote: > ... > LARL R3,=C'ABCDE-' > > Yes, it's a 5-byte literal extended to 6 to keep the LARL happy > Does giving a character constant even length guarantee even alignment? I'm thinking of such as: DC. 0H'0' EVEN DC C'?' ODD DC C'ABCDE-' Are the rules special for literals? What if you want a speciic length?: LARL R3,=CL5'ABCDE-' My head hurts, gil
Re: Base-less macros
Better than a brach-around IMHO. CharlesSent from a mobile; please excuse the brevity. Original message From: Melvyn Maltz <072265160664-dmarc-requ...@listserv.uga.edu> Date: 11/8/21 12:57 PM (GMT-08:00) To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Hi there,I hate the term base-less it means 'without foundation' !I'm not sure what the fuss is about, I've been using base-free code with literals for years.eg.LARL R3,=C'ABCDE-'MVC THERE(5),0(R3)Yes, it's a 5-byte literal extended to 6 to keep the LARL happyLARL has a range of +/- 2G which should keep most coders happy, so it doesn't matter where the LTORG isMelvyn Maltz.On 08/11/2021 12:25 am, Tony Thigpen wrote:> I finally am to the point where I no longer need to worry about > specific customers having hardware that does not support relative > instructions, so I am updating some macros I provide to be baseless.>> What is the 'preferred' approach to macro generated constants? In the > past, I have used both inline constants that I branch around, and > ltorg literals (=c'x').>> In the past, I have been bitten by using ltorg literals and the client > did not put a LTORG after my macro causing a 'no active base register' > issue. So, I am thinking inline with a BRAS is better.>> Maybe there is another approach that I missed?>> Suggestions?>> Tony Thigpen
Re: Base-less macros
Hi there, I am sure Jonathan will confirm...but yes, even byte literals will be on an even boundary, they are sorted If you code it and use LARL, you'll get an error if not on an even boundary =CL5 may not align, a frequent source of 'it worked then but not now' syndrome Melvyn Maltz. On 08/11/2021 09:17 pm, Paul Gilmartin wrote: On Nov 8, 2021, at 13:57:10, Melvyn Maltz wrote: ... LARL R3,=C'ABCDE-' Yes, it's a 5-byte literal extended to 6 to keep the LARL happy Does giving a character constant even length guarantee even alignment? I'm thinking of such as: DC. 0H'0' EVEN DC C'?' ODD DC C'ABCDE-' Are the rules special for literals? What if you want a speciic length?: LARL R3,=CL5'ABCDE-' My head hurts, gil
Re: Base-less macros
On Nov 8, 2021, at 13:57:10, Melvyn Maltz wrote: > ... > LARL R3,=C'ABCDE-' > > Yes, it's a 5-byte literal extended to 6 to keep the LARL happy > Does giving a character constant even length guarantee even alignment? I'm thinking of such as: DC. 0H'0' EVEN DC C'?' ODD DC C'ABCDE-' Are the rules special for literals? What if you want a speciic length?: LARL R3,=CL5'ABCDE-' My head hurts, gil
Re: Base-less macros
Hi there, I hate the term base-less it means 'without foundation' ! I'm not sure what the fuss is about, I've been using base-free code with literals for years. eg. LARL R3,=C'ABCDE-' MVC THERE(5),0(R3) Yes, it's a 5-byte literal extended to 6 to keep the LARL happy LARL has a range of +/- 2G which should keep most coders happy, so it doesn't matter where the LTORG is Melvyn Maltz. On 08/11/2021 12:25 am, Tony Thigpen wrote: I finally am to the point where I no longer need to worry about specific customers having hardware that does not support relative instructions, so I am updating some macros I provide to be baseless. What is the 'preferred' approach to macro generated constants? In the past, I have used both inline constants that I branch around, and ltorg literals (=c'x'). In the past, I have been bitten by using ltorg literals and the client did not put a LTORG after my macro causing a 'no active base register' issue. So, I am thinking inline with a BRAS is better. Maybe there is another approach that I missed? Suggestions? Tony Thigpen
Re: Base-less macros
Everyone,
Thanks for your suggestions.
More info:
My macro supports parms in the formats:
XXX=address
XXX=(reg)
XXX=(S,address)
XXX=*address
XXX='constant'
The only time I need a local defined area is when the user uses
XXX='constant'. Based on the info posted today, I think I will document
that using XXX='constant' is available but is not a preferred method. It
also is not logical to use XXX='constant' for most of the parms anyway,
so usage should be minimal or non-existent.
Tony Thigpen
Ed Jaffe wrote on 11/8/21 12:09 PM:
On 11/8/2021 1:45 AM, Tony Thigpen wrote:
I decided to put the constant in-line and use BRAS to acquire it's
address:
AIF ('&PARM'(1,1) NE ).N0004
BRAS &TREG,N2&SYSNDX
&TVAL SETC '&PARM'(2,K'&PARM-2)
N1&SYSNDX DC CL&SIZE'&TVAL'
N2&SYSNDX DS 0H
AGO .N0099
.N0004 ANOP
Back in the day, it was quite common to see this technique used in IBM
macros. However, they now use literals -- a better choice from a
performance perspective since I- and D-cache has been split since the
first z/Architecture boxes hit the market back in 1999. Because of this
split, an inline constant such as this will require a D-cache line be
populated from memory even though it's already present in the I-cache.
If this code is not in the performance path, then what you're doing
should be fine...
--
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
I've been using (for a shockingly large number of years!) the approach that Keith Moe and Charles Mills described. It has worked very well and caused no trouble for my product development and support teams. All of the products on which I've been a designer and developer have been nearly 100 percent OCO, so, in the main, we don't have to be concerned with code written by customers. When we ship assembler macros for customer use we have the tendency to use BRAS to branch around in-line constants when absolutely necessary (but we try very hard to avoid this). We also have a lot more usage of the machine instructions which have appropriate immediate operands (things like Load Logical Immediate). Bob
Re: Base-less macros
Am 08.11.2021 um 17:08 schrieb Charles Mills: Only if you write into the data areas; the OP wrote of constants in macros, so the areas should be read-only. Can someone who knows the hardware architecture definitively confirm or deny that assertion? I always thought there were separate D- and I-cache lines, and so the branch-around technique will cause some D-cache to be flushed and re-loaded, and ultimately flushed and re-loaded again, just to accommodate your one constant. Also, of course, branches are not performance-enhancing. Charles If I understand Ed Jaffe's comment correctly, the D-cache line must be populated in the case of embedded constants, if not done before (in the best case: only when first executing this code sequence). This may be better with literals which reside at another place, together with other literals in a literal pool, where the probability is higher that the D-cache line is already loaded. But the D-cache line is never flushed in this case; it would be flushed only if there was a write access into this area. In this case the I-cache line would also be flushed, which would do even greater harm (so-called SIIS). HTH, kind regards Bernd
Re: Base-less macros
On 11/8/2021 1:45 AM, Tony Thigpen wrote:
I decided to put the constant in-line and use BRAS to acquire it's
address:
AIF ('&PARM'(1,1) NE ).N0004
BRAS &TREG,N2&SYSNDX
&TVAL SETC '&PARM'(2,K'&PARM-2)
N1&SYSNDX DC CL&SIZE'&TVAL'
N2&SYSNDX DS 0H
AGO .N0099
.N0004 ANOP
Back in the day, it was quite common to see this technique used in IBM
macros. However, they now use literals -- a better choice from a
performance perspective since I- and D-cache has been split since the
first z/Architecture boxes hit the market back in 1999. Because of this
split, an inline constant such as this will require a D-cache line be
populated from memory even though it's already present in the I-cache.
If this code is not in the performance path, then what you're doing
should be fine...
--
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
I wasn't proposing using LOCTR for the literal pool, but for named constants that you would otherwise branch around. From: IBM Mainframe Assembler List on behalf of Paul Gilmartin <0014e0e4a59b-dmarc-requ...@listserv.uga.edu> Sent: Monday, November 8, 2021 10:45 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros On Nov 8, 2021, at 08:13:09, Seymour J Metz wrote: > > What's wrong with using LOCTR in a customer-facing macro? > It requires an unlikely degree of coordination between vendor and customer leest a construct like the following unwittingly occur: BAR LOCTR USING *,2 * ... (More stuff) FOO LOCTR L 1,=F'42' * ... (More stuff) BAR LOCTR * ... (More stuff) LTORG The interaction of LOCTR with LTORG is ill-defined. Ideally, there might be a qualifier on each literal controlling which LOCTR owns it rather than assembling all pending literals at any LTORG. -- gil
Re: Base-less macros
On 11/8/2021 8:05 AM, Charles Mills wrote: Ship an additional required macro, TTLTORG, that pushes the current LOCTR, switches to "your" data LOCTR, issues a LTORG, and then pops the LOCTR. He already has a trivially-easy solution (JAS around an in-line constant) that is guaranteed to be 100% upward-compatible with what's already in the field. Why complicate things and introduce additional risk? KISS... -- 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
> Only if you write into the data areas; > the OP wrote of constants in macros, so the areas should be read-only. Can someone who knows the hardware architecture definitively confirm or deny that assertion? I always thought there were separate D- and I-cache lines, and so the branch-around technique will cause some D-cache to be flushed and re-loaded, and ultimately flushed and re-loaded again, just to accommodate your one constant. Also, of course, branches are not performance-enhancing. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Bernd Oppolzer Sent: Monday, November 8, 2021 1:01 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros Am 08.11.2021 um 05:40 schrieb Charles Mills: > +1 > > I have my LOCTR's named CODE and DATA but I agree with the concept: base > register points to the CSECT; CSECT has data and LTORG's first. Hard to get > totally away from base registers, especially if your ARCH does not support > EXR. > > You don't want inline data values that you branch around. They are > cache-killers. Only if you write into the data areas; the OP wrote of constants in macros, so the areas should be read-only.
Re: Base-less macros
Ship an additional required macro, TTLTORG, that pushes the current LOCTR, switches to "your" data LOCTR, issues a LTORG, and then pops the LOCTR. Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Tony Thigpen Sent: Monday, November 8, 2021 6:09 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros My regular code has used location counters for about 20 years. But, that is not applicable to the question at hand, which is a service calling macro provided to customers. Tony Thigpen
Re: Base-less macros
I would agree. How hard is it for the customer to provide an addressable LTORG? It's just like some other requirement that your macro might have, such as "R0 and R1 are available as work registers" or "R13 points to a sufficient save area." Charles -Original Message- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Steve Smith Sent: Monday, November 8, 2021 4:28 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros It is not unreasonable to require your clients to provide a literal pool. It is not your problem, it's the user's. Even IBM accepted this, about 30 years ago, when relative-addressing was invented. Their macros require SYSSTATE ARCHLVL=2 or higher to generate with literals instead of inline data, but that's pretty archaic now. sas
Re: Base-less macros
On Nov 8, 2021, at 08:13:09, Seymour J Metz wrote: > > What's wrong with using LOCTR in a customer-facing macro? > It requires an unlikely degree of coordination between vendor and customer leest a construct like the following unwittingly occur: BAR LOCTR USING *,2 * ... (More stuff) FOO LOCTR L 1,=F'42' * ... (More stuff) BAR LOCTR * ... (More stuff) LTORG The interaction of LOCTR with LTORG is ill-defined. Ideally, there might be a qualifier on each literal controlling which LOCTR owns it rather than assembling all pending literals at any LTORG. -- gil
Re: Base-less macros
What's wrong with using LOCTR in a customer-facing macro? From: IBM Mainframe Assembler List on behalf of Tony Thigpen Sent: Monday, November 8, 2021 9:08 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros My regular code has used location counters for about 20 years. But, that is not applicable to the question at hand, which is a service calling macro provided to customers. Tony Thigpen Seymour J Metz wrote on 11/8/21 8:08 AM: > Well, my preferred approach is to use a location counter. I would say don't > branch around anything, but I like to have extra text in my save area > trace-back, so I put up with the otherwise extraneous branch.. > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on > behalf of Tony Thigpen [t...@vse2pdf.com] > Sent: Sunday, November 7, 2021 7:25 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Base-less macros > > I finally am to the point where I no longer need to worry about specific > customers having hardware that does not support relative instructions, > so I am updating some macros I provide to be baseless. > > What is the 'preferred' approach to macro generated constants? In the > past, I have used both inline constants that I branch around, and ltorg > literals (=c'x'). > > In the past, I have been bitten by using ltorg literals and the client > did not put a LTORG after my macro causing a 'no active base register' > issue. So, I am thinking inline with a BRAS is better. > > Maybe there is another approach that I missed? > > Suggestions? > > Tony Thigpen >
Re: Base-less macros
My regular code has used location counters for about 20 years. But, that is not applicable to the question at hand, which is a service calling macro provided to customers. Tony Thigpen Seymour J Metz wrote on 11/8/21 8:08 AM: Well, my preferred approach is to use a location counter. I would say don't branch around anything, but I like to have extra text in my save area trace-back, so I put up with the otherwise extraneous branch.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Sunday, November 7, 2021 7:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Base-less macros I finally am to the point where I no longer need to worry about specific customers having hardware that does not support relative instructions, so I am updating some macros I provide to be baseless. What is the 'preferred' approach to macro generated constants? In the past, I have used both inline constants that I branch around, and ltorg literals (=c'x'). In the past, I have been bitten by using ltorg literals and the client did not put a LTORG after my macro causing a 'no active base register' issue. So, I am thinking inline with a BRAS is better. Maybe there is another approach that I missed? Suggestions? Tony Thigpen
Re: Base-less macros
On Nov 8, 2021, at 06:35:20, Martin Truebner wrote: > > >>> I'm curious how you EQU &MVC to generate an S-constant properly. > > Like this: > > * below are for USE by EX against instructions in Literal pool > &MVC SETC 'X''512''(13)' > &CLC SETC 'X''512''(5)' > ITYM: &MVC SETC 'X''200''(13)' &CLC SETC 'X''500''(13)' I didn't know you could code an explicit base ini an S-constant. Most people quoted too much; you quote too little. The construct At issue was: >EX R4,=S(&MVC,TARGET,SOURCE) Thanks, Gil
Re: Base-less macros
Paul, >> I'm curious how you EQU &MVC to generate an S-constant properly. Like this: * below are for USE by EX against instructions in Literal pool &MVC SETC 'X''512''(13)' &CLC SETC 'X''512''(5)' Yes- I know the difference between an EQU and a SETC (it is just the old memory that failed) -- Martin
Re: Base-less macros
Well, my preferred approach is to use a location counter. I would say don't branch around anything, but I like to have extra text in my save area trace-back, so I put up with the otherwise extraneous branch.. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tony Thigpen [t...@vse2pdf.com] Sent: Sunday, November 7, 2021 7:25 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Base-less macros I finally am to the point where I no longer need to worry about specific customers having hardware that does not support relative instructions, so I am updating some macros I provide to be baseless. What is the 'preferred' approach to macro generated constants? In the past, I have used both inline constants that I branch around, and ltorg literals (=c'x'). In the past, I have been bitten by using ltorg literals and the client did not put a LTORG after my macro causing a 'no active base register' issue. So, I am thinking inline with a BRAS is better. Maybe there is another approach that I missed? Suggestions? Tony Thigpen
Re: Base-less macros
In general, z/OS macros that accommodate relative branching assume that the user has addressability to a static data area and that they will have a suitable LTORG. And that means that we feel free to use literals in such cases. Of course there are now a lot of "immediate" instructions that can avoid the need for reference to storage containing static data. Peter Relson z/OS Core Technology Design
Re: Base-less macros
> EX R4,=S(&MVC,TARGET,SOURCE) ? -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Martin Truebner [mar...@pi-sysprog.de] Sent: Monday, November 8, 2021 3:26 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Base-less macros >> You don't want inline data values that you branch around. They are >> cache-killers. For certain types it does not realy matter (i.e. OPEN or CLOSE), but if that is a concern I would go to MF=L and MF=E - That is a convention in use since ages. >> ... especially if your ARCH does not support EXR. I never had readability concerns/complains about this EX R4,=S(&MVC,TARGET,SOURCE) with appropriate EQUs at the beginning of the code. Well; almost never. Exception was at some point in the late 90ties, someone at IBM-HLASM group decided to spit out an e-level error, which can be overruled. -- Martin
Re: Assembly Listing headers
Sigh. Well, thanks for looking. I appreciate it. Dave dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell) At 11/8/2021 06:21 AM, Jonathan Scott wrote: David Cole writes: >Is there a way to increase the assembly listing header lines limit >past 8? I looked recently but didn't find anything. Sorry, but I've just had a look at the heading routine, and the limit of 4 lines of USING headers cannot easily be changed. It isn't even a simple constant; there are predefined work fields for each of the USING lines. Jonathan Scott, HLASM IBM Hursley, UK
Re: Base-less macros
Steve, In my specific case, I cant add a LTORG requirement. Although the macro I am working on is specific to our product, I have to provide a compatibility macro that converts another vendors macro to our macro. While I can require the customer to re-assemble, I don't want them to have to rework their existing code. So, a new LTORG requirement is not something I think I can do. Tony Thigpen Steve Smith wrote on 11/8/21 7:27 AM: It is not unreasonable to require your clients to provide a literal pool. It is not your problem, it's the user's. Even IBM accepted this, about 30 years ago, when relative-addressing was invented. Their macros require SYSSTATE ARCHLVL=2 or higher to generate with literals instead of inline data, but that's pretty archaic now. sas
Re: Base-less macros
It is not unreasonable to require your clients to provide a literal pool. It is not your problem, it's the user's. Even IBM accepted this, about 30 years ago, when relative-addressing was invented. Their macros require SYSSTATE ARCHLVL=2 or higher to generate with literals instead of inline data, but that's pretty archaic now. sas
Re: Assembly Listing headers
David Cole writes: >Is there a way to increase the assembly listing header lines limit >past 8? I looked recently but didn't find anything. Sorry, but I've just had a look at the heading routine, and the limit of 4 lines of USING headers cannot easily be changed. It isn't even a simple constant; there are predefined work fields for each of the USING lines. Jonathan Scott, HLASM IBM Hursley, UK
Assembly Listing headers
Hi, I've got a question. Is there a way to increase the assembly listing header lines limit past 8? I looked recently but didn't find anything. You might ask why 8 lines isn't enough. Well... I use named USINGs a LOT! So much so, that I frequently blow through the 8 line limit. And of course, there's only four lines of the header that are available for reporting the USINGs, so it doesn't really take that much to overflow the area. And sometimes I really do need to see something more informative than "More ...". Also, I always assemble with LC(108) because that fits nicely on 8.5x11 paper. So I have lots of page real estate to play with. I really hope the answer is "Yes, dummy. Just read about yadayadayada". Thanks, David Cole dbc...@gmail.com (personal) dbc...@colesoft.com (business) 540-456-6518 (cell)
Re: Base-less macros
Ref: Your note of Mon, 8 Nov 2021 03:32:34 -0700 An attempt to execute a literal gives warning ASMA016W which can be suppressed by the NOEXLITW option. gil writes: > I've seen some surprising behavior such as: >LA R1,=E'3.14' works >DC S(=E'3.14') fails to resolve the same base-displacement. That is simply because literals are processed by the same routine as DC statements, and that routine does not fully support recursive nested calls. The complexity of removing that restriction did not seem to be worth the benefits. Jonathan Scott, HLASM IBM Hursley, UK
Re: Base-less macros
On Nov 8, 2021, at 01:26:34, Martin Truebner wrote: >... > I never had readability concerns/complains about this > > EX R4,=S(&MVC,TARGET,SOURCE) > > with appropriate EQUs at the beginning of the code. > I'm curious how you EQU &MVC to generate an S-constant properly. > Well; almost never. Exception was at some point in the late > 90ties, someone at IBM-HLASM group decided to spit out an e-level > error, which can be overruled. > Does ignoring E- level errors still result in correct generated code? I've seen some surprising behavior such as: LA R1,=E'3.14' works DC S(=E'3.14') fails to resolve the same base-displacement. -- gil
Re: Base-less macros
I decided to put the constant in-line and use BRAS to acquire it's address:
AIF ('&PARM'(1,1) NE ).N0004
BRAS &TREG,N2&SYSNDX
&TVALSETC '&PARM'(2,K'&PARM-2)
N1&SYSNDX DC CL&SIZE'&TVAL'
N2&SYSNDX DS 0H
AGO .N0099
.N0004 ANOP
Tony Thigpen
Bernd Oppolzer wrote on 11/8/21 4:01 AM:
Am 08.11.2021 um 05:40 schrieb Charles Mills:
+1
I have my LOCTR's named CODE and DATA but I agree with the concept:
base register points to the CSECT; CSECT has data and LTORG's first.
Hard to get totally away from base registers, especially if your ARCH
does not support EXR.
You don't want inline data values that you branch around. They are
cache-killers.
Only if you write into the data areas;
the OP wrote of constants in macros, so the areas should be read-only.
Kind regards
Bernd
Charles
Re: Base-less macros
Am 08.11.2021 um 05:40 schrieb Charles Mills: +1 I have my LOCTR's named CODE and DATA but I agree with the concept: base register points to the CSECT; CSECT has data and LTORG's first. Hard to get totally away from base registers, especially if your ARCH does not support EXR. You don't want inline data values that you branch around. They are cache-killers. Only if you write into the data areas; the OP wrote of constants in macros, so the areas should be read-only. Kind regards Bernd Charles
Re: Base-less macros
>> You don't want inline data values that you branch around. They are >> cache-killers. For certain types it does not realy matter (i.e. OPEN or CLOSE), but if that is a concern I would go to MF=L and MF=E - That is a convention in use since ages. >> ... especially if your ARCH does not support EXR. I never had readability concerns/complains about this EX R4,=S(&MVC,TARGET,SOURCE) with appropriate EQUs at the beginning of the code. Well; almost never. Exception was at some point in the late 90ties, someone at IBM-HLASM group decided to spit out an e-level error, which can be overruled. -- Martin
Re: Base-less macros
IMHO, if you are a macro provider and have no control on the environment provided by the open code (which comes from the customer's programmer), the literal approach is more dangerous, because it assumes that the programmer will provide space and addressibility for the literals. Doing LTORG yourself cannot work, as you mentioned already, because you risk to activate literals collected by the client's open code. This will lead to problems, IMO. This said, I would try to avoid constant definitions in such macros, if possible. Use instructions with immediate operands instead. If you absolutely need constants, then in a baseless environment you must IMO establish a temporary base register, for example using register 1, 14 or 15, which you maybe change anyway during your macro expansion. The answers of some other posters which relate to general program layout don't really help in this situation, because you cannot control this when you simply provide a (third party) macro used by the customer's application programmers. HTH, kind regards Bernd Am 08.11.2021 um 01:25 schrieb Tony Thigpen: I finally am to the point where I no longer need to worry about specific customers having hardware that does not support relative instructions, so I am updating some macros I provide to be baseless. What is the 'preferred' approach to macro generated constants? In the past, I have used both inline constants that I branch around, and ltorg literals (=c'x'). In the past, I have been bitten by using ltorg literals and the client did not put a LTORG after my macro causing a 'no active base register' issue. So, I am thinking inline with a BRAS is better. Maybe there is another approach that I missed? Suggestions? Tony Thigpen
