[Scummvm-devel] Decompiler survey: Variable stack effects

[Michael Madsen]

Hello engine developers,

As part of the decompiler, I will be breaking up the full list of instructions into individual statements based on the effect each instruction has on the stack. When the stack becomes balanced, a statement ends.

In order to use that fact, however, it is necessary that it can be determined uniquely what effect each instruction has on the stack. For most opcodes, this shouldn't be a problem, as the opcode directly tells you what effect it will have on the stack. However, some opcodes, like startScript in SCUMMv6, take a list of arguments from the stack. That requires us to know something about the stack in order to determine the effect - just knowing the opcode is not enough.

Ideally, this should be determinable during disassembly simply by looking at the previous instructions in the bytecode, but this cannot necessarily be guaranteed: in theory, it is possible to fill the stack with the arguments and then perform a jump to the special opcode. Another problem might occur if the information used to determine the size of the argument list isn't pushed as a constant, but taken from a variable.

This brings me to my questions:
1) Does your engine have any opcodes that act in a similar way?
2) If yes, do you know if this sort of thing is actually used in any scripts for your engine?

Most opcodes like this are likely to have been implemented as a magic function in the original compiler, so unless there was some sort of funky optimization going on, this *shouldn't* be a problem for any engines, meaning all of this can be handled when disassembling the scripts.

I'm only interested in stack-based instruction sets for now. While it is certainly interesting to hear about other kinds of instruction sets, the same heuristic is unlikely to be applicable to them, meaning they'd require a different approach - and that would be completely outside the scope of the project. However, I would appreciate it if you can reply to my other thread even if your engine isn't stack-based.

I already know that KYRA does not have any such opcodes, and that while SCUMM v6 has them, it can be handled at disassembly time. I know that HE games has some more difficult opcodes - mainly startObjectQuick - but I do not know if code flow analysis is going to be required to handle all of those, or if it can be handled during disassembly.

Michael