Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

optimization: Transmogrify addressing runes to their values? #36

Open
samueldr opened this issue Jul 2, 2024 · 0 comments
Open

optimization: Transmogrify addressing runes to their values? #36

samueldr opened this issue Jul 2, 2024 · 0 comments

Comments

@samueldr
Copy link

samueldr commented Jul 2, 2024

Following #27:

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".

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.

samueldr added a commit to samueldr/chibicc-uxn that referenced this issue Jul 2, 2024
Fix lynn#27

The remaining suggestion requires understanding where a label point to
so that it can be replaced by its literal equivalent. See lynn#36.
@samueldr samueldr changed the title optimization: Transmogrify addressing runes to their values optimization: Transmogrify addressing runes to their values? Jul 2, 2024
lynn pushed a commit that referenced this issue Jul 17, 2024
Fix #27

The remaining suggestion requires understanding where a label point to
so that it can be replaced by its literal equivalent. See #36.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant