Paul Gilmartin notes:
> Surely similar problems must have arisen with the s360 which
> generated a specification exception at execution time for
> reference to an unaligned operand, which may have been coded
> as a literal.
Maybe, but the alignment requirement was more in your face, and
so nobody took offense when they specified a literal that was
not defined to have the required alignment. The issue with LARL
is that it's not obvious to the coder, sometimes, nor to a macro,
that the operand being addressed is not going to be able to be
addressed. In other words, sometimes it will just work out OK,
and sometimes it will not work out, the literal being allocated
on a non-half-word boundary. But in order to come up with some
literal operand to a System/360 instruction that could result in
an S0C6 ABEND (because of non-word, half-word, or double word
alignment) you would have to contrive an example that would (as
with LARL) work only sometimes. I think all such instances will
have to be contrived, since it would not be natural to define a
literal operand without the proper (correctly aligned and exact
length) attribute to begin with.
Here's an example that would (potentially) fail on System/360:
L R1,=X'55' Get X'55' into high order byte
That will work some of the time, but only if you're lucky and
the code doesn't really care what's in the low order 3 bytes.
But it's a contrived example, and not an "innocent" error as
in the case of LARL. And that's the difference. I think it
would simply be nice if the Assembler automatically aligned
literal operands of, for example, LARL. It could use any extra
unused single byte at the end for other 1-byte literals for
extra brownie points. But is this necessary (cost justified)
for IBM to do, in lieu of other needed enhancements? I think
it's pretty low on MY priority list. I recognize that others
may find it offensive because it results in problems, such as
in macros where one is trying to use LARL for all the good
reasons one should use LARL.
--
WB
