Shmuel, all, it's been a long time since I last saw code like that. Worst example was code that XOR-ed the opcode of an AH instruction to switch back and forth between AH and SH to print a report in two columns.
If I still had code like that in my code base, I'd prioritize to make that code RENT. (if I had enough breathing room to make that decision) Kind regards, Abe === Op 02/05/2024 om 19:16 schreef Seymour J Metz: > Except that IEABRC is only necessary for old code. I've inherited code that > uses NOP as a switch, overlaying the mask with F. > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > עַם יִשְׂרָאֵל חַי > נֵ֣צַח יִשְׂרָאֵ֔ל לֹ֥א יְשַׁקֵּ֖ר > > ________________________________________ > From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> on > behalf of Peter Relson <rel...@us.ibm.com> > Sent: Thursday, May 2, 2024 8:37 AM > To: ASSEMBLER-LIST@LISTSERV.UGA.EDU > Subject: Re: IEABRC anomaly > > I don't recall having thought about this when providing IEABRC. But the > conclusion that it's not going to get added is likely a correct one. > > Without a complex macro (which definitely is not going to happen), changing > NOP to JNOP for the cases Jonathan Scott mentioned will reject operands that > are fully valid (avoiding RC=4 if you suppress ASMA212W Branch address > alignment for <x> unfavorable). I believe his case is a very common one of > using the operand of NOP for diagnostic purposes. > > While NOP perhaps isn't a branch (because it never goes anywhere), it is the > conditional branch opcode so could have been a candidate for conversion. But > functionally it is not necessary. Anyone who truly wants conversion of the > operand for some reason could avoid using NOP and code a conditional branch > with mask 0. That will get converted. > > Peter Relson > z/OS Core Technology Design
