> 1. ENHANCED SQUEAK >> C COMPILER:
> 	For the benefit of G3/G4 users, the raw output of the squeak >> C
> compiler has been enhanced by adding encapsulating all local variables
> in a struct FOO. so that the compiler may use a base-offset addressing
> which reportedly provides significant speedups on that hardware.
This is incorporated in the latest VMMaker related package, which should
be available for release soon. Mac and RiscOS currently make use of a
global struct which holds most of the vm globals; on RiscOS I further
get benefit from the ability to define a global register variable to
hold the base address of this struct. GCC can apparently do the same,
though I've not had anyone tell me how. 

> 	Since the interpriter object will need to be instantiated for each
> proc, the behavior of encapsulating all instance variables in structs
> will need to be standardized.
That's Interp_e_ter by the way...
I doubt that all vm globals would want to be localized; there are surely
some that need to be shared.


> 	I propose that the interpriter be refactored into a VM system and an
> "EE" system for which each VM may have many EE's.
How do you propose to maintain synchrony between these EEs? As I
understand it java(spit) has some unpleasant issues regarding locks
between threads. Or have they solved that problem by now? For example,
you can't garbage collect with one processor whilst another is running
normal code. At least not without some form of coherency interlock.

> 	Furthermore, in the interpriter, there are many variables that are used
> as indexing constants. It would seem that a better way to deal with
> these is to write these as seperate objects and use the standard
> collection classes...
What? You'll have to explain that a bit better.

> To make them compatable, the behavior of the
> SQUEAK >> C compiler will need to be standardized so that the binary
> footprint, while hidden, remains compatable.
Err, ditto. 
> 	I would be happy to work on these presonally but first I will require a
> totorial on how to use the features of the refactoring browser... 
> 
> -------[We now have a first approximation of a multithreaded VM]-----
Not by a long way as yet.

I think there's several orders of magnitude more work involved than
this.

tim
-- 
Tim Rowledge, tim at sumeru.stanford.edu, http://sumeru.stanford.edu/tim
Every program is either trivial or it contains at least one bug.