Currently all expression evaluation happens with 16 bit width: All additions, shifts, logic operators, all happen with 16 bit (lobyte in A, hibyte in X). The same goes for all hardware stack pushes during expression evaluation: Always 2 pushes: pha:txa:pha.
It would be nice if the calculations could be limited to 8 bits where those are sufficient.
v-assembler.fth already has the basic mechanism needed for this in the form of the "sized" .lda.s etc. pseudo-operations, where the template contains w: ;w and b: ;b sequence snippets that are only instantiated for word or byte size operations, respectively.
The biggest challenge would be to keep track of the size of each hardware stack push, but since the parser keeps a compile time stack of object types (incl. size) in sync with the runtime hardware stack, the basis for this is also already in place.
Still, it would be a non-negligible effort, and might easily cost a few hundred bytes in compiler size, so that should be checked beforehand, esp. wrt. the chronically tight memory at compiler compile time on the X16.
Currently all expression evaluation happens with 16 bit width: All additions, shifts, logic operators, all happen with 16 bit (lobyte in A, hibyte in X). The same goes for all hardware stack pushes during expression evaluation: Always 2 pushes: pha:txa:pha.
It would be nice if the calculations could be limited to 8 bits where those are sufficient.
v-assembler.fth already has the basic mechanism needed for this in the form of the "sized" .lda.s etc. pseudo-operations, where the template contains w: ;w and b: ;b sequence snippets that are only instantiated for word or byte size operations, respectively.
The biggest challenge would be to keep track of the size of each hardware stack push, but since the parser keeps a compile time stack of object types (incl. size) in sync with the runtime hardware stack, the basis for this is also already in place.
Still, it would be a non-negligible effort, and might easily cost a few hundred bytes in compiler size, so that should be checked beforehand, esp. wrt. the chronically tight memory at compiler compile time on the X16.