On 2017-02-23, at 23:54, John Dravnieks wrote: > > Unless the assembler is redesigned to use just one expression processor, > there will always be differences in between instruction operands and DC > operands > I see little value in attempting to eliminate that difference and much value in preserving the use of expressions as immediate operands. > And there are further complications - the instruction operand arithmetic > is done using 32 bit signed binary values and it is only at the end of the > process where the target operand properties are considered . > So by way of an example,16 bit immediate operands come in three flavours: > > Arithmetic (for example, AHI) - the value is range checked to be > between -32768 and +32767. So AHI R1,-1 is acceptable, but AHI > R1,X'FFFF' is not > But I'd expect AHI R1,X'FFFF8000' to be acceptable (somewhat surprisingly). And this would be a compatibility impediment to the (already unlikely) extension of expressions to 64-bit arithmetic. Compatibility could be preserved with an idiosyncratic rule that hexadecimal terms of 8 digits are more are sign-extended to 64 bits; hexadecimal terms of 7 digits or fewer are 0-extended.
On 2017-02-24, at 01:05, [email protected] wrote: > > the two instructions > > AHI 1,-1 > AHI 1,X'FFFF' > - > if they are compiled produce coding > > 00000000 90EC D00C 0000000C 5 STM 14,12,12 > (13) > 00000004 A71A FFFF FFFFFFFF 6 AHI 1,-1 > > 00000008 A71A FFFF 0000FFFF 7 AHI 1,X'FFFF' > You're contradicting John D. here. What about: B EQU 65535 AHI R1,B * Should be invalid A EQU X'FFFF' AHI R1,A * ??? ??? -- gil
