Just as a spectator - sounds to me like you're mixing several projects
that could be orthogonal.

- In-image VM (which I'm assuming could just as easily have current
Squeak semantics)
- Distributed Squeak
- Yet Another Go At namespaces (YAGA ;-)

All are fascinating, and each of them somewhat risky. Mixing them
multiplies the risks...

Does doing them at once make it all so much simpler that it's worth it?

Daniel

Anthony Hannan <ajh18 at cornell.edu> wrote:
> The plan is to implement the following modules (and related ones not
> yet realized).  If anyone wants to help, please let me know.  Also, if
> anyone has any feedback, please respond.  All modules except the Boot
> modules shall be implemented in Smalltalk.  After we have a working
> Squid kernel then we can port Squeak code to it.
> 
> Cheers,
> Anthony
> 
> Boot
> 
> Parses the command line, loads the named squid file, and executes its
> boot method with the rest of the command line string as it argument.
> 
> Method Execution
> 
> Method bytecodes are translated to machine code, if not already, and
> then executed.  Each method maintains a pointer to its machine code. 
> Translated code still manipulates its own Smalltalk object stacks. 
> Bytecodes are low-level like machine code.
> 
> Translator
> 
> The translator translates bytecodes to machine code using a
> platform-specific machine code generator (conversion table).  The
> translator and generator is written in Smalltalk.
> 
> Segments
> 
> Each squid file contains a segment of objects.  Objects can point to
> objects in other segments, using cross pointers.  Following a cross
> pointer causes the target segment to be loaded, if not already.  Files
> are kept in sync with with their loaded segments (mmap) maintaining
> persistence without explicit saving.  Cross pointers may cross machine
> boundaries.
> 
> Remote Pointers
> 
> Cross pointers across machines must be established and maintain and
> robust against failure.  When accessing a remote field or invoking a
> remote method execution can move to the remote machine or the
> object can move or be replicated to the local machine.
> 
> Garbage Collection
> 
> Garbage collection is performed on each segment individually.  It is
> written in Smalltalk and runs in its own segment, thus allowing the
> algorithm to utilize full Smalltalk power, ie. object creation.
> 
> C Interface
> 
> There is no VM.  The native OS and machine are accessed via C library
> functions called directly from Smalltalk.  C calls transfer args from
> the Smalltalk stack to the C stack and vice versa.
> 
> Modules
> 
> A Smalltalk module defines a set of selector methods, classes, and class
> methods, and imports a set of other modules whose public methods and
> classes are accessible.  A selector method is a method that stands alone
> and is called directly.  A class method overrides a selector method and
> cannot be called directly.  A selector method may delegate to the
> receiver's class if desired.  Only class method can access fields of the
> receiver.  Delegation looks up the class method in the sender's module
> (including visible imports) and the class's module.
> 
> Compiler
> 
> Translate Smalltalk source into Squid bytecodes.  The closure compiler
> is a start for this.
> 
> Dynamic Optimizer
> 
> Add profilers and inline heavily used code.  The inlined code is
> bytecode which is then translated to machine code.