Halfword signed immediate operands outside the range -32768 to 32767 are
only tolerated by HLASM when normal checking is disabled using the options
TYPECHECK(NOSIGNED) or, worse, TYPECHECK(NOMAGNITUDE). As that can lead to
accidents, it is not recommended.
This applies to C'FU', C'LL' and 48000 in the following examples. They can
all be made valid by subtracting X'10000', and it is possible to write an
expression that will automatically apply that correction when necessary,
even for a symbolic value, so it is possible to write a macro which is an
unsigned equivalent of MVHHI, provided that the value does not exceed 65535.
And truncation of 65537 to 1 for an immediate operand is only tolerated by
HLASM when TYPECHECK(NOMAGNITUDE) is specified.
Of course, there is no such check on what a compiler can generate in binary;
if it chooses to list generated instructions as assembler which contains
values that are technically out of range, that won't affect the results.
I agree a shift operator in assembler expressions would be useful (along
with some other functions and operators). It was still on the list when I
retired, mainly because operators are converted to 1-byte internal codes and
there were no free values left in the encoding scheme, so it would have
needed a major design change. Shift functions are available in the macro
language, but can only be used if the value is known at macro time.
Jonathan Scott
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On
Behalf Of Ngan, Robert (DXC Luxoft)
Sent: 25 August 2025 17:20
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: Re: Execute-Type Instructions
You would use MVHI where appropriate, but the MVHI immediate operand is a
SIGNED halfword, so:
MVC XL4a,=C'FULL'
would be coded as:
MVHHI XL4a+0,C'FU'
MVHHI XL4a+2,C'LL'
And:
MVC XL4b,=F'48000'
would be coded as:
MVHHI XL4a+0,0
MVHHI XL4a+2,48000
And:
MVC XL4b,=F'65537'
would be coded as:
MVHHI XL4a+0,65537>>16 i.e. 1
MVHHI XL4a+2,65537 which HLASM conveniently
truncates to 1 for us
There no actual SHIFT operator, so (in general) this is implemented as an
arithmetic expression.
Robert Ngan
DXC Lusoft
-----Original Message-----
From: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> On
Behalf Of João Reginato
Sent: Saturday, August 23, 2025 07:53
To: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Subject: RES: Execute-Type Instructions
Importance: Low
[Algumas pessoas que receberam esta mensagem geralmente não receberão emails
de 00001deb39c13de1-dmarc-requ...@listserv.uga.edu. Saiba por que isso é
importante em https://aka.ms/LearnAboutSenderIdentification ]
Why not just one MVHI instead of two MVHHI?
-----Mensagem original-----
De: IBM Mainframe Assembler List <ASSEMBLER-LIST@LISTSERV.UGA.EDU> Em nome
de Jon Perryman Enviada em: sábado, 23 de agosto de 2025 00:12
Para: ASSEMBLER-LIST@LISTSERV.UGA.EDU
Assunto: Re: Execute-Type Instructions
On Fri, 22 Aug 2025 17:00:33 +0000, Ngan, Robert <robert.n...@dxc.com>
wrote:
>I noticed the COBOL compile generated two MVHHI's to set a fullword
>field with a constant value, but did an MVC with an 8-byte constant
>when setting two adjacent fullwords.
This makes sense because data is in the pipeline instead of moving from L1.
With inline constants, you eliminated the extra fetch from storage. Ask
yourself if it's worth the effort to eliminate the extra L1 access. You're
running C, Java, Python and ??? where you can save a few dollars instead of
a few penniess.
