Hi Lars,
On Tue, 26 Sep 2000, Lars Skovlund wrote:
> > > I haven't seen the embedded cel command in actual use. OTOH, KQ1/SCI breaks
> > > because the current FreeSCI does not handle Set Priority Table yet.
> > That's the same reason QfG2 usually breaks, and it should be relatively
> ??? Mine dies when I get to the character attributes screen (a failing
> call to Clone()).
Sorry, I was referring to pic drawing here, not the interpreter.
[VM/Heap stuff]
> > I guess those were the changes Corey Cole was talking about when he
> > referred to the memory problem in QfG2 being solved 'on both sides'...
> That's probably it, though I can't see the meaning of "on both sides" -
> I haven't seen your correspondence with him.
Well, the heap/non-heap separation for scripts on the interpreter side,
and changes to use static objects rather than object instances in some
cases (thereby removing the lowest superclass). He was also referring to
an 'overlay system' (this might mean that they're loading/unloading
scripts more often, but I'm not sure about that).
> > > So no, we don't have as
> > > much free heap as Sierra SCI. Later on, SCI1.1 performed this split at
> > > compile time (creating two files, *.SCR and *.HEP).
> > You're right, this will need some work in the Interpreter to be done
> > correctly. OTOH, it might make things somewhat cleaner...
> > So, what has to remain in the heap?
>
> Closer scrutiny will have to take place to be certain, but the *.HEP
> and *.SCR files of SCI1.1 may be a good indicator. I recall that the
> script objects were lobotomized, such that selector numbers and
> selector values were stored in separate places (hunk and heap,
> respectively). OTOH, the class/object headers (which were a separate
> structure in SCI0) now consists of selectors with well-defined numbers
> in a well-defined order (with numbers starting at 0x1000).
Good.
> > What about string constants? IIRC, that's where lofsa/lofss come into play
> > (local calls have relative addresses). Do you happen to know if we have to
> > map all string segments into the heap all of the time?
> Since they are part of *.HEP files in SCI1.1, and the script code may
> unpredictably address them, I would say yes.
I haven't seen them doing random access to strings, but we should account
for that possibility.
> > Anything else that used to be on the heap (lists, nodes) can be removed
> > from there as well.
> I am not sure that we should randomly move things out of the heap. In
> any case, the scripts are the major consumer of heap space here, and we
> should at least begin with that.
The point is that we currently assume that all script parts are on the
heap, which means that "simple" optimizations are limited to removing
relocation pointer tables. Anything more complex than that will require
non-trivial changes to the script loader and to the vm (kernel functions
should be unaffected). So, while we're at it, we should at least consider
getting rid of the heap entirely.
IMHO, the advantages of this approach are:
- cleanness- no more GET_HEAP(address), but, rather, in-memory
representation of scripts, script variables, objects/classes etc.
- speed- Big-Endian processors scream and cry whenever they have to use
PUT_HEAP(), for example (note that this can be fixed without re-modelling
the vm)
- scalability- This stuff is much more likely to actually work with SCI32
eventually
Disadvantages:
- Greater time investment- some kernel functions will need re-writes, e.g.
Clone() will have to malloc() objects, they would need to be tracked in a
global list to avoid memory leaks (as would lists), and many debug
functions would break
- Risk of introducing new bugs (we might do semi-automatic checking for
some of them by running the new vm side-by-side with the old one and
comparing results of specific operations, though)
Anyway, this is a post-0.4.x issue. It would have been nice to have SCI01
support for 0.5.0 (FreeSCI 1/2 ?) but we can't do that without breaking
the vm. I think we should focus on the following right now:
- Fix graphics (...)
- Add sound support
- Test for and remove bugs (there still are a few known ones, like the
barber's chair in LSL2, that need to be investigated)
(Partial) SCI01 support can be implemented anyway (kernel functions, pic
resources), we'd just have to postpone the vm. Personally, I'd suggest
we start working on it when we reach 0.4.x, as the 0.6.x development
branch (0.4.x is for fixes /only/. I don't really expect a lot of 0.4.x
releases, though...).
We should do some sort of regression testing during 0.6.x, though.
> [snip discussion of virtual memory etc.]
I still like the idea- using 32 bits, we could tag all selectors for the
data type they reference to, thereby easily distinguishing between
pointers to lists, pointers to objects, window handles, and pointers.
llap,
Christoph
