Include identifier in store opcode #2156
Conversation
|
@tsholmes Do you want to put the rest of fixing issue #2152 into this same PR or make separate PR's for them later? |
|
I'm going to make another PR for it later. I made sure to not use any of the trigger phrases ( |
tsholmes
force-pushed
the
feat/ident_in_store
branch
from
475546a
to
06506dc
Compare
It turns out there was a problem buried deep in the compiler, and it was introduced first with commit number #06506dc, with Pull Request KSP-KOS#2156. That commit altered the boilerplate code inserted for triggered locks (steering, throttle, etc), reducing the number of instructions that existed in the boilerplate code chunk. But just prior to those edits, on the line above, there was a br.true +4. Becuse of those edits, there was now one fewer opcode to skip over and the br.true +4 needed to be changed to a br.true +3, and it hadn't been. The result is that when the function $steering* already exists, and it tries to skip over the setting of it, it skips the wrong distance missing a "push", and thus everything on the stack is mis-aligned after that. The reason it hasn't been noticed before is that usually, this case doesn't happen in typical cases. It requires running a boot file that runs a compiled KSM file to encounter the case where that br.true will fire off. Most of the time it was false and not executing, thus the wrong size of how far it jumps wasn't having any effect.
Includes the identifier name in the store, storeexist, storelocal and storeglobal opcodes.
This is the first step to fixing #2152