On April 11, 1998 Jecel Mattos de Assumpcao Jr wrote:


> My idea for a more modular primitive system is that we should pick
> a more object-oriented style and have primitive *objects* instead
> of primitive *methods*. These objects would be well known (I
> have made their names globals in this example) and would be
> invoked using the standard send bytecodes, like this:
> 
>          ArithmeticUnit add: 12 with: 21
> 
> Here are some of the primitive objects that will be needed:
> 
>    ArithmeticUnit - we met already 
>    LogicUnit - shifts and general bitwise stuff 
>    FloatingPointUnit - for obvious things 
>    Memory - used by basicNew and friends 
>    BitBlitter - in some cases implemented in hardware 
>    Os - files and things 
>    Mac - unique Mac things 
>    Win32 - the little shop of horrors 
I like this. In this way one defines the virtual computer/machine. Almost
all hardware processors have an arithmetic unit, a logic unit and sometimes
a floating point unit. Memory comes in many flavors: registers, cache,
primary and secondary (hard disks and so). The BitBlitter would then refer
to the video card. OS is a bit tricky because Squeak is an OS in itself and
files are a kind of memory.
> 
> In itself, this idea is pretty stupid. 
No, it isn't. Its clean.

> But if the image were modularized
> so that objects could be linked in on the fly and we had the ability to
> store native machine code inside these image "parcels" (which would come
> in handy if there were a Squeak native compiler) then primitive objects
> could be loaded dynamically very easily.
I imagine that it should be possible for the Smalltalk part to ask the
native part for the machine codes for a number of well defined primitives.
In this way you could put the native code in place of the bytecodes. Now,
the interpreter jumps into the primitive each time you reference an
instance variable. But what if the compiler would put the native machine
code in the method for accessing the instance variable!

Reinier.