New: Add the support for compiling two bytecodes as a super-instruction.
Improve: Improve some optimisations related to constant (well-known objects really, like trueObject) propagation and block splitting. It was necessary for merging comparison + jumps in the expected way (remove must be boolean and push/pop of the boolean).
Fix: Fix where to flush stack algorithm, it was failing in my case.
It also generate the code to read next bytecode + checks
To make the super-instruction, I changed the meta-compiler to work with a list of methods (not only one). They are meta-interpreted in sequence.
I also need more info about the bytecodes (not only the sourceSelector). At least the bytecode number: bytecodes: { bytecode -> aSelector }.
This is an ad-hoc implementation, old uses are still working. I didn't want to make a big refactor for this yet.
TODOs (for next iteration)
[ ] Fixups to merged bytecode: We need to fix the fixup of jumps to the merged bytecode (the second one) to jump "in the middle of the super-instruction".
New: Add the support for compiling two bytecodes as a super-instruction.
Improve: Improve some optimisations related to constant (well-known objects really, like
trueObject) propagation and block splitting. It was necessary for mergingcomparison + jumpsin the expected way (remove must be boolean and push/pop of the boolean).Fix: Fix where to flush stack algorithm, it was failing in my case.
How to use it?
The first bytecode is annotated with the next one(s) to be combined. https://github.com/PalumboN/druid/blob/ee70f861f25bf916c85d20a0b3a4b78c67aef454/Druid-Tests/DruidTestInterpreter.class.st#L94-L99
Then the meta-compiled generator will:
ifchecking for each next bytecode, if true:bytecodePCand call the generator of the super-instruction.https://github.com/PalumboN/druid/blob/ee70f861f25bf916c85d20a0b3a4b78c67aef454/Druid-Tests/DruidTestRTLCompiler.class.st#L2127-L2141
About the implementation...
DRSuperInstructionCustomisationTo make the super-instruction, I changed the meta-compiler to work with a list of methods (not only one). They are meta-interpreted in sequence.
I also need more info about the bytecodes (not only the
sourceSelector). At least the bytecode number:bytecodes: { bytecode -> aSelector }.This is an ad-hoc implementation, old uses are still working. I didn't want to make a big refactor for this yet.
TODOs (for next iteration)
fixupof jumps to the merged bytecode (the second one) to jump "in the middle of the super-instruction".