Hi,
> First point is 8-bit SCI bytecode. And it support only 8,16bit
> paramers.
Good point, of course.
> Or you think bytecode before execution should be pre-parsed to fit new
> 32bit concepts
While this (or even compiling to the host platform's native operation
encoding) would certainly be an option in theory, it might cause issues
with debugging and general jump translation. If we abstract the VM
interface from the data in a reasonable way, we could experiment with this
later, though.
> Second: and what if get rid of stack concepts at all. What SCI stores
> in it? Only temoprary variables needed to call to functions? Or
> something else?
SCI is a stack-based VM, this means that it performs it calculations on
the stack. As such, an SCI compiler might transform an arithmetical
expression such as
4 + (5 * 6)
into a code sequence along the lines of
pushi 4
pushi 5
ldi 6
mul
add
Without re-compiling the scripts, we'd have a hard time getting rid of
the stack usage.
Apart from that, temporary variables (including strings and parameters to
functions and system calls invoked) and selector IDs are stored on the
stack.
> I think that script resource layout should be added to documentation
We already have the basic layout. I'll try to add some more stuff this
evening.
> I will add a couple of pages on this topic. And then continue to
> rewrite it to 32 bit code
OK. BTW, since this involves changes within the VM, it might be a good
idea if we found a way to run two versions of the VM concurrently (old
and new one), to perform automatic error detection.
llap,
Christoph
