I was interested in the top half of the fullword, your equates give me the bottom half, which I do not need to do anything special for since HLASM truncates the value correctly when used directly on the MVHHI instruction. However, I can use your code to strip the low order half off the value before dividing by 65536, which resolves my issue of the value being potentially "off by one" when a negative value is divided.
&M1 SETC '(&IMM-((&IMM)/65536)*65536)' &M2 SETC '(&M1+65536)-(&M1+65536)/65536*65536' &M3 SETC '(&IMM-&M2)/65536' PUSH ACONTROL,PRINT,NOPRINT PRINT NOGEN,NOPRINT Suppress printing of following ACONTROL ACONTROL NOTYPECHECK Suppress annoying ASMA320W messages POP PRINT,NOPRINT Print following instructions MVHHI &TO+0,&M3 Set first half of fullword MVHHI &TO+2,&IMM Set second half of fullword POP ACONTROL,NOPRINT The example "expression" I was messing with was actually SAVF4SAID_VALUE (i.e. C'F4SA') which when divided by 65536 gives C'F5' instead of C'F4'. However &M3 above generates the expected value. Robert -----Original Message----- From: IBM Mainframe Assembler List [mailto:ASSEMBLER-LIST@LISTSERV.UGA.EDU] On Behalf Of Paul Gilmartin Sent: Wednesday, March 01, 2017 20:40 To: ASSEMBLER-LIST@LISTSERV.UGA.EDU Subject: Re: HLASM anomaly On 2017-03-01, at 17:35, Ngan, Robert wrote: > I noticed the new COBOL compiler was generating: > > MVHHI target,0 > MVHHI target+2,48000 > > instead of: > > MVC target,=F'48000' > > and I thought I'd look into using 2 MVHHI's instead of a MVC with a literal > even when the top half of the value is non-zero. The assembler happily > accepts: > > MVHHI target+2,C'abcd' > > truncating the leading 'ab', but I gave up since I could not determine how to > consistently obtain the top half of the value when it is a general > (resolvable at assembly) expression, ... > How about, with the miracle of integer arithmetic: ABCD EQU c'abcd' Then (best done in a macro): DEN EQU 65536 M1.SYSNDX EQU ABCD-ABCD/DEN*DEN M2.SYSNDX EQU (M1.SYSNDX+DEN)-(M1.SYSNDX+DEN)/DEN*DEN MVHHI target,(ABCD-M2.SYSNDX)/DEN I believe this is safe against oveflows, but I haven't proven it formally. -- gil CSC - This is a PRIVATE message - If you are not the intended recipient, please delete without copying and kindly advise us by e-mail of the mistake in delivery. NOTE: Regardless of content, this e-mail shall not operate to bind the Company to any order or other contract unless pursuant to explicit written agreement or government initiative expressly permitting the use of e-mail for such purpose.