Hi,
This mail goes primarily to Xiaojun and Sean, but I thought the list
might be interested, too...
The glutton VM is now pretty close to being useable for a couple of
simple scripts. In order to get it to run in its entirety, the most
important change would be to fix selector lookup.
State:
Selector lookup: Disabled
Execution stack: Implemented
Data stack: Implemented, but outside of segment space
Scripts: script.000 hardwired (s->script_000), no access to other
scripts
VM: Simple functions working, others disabled
Debugger: Basic functionality implemented
Segment manager: Compiles
Right now, game.c and vm.c are hardwired to using script.000; modifying
them to be able to work across different scripts (by looking these up
via s->r_pc.segment) should have slightly less of a priority when com-
pared to selector lookup.
Some of the other things looking like hacks (script_000, s->stack_base
etc.) will be required later anyway, for decent performance, so don't
worry about us having to remove a large number of quick hacks (which
should IIRC be concentrated in game.c, plus one line in vm.c).
For reference: I've introduced two new types:
- stack_ptr_t (= pointer to reg_t)
- selector_t (= int)
There are a few macros and static functions for these, defined in the new
header vm_types.h.
So, here are the next steps:
-- Get the segment manager working in its entirety
Required functionality (some of this has already been done, IIRC):
(1) look up existing script by ID (should also check that the ID is valid,
unless DISABLE_VALIDATIONS is defined).
(2) Implement locking as described in the TODO
-- Get the script instantiation mechanism working again
Must do the following:
(1) Count objects/classes, allocate appropriately large entries for the
corresponding script_t.objects entries, set script_t.objects_nr,
write index number to the script localvar pointer offset within
the byte buffer (remember to write 2 bytes max, you can use
getInt16 and putInt16 for that as an initial solution)
(2) Translate locals within the byte buffer into locals consisting of
a reg_t array (initially, set all segments to 0; then iterate
over the relocation table and set segments to the current segment
for the corresponding locals)
(3) Same for object properties.
Required functionality for script_ts (global functions taking a script_t
as its first argument):
(1) Lookup export entry: Returns reg_t, segment is the script's segment,
offset is the value from the exports table
(2) Whatever turns out to be required for selector lookup
-- Get selector lookup working
(1) fix send_selector() in vm.c using the mechanisms introduced for scripts
(this should call add_exec_stack_entry(); note that there has been
a slight change in the semantics of its arguments in that we no longer
pass the byte offset to read from-- which the disabled code expects--
but, rather, the explicit number of entries to consider, i.e.
for a single call 2+number of arguments (where the first two are the
selector ID followed by the number of arguments).
[Note that this doesn't really need a working variable selector lookup, since
function selector lookup would be sufficient for the first run, but doing
both simultaneously sounds like a reasonable approach].
-- Test whether we can step through the first couple of instructions in
an existing game (start up with -D)
[Probably forgot a couple of things, but I hope this gives you a rough idea.]
After that (and after bug fixing), calle, send etc. should be added (should be
rather straightforward then). Note that the debugger should work sufficiently
for very simple tests-- inspecting the stack should work ('stack'), quitting
('quit') should work, singlestepping ('s'), too. Beyond that, most of the
VM functions are either disabled or will behave in funny ways; if you notice
any of them behaving funnily, please disable them with an appropriate #warning
(you can make that #ifdef __GNUC__ if you don't like #warnings in common
code). We'll need a few small extensions to the console code in order to be
able to add the missing debug functions, but that should be doable; I'd like
to postpone this until pages and scripts are slightly more stable in order
to be able to add a couple of features I've been wanting to have in there for
quite a while.
Regarding the stack: It's allocated dynamically ATM and treated specially;
that's OK for the time being, although we'll have to move it into a page
of its own later so we can reference objects on it [for certain kernel
functions]. Just leave callk commented out and don't worry about all the
warnings genereted by engine/k*.c right now; we'll get to that soon enough
;-)
I definitely won't be at university before 14:00 MST (22:00 UTC); I'll try to
come "as soon as possible", but I'm down in Denver doing stuff and some of
that stuff depends on other people, so I can't really give you any more
concrete time ATM.
Regarding the presentation: Either of you should do that. Note that october
30 is the deadline for the updated project state and slides; while I'd be glad
to do the project state part, someone else will have to do the slides and
presentation. Sean, you volunteered for this; if you'd like to go through with
that, that'd be fine by me, but we should discuss what's on the slides on
tuesday (or tomorrow, if possible), just to make sure we have the same per-
ception of the state of the project.
By the way, final presentations will be expected on dec. 3rd, 5th or
10th. We'll be doing these together, so are there any preferences regarding
these dates on your part? (There are slots free on all of these days; I'd
like to do it on the 10th so we can do "as much as possible", but I can see
us having the VM and a couple of kernel calls done by dec. 3rd, too, so if
that's too close to the finals for your taste, don't worry about that pre-
ference all that much).
-- Christoph
