Constants in MVI/CLI instructions

[Mark Hammack]

I came across something working on a new (to me) assembler program. The
program was written many years ago and the programmer used C'Y' and C'N' as
flags. Sometime later, another programmer added:

YES EQU X'FF'
NO EQU X'00'

For some "new" flags that were added (there are external flags that still
require Y/N characters). What I was trying to do was to add:

TRUE EQU -1
FALSE EQU 0

To add some consistency with the C code I also support. However:

MVI FLAG,TRUE

Causes an ASMA320W message (which I understood after thinking about it). I
know I can turn off magnitude checking (I've run into this before trying to
play loose with "halfwords"), but would rather keep it on.

I guess I could define TRUE as X'FF' (or 1 for that matter) which would
take care of the 99% (the reason not to use x'01' would be to make it
easier to read in a dump). However, in another nod to C, there may be a
case somewhere that a fullword is being used a bool. MVHI (and MVHHI for a
halfword bool) doesn't sign extend x'FF' to x'FFFFFFFF' (or x'FFFF").

Yes, it's a very minor thing which I've already resolved but it would be
nice if the assembler "understood" that x'FF' and -1 are "equivalent" in a
1 byte immediate instruction (like -1 and x'FFFF" are equivalent in a
halfword immediate instruction). And yes, I realize that bytes are
unsigned whereas anything bigger is signed.

Thanks!



*Mark*

[Jon Perryman]

> Mark Hammack

> YES EQU X'FF'
> NO EQU X'00'

> TRUE EQU -1
> FALSE EQU 0

Using TRUE EQU YES makes your intent clear. Coding X'FF' would be consistent. -1 should not be used.

> I realize that bytes are unsigned whereas anything bigger is signed.

Numbers in HLAsm are signed or unsigned and have a length of 2, 4 or 8 bytes (ignoring float & packed). 1 byte is not considered a number.

> it would be nice if the assembler "understood" that x'FF' and -1 are "equivalent"

In C, they are equivalent but HLAsm is warning us that it's making an assumption about our intent.

> MVHI (and MVHHI for a halfword bool) doesn't sign extend

I'm not familiar with these instructions but I assume they are for the C compiler. If there aren't signed equivalents, then I'm guessing the C compiler did not need them.

[Steve Smith]

MVHI and MVHHI operate on signed operands, and do sign extension. The
point was that 255 (x'ff') isn't a negative number, and so won't produce
the 2 or 4 bytes of all ones that he wants. Jonathan Scott has explained
the workings of HLASM absolute values more than once... it is what it is.
But fundamentally, you really can't use signed numbers in a logical context
and not expect there's going to be some issues.

There is some limited support for 8-bit signed numbers. LB I know about,
and I have vague memories of vector support. Oh yeah, there's CIB/J, which
also has a signed 1-byte operand.

As for the assembler "understanding". It does what you want, you just
don't like the warning, which you prefer not to suppress. Anyway, I think
HLASM does the best it can to accommodate all desires.

sas

[Jonathan Scott]

If you have APAR PH38969 (from July 2021) installed, HLASM
supports the new option TYPECHECK(NOSIGNED) which bypasses
checking for whether an immediate operand value is signed or
not. This allows a signed value to be used for an unsigned
immediate operand and the other way round, provided that the
value is still within the valid range for the size of the
operand field.

This is safer than the old trick of using TYPECHECK(NOMAGNITUDE)
in such cases as it does not tolerate values which are outside
the valid range. However, as it is effectively a way of quietly
hiding a minor error, it is not an ideal way to write code.

Jonathan Scott, HLASM
IBM Hursley, UK