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:[email protected]] On
Behalf Of Paul Gilmartin
Sent: Wednesday, March 01, 2017 20:40
To: [email protected]
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.
