"PhiHo Hoang" <phiho.hoang at rogers.com> is claimed by the authorities to have written:

> 	I read through the missing chapters of the Blue Book but miss
> the point why Interpreter is a subclass of ObjectMemory.
[snip]
> 	You may ask why I ask. The reason is that I am toying with the
> thought of splitting the ObjectMemory and ByteCodeInterpreter and wonder
> what the price that must be paid for this. 
> 
> 	Is Interpreter a subclass of ObjectMemory in the original design
> as described in the Blue Book or is it an innovation in Squeak (where
> can I get the original source) ?
This is an implementation simplification for Squeak; it makes it
simpler to generate the single interp.c file. It also avoids
cross-module call costs which on some OS/cpu combinations can be
stupidly high. However, with some work it really should be possible to
narrow the interpreter/object memory interface to a sensible api. 

The main advantage I have long been interested in is the possibility of
different execution and object memory systems being mixed and matched.
At the very least it would make sense to have the bytecode interpreter
and the jitter as alternative execution modules instead of the J3 fudge
of simply taking over. It might be useful to have a somewhat different
object memory to support multi-cpu images.

A first step of moving Interpreter to be a subclass of Object followed
by fixing up all the places where 'self fooble' needs to become 'objmem
fooble' or 'executor fooble' ought to tell you a good deal about how
difficult it will be.

tim

-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Useful random insult:- Gets parity errors under load.