[Scummvm-devel] Decompiler survey: Variable stack effects

[Michael Madsen]

> -----Original Message-----
> From: Paul Gilbert [mailto:paulfgilbert at gmail.com] 
> Sent: Sunday, June 13, 2010 1:47 AM
> To: ScummVM devel
> Subject: Re: [Scummvm-devel] Decompiler survey: Variable stack effects
> 
> On Sat, Jun 12, 2010 at 10:47 PM, Michael Madsen <michael at birdiesoft.dk> wrote:
> 
> > 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?
> 
> Well, the Tinsel engine is probably one such example. It's stack based, 
> and one of the fundamental opcodes is 'OP_LIBCALL'. This opcode is 
> basically an interface to a whole bunch of intrinsic support functions.
> How many parameters get popped off the stack (as parameters for each 
> method) depend on which method is called, which is passed as an 
> immediate parameter along with the opcode.
> 
> There can be many such calls within the one script, so the only way 
> disassembly could be reasonably handled for this engine, eventually,
> would be to have support in the decompiler for special handling for 
> this instruction to have a lookup table that returns the number of 
> parameters popped off the stack for each given method Id. At the same 
> time, it might be useful to be able to replace the immediate value of 
> the method Id with a descriptive name as well in the resulting disassembly.

Actually, it sounds like the answer to 1) would be "no", then. If I understand you correctly, OP_LIBCALL could be considered a multi-byte opcode, with the method ID acting as the remaining part. This is already possible to handle with the current structure, and I even have some of these in my SCUMMv6 disassembler (for example 0x6B, which contains a number of "sub-opcodes" related to cursors).

As long as the stack effect is known for each individual method, then the answer to 1) is "no", and there should be absolutely no problem here. The potential problem can only occur if one of those intrinsic methods can take a *variable* number of arguments from the stack - for example taking an array or a list placed directly on the stack instead of being placed somewhere in memory and referred to by a pointer on the stack.

Michael