I'm going to make a somewhat incompatible change to the assembler, and would like to hear about current usage to make the change less intrusive. Currently, all expressions are evaluated using (at least) 32 bit values within the assembler. Exported symbols are truncated to 32 bits. One problem that proved to be serious in some cases is that the assembler doesn't have a clear notation of signedness: Symbol values are handled as signed or unsigned values depending on the context. An example is foo = -1 lda #foo ; Error: Out of range Since the internal representation of foo is $FFFFFFFF, and since the lda instruction expects an 8 bit operand, the assembler would output an error. My plan is to resolve these ambiguities by explicitly defining numeric values to be always 32 bit signed. Neither the 6502 nor the 816 can handle 32 bit values, so most programs don't use values where bit 31 is used as a value bit (and not as a sign bit). In addition, it would still be possible to do something like foo = $FFFFFFFF but internally foo would be represented as -1. It is also possible for the code written, to handle such values as unsigned, but again, the assembler itself will always handle them as signed values. 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. There may be other, less obvious problems. While the change would not affect most programs, there may be some that run into problems. So I would like to evaluate how many such programs exist, and if there is something I can do to ease the transition. If you have written code that depends on the current interpretation of 32 bit values, please let me know. Happy easter! Uz -- Ullrich von Bassewitz uz@musoftware.de ---------------------------------------------------------------------- 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 12:40:55 2004
This archive was generated by hypermail 2.1.8 : 2004-04-09 12:41:01 CEST