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 On Fri, Aug 11, 2023 at 7:17 PM Jon Perryman <[email protected]> wrote: > > 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. >
