Re: Ensuring LRL 2nd operand alignment
AL4, Shirley. IBM used a similar trick with pseudo-register references way back when. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Tom Harper [tomhar...@phoenixsoftware.com] Sent: Tuesday, May 4, 2021 9:48 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Ensuring LRL 2nd operand alignment Here is how I code a similar instruction: CNOP 2,4 LLILF R14,0 ORG *-4 DC A(symbol+X’8000’) BASSM R14,R15 So that the second operand can be an ADCON or VCON. You could do the same with LRL. Sent from my iPhone > On May 4, 2021, at 9:18 AM, Peter Relson wrote: > > Tony H asked about a use case for LRL: > one obvious one is a non-reentrant module. > Or, as Shmuel mentioned, it might have been needed for cases where there > is no binder support for fullword immediate relocatable expressions. > > As to the OP's actual question, there are limited choices that come to > mind > -- the code was not actually running on a z10 or later machine; the OP > says "not the case". > -- If this is VM perhaps they have done something to ask that VM treat the > execution environment as an older machine. There is the concept of the > "virtual architecture level". > -- the data shown does not represent what happened -- either it was not a > PIC 1 or it was not a PIC 1 at that address. If this is repeatable then it > could have been helpful to show some preceding data and have the trace > that was shown cover the instruction before as well. > > Regardless, alignment of the operand is not relevant to the discussion. As > pointed out, a misaligned operand would have resulted in a specification > exception. > > Peter Relson > z/OS Core Technology Design 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: Ensuring LRL 2nd operand alignment
Here is how I code a similar instruction: CNOP 2,4 LLILF R14,0 ORG *-4 DC A(symbol+X’8000’) BASSM R14,R15 So that the second operand can be an ADCON or VCON. You could do the same with LRL. Sent from my iPhone > On May 4, 2021, at 9:18 AM, Peter Relson wrote: > > Tony H asked about a use case for LRL: > one obvious one is a non-reentrant module. > Or, as Shmuel mentioned, it might have been needed for cases where there > is no binder support for fullword immediate relocatable expressions. > > As to the OP's actual question, there are limited choices that come to > mind > -- the code was not actually running on a z10 or later machine; the OP > says "not the case". > -- If this is VM perhaps they have done something to ask that VM treat the > execution environment as an older machine. There is the concept of the > "virtual architecture level". > -- the data shown does not represent what happened -- either it was not a > PIC 1 or it was not a PIC 1 at that address. If this is repeatable then it > could have been helpful to show some preceding data and have the trace > that was shown cover the instruction before as well. > > Regardless, alignment of the operand is not relevant to the discussion. As > pointed out, a misaligned operand would have resulted in a specification > exception. > > Peter Relson > z/OS Core Technology Design 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: Ensuring LRL 2nd operand alignment
Tony H asked about a use case for LRL: one obvious one is a non-reentrant module. Or, as Shmuel mentioned, it might have been needed for cases where there is no binder support for fullword immediate relocatable expressions. As to the OP's actual question, there are limited choices that come to mind -- the code was not actually running on a z10 or later machine; the OP says "not the case". -- If this is VM perhaps they have done something to ask that VM treat the execution environment as an older machine. There is the concept of the "virtual architecture level". -- the data shown does not represent what happened -- either it was not a PIC 1 or it was not a PIC 1 at that address. If this is repeatable then it could have been helpful to show some preceding data and have the trace that was shown cover the instruction before as well. Regardless, alignment of the operand is not relevant to the discussion. As pointed out, a misaligned operand would have resulted in a specification exception. Peter Relson z/OS Core Technology Design
Re: [PossibleSpam] Re: AREAD question
Right... but for the CL, you want F-word alignment anyway, although it would only cause a trivial warning if it wasn't. As for the "oh-so-clever" remark, it only meant reusing an adcon as the branch target... it's a very minor point; I'd just prefer something like B *+1 or EX Rx,* that more clearly doesn't look like an accident. OTOH, it's not as easy if you have no code-base. It is very true that anything is better than a wild branch. sas On Mon, May 3, 2021 at 8:00 PM Tony Thigpen wrote: > Thanks for the alignment issue. I went back and found that a DS 0H was > in the code in some historical copies of the macro, but not in all the > copies. I must have fat-fingered a line delete at some point. > > Also, the SOC1 is only if I did not tell the macro how to handle a bad > value. With some of my code, I am just too deep in the levels and past > all other edits. So, as such, there should "never" be a bad value. So, > instead of having to set up a new message or returning up the code > levels, I want an abend so I can actually review the dump and see what > happened. > > I know too many programmers that say "it will never happen" and so don't > put some sort of trap in "just in case". Eventually, they will get burnt. > > Many years ago, there was a piece of software that put out a message: > "Call Joe at x and tell him he owes Bob $10". Bob had bet Joe that > some condition could never occur, but it did. Bob got his $10. :-) > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
I've done both single macros with lists and separae prolog/item/epilog macros and and haven't seen much of a difference. IMHO, either is preferable to AREAD. I tend to use LOCTR, immediate operands or literals rather than jumping around constants. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Tuesday, May 4, 2021 8:40 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question Ah, OK. If I re-coded this, there would be separate macros for each entry. A final end-of-table macro would set an EQU to the length needed to generate the code. The macros could easily be the same macro source, with a type operand. But overall, I think it's simpler and clearer than to pile multiple entries into an operand list. Much easier to add/delete entries, too (which the AREAD version also has). sas On Tue, May 4, 2021 at 5:33 AM Seymour J Metz wrote: > The added parameter is in place of the AREAD. > >
Re: [PossibleSpam] Re: AREAD question
Ah, OK. If I re-coded this, there would be separate macros for each entry. A final end-of-table macro would set an EQU to the length needed to generate the code. The macros could easily be the same macro source, with a type operand. But overall, I think it's simpler and clearer than to pile multiple entries into an operand list. Much easier to add/delete entries, too (which the AREAD version also has). sas On Tue, May 4, 2021 at 5:33 AM Seymour J Metz wrote: > The added parameter is in place of the AREAD. > >
Re: [PossibleSpam] Re: AREAD question
The added parameter is in place of the AREAD. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Steve Smith [sasd...@gmail.com] Sent: Monday, May 3, 2021 6:32 PM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: [PossibleSpam] Re: AREAD question There's no need for more parameters... just maybe a GBLA. Frankly, I think branch tables are simple enough to code, including automatic range checking, as to not be worth macros at all. Whatever. btw, HLASM is pretty smart, but it doesn't read your commentary: A DCX''FORCE ABEND | MUST BE TOGETHER FOR THE C DCY(*-B) | CL TEST TO WORK TT 050610 You have an unaligned constant in front of an aligned one, and they have to be together. Lucky for you they are until someone tweaks your macro. A DCA(*-B) ..is what you want. That oh-so-clever S0C1 for an out-of-range value will work just as well. sas On Mon, May 3, 2021 at 5:36 PM Seymour J Metz wrote: > The same would be true if you used macro parameters. > > > -- > 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: Monday, May 3, 2021 5:24 PM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: [PossibleSpam] Re: AREAD question > > Because the AREAD enables building the built-in error trapping logic. If > the reg is too large or negative, it's trapped automatically. And, I > don't have to remember to change the limit edits every time I add > something to the branch table. > > Tony Thigpen > >
Re: [PossibleSpam] Re: AREAD question
CLFI? LOCTR?
--
Shmuel (Seymour J.) Metz
http://mason.gmu.edu/~smetz3
From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf
of Jon Perryman [jperr...@pacbell.net]
Sent: Monday, May 3, 2021 11:53 PM
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: [PossibleSpam] Re: AREAD question
AREAD is not recommended for Tony's situation. Instead, follow the standard
assembler conventions and the code will be clean and readable for assembler.
Here is how I would implement Tony's PERFORM_ON macro.
Jon.
PERFORM_ON (R3),BAD_VALUE=ERRNO_2,BRTABLE=(
INITAPI, 00
ACCEPT,01
BIND, 02
CLOSE, 03
CONNECT, 04
FCNTL) 05
MACRO
PERFORM_ON ,_VALUE=,BRTABLE=
.* SAME AS PERFORM_ON
SETC 'A'
AIF ('_VALUE' EQ '' ).NOBV
SETC '_VALUE'
.NOBVANOP
STR15,R15_LASTNot sure why
MACPARM L,R15,
TMLLR15,3 Valid 4 byte offset?
JNZ Invalid, go abend
CLR15,=A(D) < 0 or > branch table size?
JH Invalid, go abend
L R15,B(R15)
BASR R14,R15 call function
J D
A DCX'' FORCE ABEND
B DS0F
SETA 1
.NEXTANOP
DCA(()) Branch table entry
SETA +1
AIF ( LT K').NEXT
D DS0H
MEND
