Ref: Your note of Wed, 25 Apr 2018 09:32:53 -0600 Paul Gilmartin wrote: > Jonathan Scott wrote: > > The problem is that calculations of the form A-B+C evaluated using > > 31-bit signed arithmetic can sometimes overflow 31 bits for an > > intermediate result yet give a correct final result (equivalent to > > performing the calculation in a different sequence). If HLASM rejected > > any displacement calculation that caused overflow for an intermediate > > result, this could break existing code. > > > Wouldn't the same be true of the operand of an EQU? Programmers deal > with it. But having allowed it historically sets the stage for > complaints that it "could break existing code." I'd prefer to say, > "expose long-standing errors." > > 33 bits might not suffice for an expresion with too many terms.
For any single expression, overflow is considered an error. Resolving a displacement (especially for a dependent USING) can require two additional arithmetic operations behind the scenes, and the order in which those are performed could affect whether overflow occurs. As valid addresses cannot be negative, we think that one additional bit is sufficient to track whether overflow occurs on one operation and is not cancelled by overflow the other way on the other operation. Jonathan Scott IBM Hursley, UK
