You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
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.
The text was updated successfully, but these errors were encountered:
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.
The text was updated successfully, but these errors were encountered: