Christoph Reichenbach wrote:
> Hi Lars,
[SCI(0)1 memory management]
>
> 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).
I think he's talking about ARM, an internal driver-based memory manager. Supports
all of the memory types we had in the bad old days of DOS - even video RAM in some
versions.
> > > 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.
Strings are usually adressed by lea (for temporary strings) or lofsa (for string
tables). String _editing_ on the other hand is done with the Str* kernel functions.
However, isn't swapping string segments out based on execution of specific bytecodes
a bit dangerous?
>
>
> > > 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.
Some games will probably moan about this.
>
>
> 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
... :-)
But... you're right. Keeping two memory systems around for the same interpreter
would probably be ugly.
> 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
I don't know how much good that would do. The only SCI(0)1 game that plays rather
well at the moment is KQ1. Now that the parser has been updated, I can at least
score a few points... :-)
> > [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.
It would require extensive fiddling with the script files in memory (extending
localvar areas etc.), but the idea in itself is good, and also how SCI32 does things
(if we ever get there). However, SCI32 internals are in OOP, and FreeSCI is not. I
don't know if it is possible to make an SCI32 implementation in pure C.
> llap,
> Christoph
Lars
