[freesci-develop] State of Glutton #3

[Christoph Reichenbach]

Hi,

a quick status update for those who missed the last one, and some details
for those involved in development:

Glutton seems to be coming along nicely. The VM now supports the entire SCI
instruction set (not tested in its entirety, though) and on-demand script
instantiation, a total of 64k segments (each script occupies one or two
segments, one for its local variables (optional) and one for the rest);
a couple of debug features (breakpoints in particular) are disabled, though.
  The new VM does more internal checks than the last one did; for performance,
these can be disabled by compiling with -DDISABLE_VALIDATIONS (untested).

21 kernel functions have been ported to the new infrastructure; of the
remaining (~90), most are emulated using src/engine/kemu_old.c. The
ported kernel functions encompass list management and some internal
functions (some of which still need more testing). Missing kernel
functionality is as follows:
 - Clone
 - DisposeClone
 - Hunk allocation/deallocation
 - Animate
 - DoBresen
 - CanBeHere
 - BaseSetter
 - SetNowSeen
(of which the last two should be trivial to fix; Animate() will probably
be the biggest chunk of work here).
  kernel.c has also been revised somewhat, both to handle emulation, but
also to allow run-time typechecking for kernel functions. Thus, kernel
functions can now rely on their arguments only being of specific types
(arithmetic, objects, list nodes etc.).

The debugger has been cleaned up internally; built-in help is divided
into three sections: commands, variables, and docs (1, 2, 3). New
debugger commands include:
 - shownode (new node inspection)
 - vo (object viewer)
 - codebug (codebugging: Runs a parallel FreeSCI process, prints its
   output in ANSI red -> codebugging.3)
 - segtable (segment table lister)
 - seginfo (segment info)
Calls able to use addresses (vo, shownode) can now look up those using
an extended syntax (-> addresses.3) which allows, among other things,
to look up objects by name.

The most relevant new concept in glutton is the segment manager, which
handles (as indicated above) up to 65535 "segments", where segments are
typed address spaces with a mostly uniform type (i.e. there are dedicated
list segments, node segments, clone segments, a stack segment etc.); the
one segment that violates this rule is the script segment, which contains
both raw script data (bytecode, data, said specs etc.) and objects.
  Segment 0 is explicitly reserved for arithmetic values, thus, the segment
manager doesn't really do a lot for it.

Also, in both the glutton and the main branch, song iterators have
received bugfixes; they're more likely to work now.


Right now, Glutton runs over 1300 instructions in sq3 until it blows up;
the reason for this is somewhere in between Clone/DisposeClone missing and
the emulation potentially having a bug or two. The final project presentation
at CU will be on December 10th; an official release of this unstable branch
is likely to happen soon after that.
  The 0.3 stable branch will be continued independantly of that, although
it's likely that we'll converge on 0.4 (bug-fixing only) somewhat sooner now,
in order to minimize fork friction.


llap,
 Christoph