A detail, right? In AMODE 64 I could load X'FFFFFFFFFFFFFFF0' into R1, ... Charles
-----Original Message----- From: IBM Mainframe Assembler List [mailto:[email protected]] On Behalf Of Paul Gilmartin Sent: Monday, March 6, 2017 8:44 AM To: [email protected] Subject: Re: HLASM anomaly On 2017-03-06, at 09:18, Charles Mills wrote: > 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? > Not in AMODE 64. The example I gave was (slightly adjusted) to load X'7FFFFFFF' into R1. Then I might L R2,X'80000011'(,R1) which does get the CVT in AMODE 24 or AMODE 31, but in AMODE 64 it accesses X'8000 0010, in the z/OS demilitarized zone. That it works modulo some addressing modes does not excuse its being algebraically wrong. I suppose Jonathan (but not Dave) might argue that some user, somewnere is relying on this behavior and will get a rude shock only when trying AMODE 64. I doubt that there is any case where recognizing overflow as an error would prohibit an algebraically correct result. >> Pieter Wiid <[email protected]> wrote: >>> >>> 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
