On 2017-02-28, at 14:02, Melvyn Maltz wrote: > To restate what I'm asking for... > Now that we have 2 and 4-byte immediate values it would make sense > to allow both duplication factor and explicit length for these > Currently the instructions below would fail > AHI 1,2X'FF' > CFI 1,XL4'FF' > > Rather more contentious, I agree, is to imply an explicit length > of 1, 2, or 4 bytes to any immediate if there were no dup/explicit > already present > > So, CFI 1,C'9' generates X'000000F9' (yuk) > But if it were forced to have an explicit length it would be > interpreted as CL4'9'=X'F9404040' which is what you might expect ??? > Ok, I'll be shot down on that one, but I'll still submit it > Bang!
C9 EQU C'9' Assigns x'000000F9 to the symbol. Would you nave it otherwise? Then, DC AL4(C9) generates x'000000F9' Would you have it otherwise? > Paul Gilmartin---How do you feel about AHI 1,X'00FFFF' > ... > Yes, AHI 1,65535 is valid > And here, I part company with HLASM, or at least with its Reference. PoOps states that the operand of AHI is "taken as" a 16-bit signed binary number. 65535 is not in that range. HLASM should report an operand range error (best) or at least the Ref. should clearly specify how out-of-range operands are treated. HLASM would benefit for stricter operand checking, but also a richer repertoire of arithmetic operators/functions. -- gil
