From: "Ullrich von Bassewitz" <uz@musoftware.de> > My plan is to resolve these ambiguities by explicitly defining numeric values > to be always 32 bit signed. If you're going to choose one sign, I'd say make it unsigned. Unsigned numbers are a bit more "literal", as bits in your number directly translate into bits, and we assembly programmers like that. :) But if A = -1 and A = $ffffffff both end up being the same thing (ie, the $ffffffff doesn't give an out-of-range error in signed mode), I doubt it will even matter what the internal representation is, though unsigned would be my preference. > An operator that will change its meaning in the transition is the shift > operator. Shifts are currently unsigned. That is, > > $FFFFFFFF >> 1 = $7FFFFFFF > > This will change, but new unsigned shift operators will be made available. I'd prefer to leave shifts as unsigned shifts, and add signed shift operators. This would mirror 6502 functionality, where you'd need to to something special to make a shift signed, and since this is a 6502 family assembler it would be reasonable to have signedness assumptions be consistent between the assembly code and the pseudo-ops. -- White Flame (aka David Holz) http://www.white-flame.com/ ---------------------------------------------------------------------- To unsubscribe from the list send mail to majordomo@musoftware.de with the string "unsubscribe cc65" in the body(!) of the mail.Received on Fri Apr 9 13:45:24 2004
This archive was generated by hypermail 2.1.8 : 2004-04-09 13:45:30 CEST