Changing the name of an instruction, or slight changes in cache size can cause the generated code to be incorrect in odd ways.
This is a result of there being too many special cases and undocumented assumptions built in to the code generator.
This was a natural result of getting the thing working and was, until now, acceptable technical debt.
However, as we want to generate abstract interpreters, a new combiner tier-1/tier-2 interpreter and possible tail-calling interprtet/JIT compiler pair, things are too fragile.
We need to:
- Reduce the number of ad-hoc special cases in the tools to zero.
- Minimize and very clearly specify any special markers and variables we use in
bytecodes.c
- Clarify the in-memory state and transitions of execution.
- Document the representation of that state in the various tiers and components.
Linked PRs
Changing the name of an instruction, or slight changes in cache size can cause the generated code to be incorrect in odd ways.
This is a result of there being too many special cases and undocumented assumptions built in to the code generator.
This was a natural result of getting the thing working and was, until now, acceptable technical debt.
However, as we want to generate abstract interpreters, a new combiner tier-1/tier-2 interpreter and possible tail-calling interprtet/JIT compiler pair, things are too fragile.
We need to:
bytecodes.cLinked PRs
next_instrconsistently at the start of the instruction. #111486BEFORE_WITHa uop #111812TIER_ONE_ONLY#113155TARGETtable for computed goto dispatch. #113319FOR_ITERin tier2 #113394