On Mon, 30 Sep 2013 13:38:28 -0400, Dave Rivers <riv...@dignus.com> wrote:
>I'd love to see that example!
>
Page 3
Active Usings: None
Loc Object Code Addr1 Addr2 Stmt Source Statement
HLASM R6.0 2013/09/30 14.42
000000 00000 00014 1 NEGD64 CSECT
000000 C41C 0000 0008 00010 2 LGFRL R1,=F'2147483392'
R:1 FFFF00 3 USING 2147483392,R1
000006 4140 1200 00100 4 LA R4,-2147483392
5 *
6 YREGS
I'd similarly be interested in how assemblers other than HLASM
treat this. (But not so interested that this should be considered
an RPQ.)
>> And I have a test case showing incorrect base-displacement
>> resolution (it should be unresolvable). The behavior is
>> arguably correct modulo 2**24 and modulo 2**31, but
>> inarguably incorrect modulo 2**64 or using non-congruential
>> arithmetic to any precision. I am little impressed by
>> arguments that HLASM is dedicated to 32-bit arithmetic;
>> generally, overflows are reported as errors.
>>
By my guess, the (mis)behavior arises when base-displacement
resolution fails to detect or ignores an overflow condition
that occurs when subtracting the USING base from the operand
address.
-- gil
