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.