Hi,
On Wed, 27 Sep 2000, Lars Skovlund wrote:
[string constants]
> > 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?
Not if we trap for that appropriately. If StrCmp knows that address
0xff21 refers to the second string in the third string segment rather
than heap address 0xff21, then this is not a problem. The only problem
here occurs when the SCI code wants to address the string minus its first
character, and tries increasing the address by one to achieve that. That's
where the 32 bit idea (or sizeof(int) anyway) comes in...
> > 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.
Why? If we do this right, they won't know the difference.
Think of the SCI interpreter as a set of sorts (variable types),
functions (both kernel and bytecode), and axioms. Since the interpreter
itself is finite, all three of them are finite, including the axioms.
We provided an interpreter that provides (almost) all of the functions and
violates only a small subset of these axioms (those are the bugs). Now,
all we have to do is rewrite some of our internals while not violating the
axioms.
SCI code doesn't care whether 'add' uses arithmetics to calculate the
results, or looks them up in a lookup table; so why should lea or lofsa,
or any of the kernel functions?
(Sorry if I'm getting to algebraic here. Pre-diploma exam is on friday,
please bear with me until then...)
> > 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.
I'd rather prefer an alternative, right.
> > (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... :-)
Great :-)
(Note that the parser implementation needs an overhaul, too, as it's damn
slow).
Anyway, SCI01 pic support and kernel functions would benefit the system as
a whole, even if we changed the vm (I was thinking of that as a way to
simply work towards SCI01 a bit).
[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).
Yes, we'd have to translate scripts into our own representation (note that
we'd be able to release the memory allocated for that specific script
resource afterwards- we need to do something about memory consumption
eventually...). However, this isn't really a problem. Actually, I think
it's more natural- SCI code typically wants to change its local variable
#7. Right now, this means PUT_HEAP(xs->variables[VAR_LOCAL] + 7*2, value).
The action performed by this macro is (after a series of checks) to alter
two bytes in out big heap (ok, so 64k isn't really big). However, the SCI
code doesn't want to change two bytes, it wants to set its local variable.
So we might as well do something like xs->variables[VAR_LOCAL][7] = value
(ok, this would probably be hidden in an inline function or macro anyway,
to allow for some sanity checks), which also happens to be a lot more
readable to random code reviewers.
> 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.
C++ is no more powerful than C is. There are a lot of funky ways to prove
this in theoretical CS and Algebra. But, rather than letting my fantasy
run wild, I'd like to point you to GTK, which is object-oriented /and/
written in C. While you're looking at it, I'll finish our widget code,
which should be object-oriented too eventually (the new graphics code uses
several OO ideas).
llap,
Christoph
