If they are documented that way then it's legitimate, and, as you note, it provides more information then the assembler equivalent.
IBM's current compilers for C, COBOL and PL/I use a common back end; the last I heard, IBM was not using that back end for Ada or FORTRAN, although those may no longer be supported. I would have expected them to use peephole optimization by now. -- Shmuel (Seymour J.) Metz http://mason.gmu.edu/~smetz3 ________________________________________ From: IBM Mainframe Assembler List [ASSEMBLER-LIST@LISTSERV.UGA.EDU] on behalf of Bernd Oppolzer [bernd.oppol...@t-online.de] Sent: Friday, November 12, 2021 2:58 AM To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: Curious compiler optimization This is the usual way the generated statements are documented in the pseudo assembly listings since (I think) 20 years now, no matter if the compiler is C, PL/1 or COBOL (don't know about others). The shown ASSEMBLER code would not work, of course, but it shows the variable or structure names AND the offsets and base registers (sometimes other information like the name of intenal compiler work areas, control blocks etc.). What the "pseudo" assembly listing does: trying to put as much information as possible into the pseudo assembly notation, while still showing what the original machine instruction looks like. IMO, this "pseudo" notation is a clever solution, and: it is not an error. This said: most Windows etc. based compilers don't even have a compiler listing; at least it is completely uncommon to use it there. Kind regards Bernd Am 12.11.2021 um 03:46 schrieb Seymour J Metz: > If that were assembler source it would be invalid, but IBM uses various > pseudo-assembler formats in their compiler listings. > It's confusing and ugly, but unless IBM documents a different format it's > probably Broken As Designed (BAD). > > > -- > Shmuel (Seymour J.) Metz > http://mason.gmu.edu/~smetz3 > > > > > With NOOPT: > > * int var = 0; > > LA r4,0 > LR r0,r4 > ST r0,var(,r13,160) > > And I'm unclear what > > var(,r13,160) > > is supposed to be-the actual generated opcodes are > > 5000 D0A0 > > Which makes sense. Feels like there's an extra comma in there and an extra > offset. Maybe this is the compiler's way of saying "This is tinkering with > var, which is at offset 160"? I.e., it explicitly mentions both the variable > name and the 160 for readability? >
