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
Static arithmetic in oneko, like ;theCursor_ #0004 ADD2, which could be merged into a LIT2.
Without knowing where ;theCursor points to, it is hard impossible to apply this static optimization.
In my naïve "don't really know about compilers" mind, I'm thinking this is not that hard, as long as we're clever.
My guesstimation is that it would require placing “placeholder literal” values within the program, which keep a ref to the labels. The placeholders can be optimized just like LIT* could be...
Someone more clever than me could think up a scheme where the literals are handled the same way to make it the same operation. After all, what's the difference between ;abc #0002 ADD2 and #f000 #0002 ADD2? The only difference is one's value is only known after the program length is final. So the placeholder would need to be able to keep context about all the values folded in, labels and literals.
After this pass of optimizations is done, optimizations that don't change the program length can be ran... The labels, I presume may not always come from before, to the length of the program matters.
Oops, I guess this would also require computing each Instruction's address... otherwise it gets awkward. But also maps well to the semantics of this being a last pass.
Hopefully these ramblings made sense.
EDIT: uuuuh, I kinda forgot about how this wouldn't work cleanly because it would require strong assumptions that the generated assembly is "final".
It would make more sense to implement this as an external stage, given an "all includes and macros resolved" version of the .tal representation, then the assumptions are known facts, and can be optimized in/out.
The text was updated successfully, but these errors were encountered:
samueldr
added a commit
to samueldr/chibicc-uxn
that referenced
this issue
Jul 2, 2024
samueldr
changed the title
optimization: Transmogrify addressing runes to their values
optimization: Transmogrify addressing runes to their values?
Jul 2, 2024
Following #27:
Without knowing where
;theCursor
points to, it ishardimpossible to apply this static optimization.In my naïve "don't really know about compilers" mind, I'm thinking this is not that hard, as long as we're clever.My guesstimation is that it would require placing “placeholder literal” values within the program, which keep a ref to the labels. The placeholders can be optimized just likeLIT*
could be...Someone more clever than me could think up a scheme where the literals are handled the same way to make it the same operation. After all, what's the difference between;abc #0002 ADD2
and#f000 #0002 ADD2
? The only difference is one's value is only known after the program length is final. So the placeholder would need to be able to keep context about all the values folded in, labels and literals.After this pass of optimizations is done, optimizations that don't change the program length can be ran... The labels, I presume may not always come from before, to the length of the program matters.Oops, I guess this would also require computing eachInstruction
's address... otherwise it gets awkward. But also maps well to the semantics of this being a last pass.Hopefully these ramblings made sense.EDIT: uuuuh, I kinda forgot about how this wouldn't work cleanly because it would require strong assumptions that the generated assembly is "final".
Especially with #35, the assembly might not be.
It would make more sense to implement this as an external stage, given an "all includes and macros resolved" version of the
.tal
representation, then the assumptions are known facts, and can be optimized in/out.The text was updated successfully, but these errors were encountered: