On Tue, 29 May 2001, Christoph Reichenbach wrote:
> 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.
There is also the lea instruction (followed by a kernel call that modifies
the heap), and the Memory call in SCI01 (used for building a file list in
the character import script in QfG2, generating polygons on the fly in
SCI1, and other such things). Theoretically
(There's even MemorySegment(), but I've only seen that used in LSL5 where
it is used on game startup for an unknown purpose)
> 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.
(oops, didn't see 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)
Cool. If you could send us the patches (and Christoph agrees), this could
go into CVS right away and possibly help QfG2 a bit.
> This makes a whole lot of sense and is one of the things that should
> definitely go into a new VM.
Yes.
> 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).
The first DoSound() command executed by QfG2.
It's DoSound(0, 0xf) - it sets the master volume. Remember, you heard it
here first :)
>
> > 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
> ;-)
This write doesn't actually affect the kernel call, but is used for
soimething else.
>
> > 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.
It doesn't.
> > 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.
Dynamically loaded? Scripts /are/ dynamically loaded, even in SCI0, just
like every other resource (just not by the current FreeSCI
implementation). That is, if I understood you correctly.
>
> llap,
> Christoph
Lars
