On Sep 14, 2010, at 18:27, John R. Ehrman (408-463-3543 T/543-) wrote:
> Think of it this way: the USING specifies "Max-16" and the implied
> address specifies -(Max-16) so the difference between the two that's
> needed for the displacement is the implied address minus the USING
> value, or (-(Max-16)-(Max-16))=(-2*Max)+16+16=32, which to 31 bits
> is 32=X'020'.
>
Or, in hex, replacing subtractions by complement and addition:
x'80000010'
+ x'80000010'
= x'100000020' >32 bits!
But an overflow occurred and was ignored by HLASM. Otherwise
The lowest 32, not just 31, bits are correct. But more code:
Loc Object Code Addr1 Addr2 Stmt Source Statement
HLASM R6.0 2010/09/15 09.04
000000 00000 00020 1 NEGD64 CSECT
000000 C41C 0000 000C 00018 2 LGFRL R1,=A(X'7FFFFFF0')
R:1 FFFFF0 3 USING X'7FFFFFF0',R1
000006 4143 1020 00010 4 LA R4,-X'7FFFFFF0'(R3)
5 *
000010 6 X33 EQU -X'7FFFFFF0'
7 Y33 EQU X33+X33
** ASMA075E Arithmetic overflow
** ASMA158E Operand expression is defective; set to *
** ASMA435I Record 7 in user.NEGD64.JOB08415.D0000101.? on volume:
This shows that HLASM doesn't generally ignore overflows. Why does
it tolerate them in the case of implied address resolution? In this
case an overflow almost certainly occurred. And 31-bit correctness
is not a rationale:
00000A C41C 0000 0009 0001C 9 LGFRL R1,=A(X'3FFFFFF0')
R:1 FFFFF0 10 USING X'3FFFFFF0',R1
000010 0000 0000 00000 11 LA R4,-X'3FFFFFF0'(R3)
** ASMA028E Invalid displacement
** ASMA435I Record 11 in user.NEGD64.JOB08415.D0000101.? on volume:
12 *
000010 13 X32 EQU -X'3FFFFFF0'
000020 14 Y32 EQU X32+X32
15 *
000018 16 LTORG
000018 7FFFFFF0 17 =A(X'7FFFFFF0')
00001C 3FFFFFF0 18 =A(X'3FFFFFF0')
19 YREGS
The arithmetic:
x'C0000010'
+ x'C0000010'
= x'80000020'
For AMODE 31, HLASM could resolve the implied address at line
10 using R1 as a base, even as it did at line 4. HLASM insists
on not merely 31 bit correctness, but on 32 bit correctness
for address resolution.
The result at line 4 is radically incorrect for AMODE 64; it's
tolerated for AMODE 31 or AMODE 24. When/if HLASM is ever
enhanced to support 64-bit expression evaluation will need to
issue ASMA028E. Isn't it better to bite that bullet early rather
than to leave a pitfall to be encountered in the future?
-- gil
