Why Interpreter isa ObjectMemory

PhiHo Hoang phiho.hoang at rogers.com
Sun Feb 24 21:53:15 UTC 2002


Tim,

	Your response together with Anthony's seems to indicate that
it's not wrong to have ByteCodeInterpreter and ObjectMemory as separate
objects. It's only a matter of design and implementation and speed wise
performance (4GHz CPU will be in the entry level PC when my nano VM is
done ;-)

	I am now sleeping on the drawing board for my nano VM designed
and built around a 'MetaObjectMemory' to be seeded with 3 MetaObjects
'ObjectMemory', 'Compiler' and 'ByteCodeInterpreter'. Wish me luck ;-)

	Cheers,

	PhiHo.


-----Original Message-----
From: squeak-dev-admin at lists.squeakfoundation.org
[mailto:squeak-dev-admin at lists.squeakfoundation.org] On Behalf Of Tim
Rowledge
Sent: Saturday, February 23, 2002 10:17 PM
To: squeak-dev at lists.squeakfoundation.org
Subject: Re: Why Interpreter isa ObjectMemory


"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.





More information about the Squeak-dev mailing list