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?
