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
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
> Mark Hammack
> YES EQU X'FF'
> NO EQU X'00'
> TRUEEQU -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
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
