Hardware address arithmetic has always allowed overflow, right?

I could load X'FFFFFFF0' into R1, do L R2,32(,R1) and get the CVT, right?

Charles

-----Original Message-----
From: IBM Mainframe Assembler List [mailto:[email protected]]
On Behalf Of Jonathan Scott
Sent: Monday, March 6, 2017 6:24 AM
To: [email protected]
Subject: Re: HLASM anomaly

Ref:  Your note of Mon, 6 Mar 2017 07:43:25 -0500

I noticed some time ago that HLASM fails to check properly for overflow
during USING calculations, which in my opinion is a bug in HLASM.  However,
it's not just a matter of checking each calculation for overflow, because
intermediate calculations could overflow (depending on the order in which
they are done) even when the final result is valid, and rejecting that with
an overflow indication could cause problems for existing programs.

By ignoring overflow and just letting calculations wrap round, the current
implementation tolerates all cases where the final result is valid but fails
to detect some cases which should have been rejected.

I think that conceptually the result should be as if HLASM did the
intermediate calculations using a larger field (for example using 63-bit
signed arithmetic) then checked whether the final result was in the valid
range for a 31-bit signed offset, giving an overflow indication if not.  It
may well be possible to implement that rule without actually using a larger
field.

Jonathan Scott
IBM Hursley, UK

> Pieter Wiid <[email protected]> wrote:
> >
> > Your USING should be USING X,R2
> > Then, you get this with HLASM (z/OS 2.2)
> >
> >                        00002           1 R2 EQU 2
> >                        00003           2 R3 EQU 3
> > 000000                00000 00004     3 FOO CSECT
> >                       FFFFFF           4 X        EQU X'7FFFFFFF'
> >                   R:2 FFFFFF           5          USING X,R2
> > 000000 4130 2002            00001     6          LA R3,-X
> >
>
>  Ugh - yep - you're right.
>
>  And, that's a difference from us, we get this:
>
>                         7FFFFFFF               4 X        EQU
X'7FFFFFFF'
>                         7FFFFFFF               5          USING X,R2
> 00000000 0000 0000               00000000      6          LA    R3,-X
> ** DASM028E Invalid displacement
> ** DASM435I Record 6 in t2.asm
>
>  that means, for this bright Monday morning - I'll have to enter a bug.
>
>     - Dave Rivers -
> --
> [email protected]                        Work: (919) 676-0847
> Get your mainframe programming tools at http://www.dignus.com

Reply via email to