Hi,
On Tue, 29 May 2001 [EMAIL PROTECTED] wrote:
> First I"d like to countinue discussion about usage of stack and heap in VM
Sure.
> First of all, why do we need to store bytecode in SCI heap?
We don't really. SCI0 used to do this, and we emulate its behaviour ATM.
As you've noticed, there is no actual need to do this.
> And classes may be stored not in it too. For example, super and self is
> only an identifiers right?
In theory, yes. However, a few subtleties are related to this:
In SQ3 [for example], when you climb up the ladder from the room where you
find the portable reactor and enter the next room, the 'eye' objects of
the rats in the foreground are destroyed. However, when this happens, the
function that destroys them is in a script which is no longer loaded, but
still referenced (a dangling pointer). SCI0 doesn't notice this, so SQ3
works; however, later SCI implementations checked for these situations (or
so I'm told).
This behaviour can, of course, be emulated by using script IDs which keep
their property values until they are loaded explicitly (i.e. those are not
cleared when the scripts are disposed, and scripts remain callable (in
SCI0) even after that).
> Why they must be pointers in heap. We could store them elsewhere. As I
> understand we can access to local(global) variables only by indexing
> them (I mean that we cannot modify them directly by setting sp to some
> value and then call push()
Yes. There are two ways to modify them (by selector ID and by
object-relative offset), but both can be taken care of without explicit
references.
Note that SCI0 supports 'lofsa'/'lofss' calls to retreive the offset of a
variable; IIRC this was used only for string operations (i.e. on the
stack only), but we should do some more tests with this.
> Then, I've already try to store Doubly-linked lists, nodes not in heap,
> but in my own allocation pool and return it IDs in this pool instead of
> heap_ptr - All works fine (I test this on several screens from SQ3 LSL3)
This makes a whole lot of sense and is one of the things that should
definitely go into a new VM.
> Then about HQ2 again
> I fear that in SCI01 games sound subsitem slightly different then in SCI0
That's true. Not just on the script level, though; the sound resources
themselves changed dramatically (#include <jarring_chord.au>).
> For example, It is assumed that second parameter for DoSound function
> if passed, is a pointer to SoundObject
> But function 0 from script 2 do something like this:(I don't remember which values
>does it exactly pass):
> ldi 0x2a3
> sag 907
> ldi 3
> sag 12
> pushi 2
> pushi 0xf
> pish0
> push0
> push0
> callk DoSound 4
> If I don't miss something i.e. DoSound was called with parametrs (0,
> 0x0f) which means init sound object with pointer 0f!!!
Actually, this would call DoSound() without any parameters, as far as I
can tell. If you left out two of the push0s for the following:
> pushi 2
> pushi 0xf
> push0
> callk DoSound 4
it would invoke DoSound(0xf, 0), which is an unknown sound function
(unknown to me, at least- we don't support it ATM at any rate).
> Absurd! But why do we need to chage some global variables before call to
> DoSound.
Many parts of the SCI state were stored in global variables. This may not
always be very clean design, but, well, it's how those games were written
;-)
> May be if objptr<1000 then it should take information about
> sound object from global variables?
I'm not convinced something like this is happening here, actually.
> BTW, why do you know, that scripts in SCI01 are dynamically loaded?
Are they? I'm not certain about that... is it mentioned in the docs?
The thing about SCI01 is that it separates between the dynamic and
static parts of scripts and only loads the dynamic parts (local
variables, objects, and classes, I'd guess) to the heap, whereas the
others are stored off-heap.
llap,
Christoph
