[Vm-dev] InterpreterSimulator and Primitive Code convention

David T. Lewis lewis at mail.msen.com
Tue Dec 1 16:35:28 UTC 2009

On Tue, Dec 01, 2009 at 05:06:10PM +0100, arnaud Jean Baptiste wrote:
> On Dec 1, 2009, at 4:15 PM, David T. Lewis wrote:
> > On Tue, Dec 01, 2009 at 10:01:22AM +0100, arnaud Jean Baptiste wrote:
> >> 
> >> Ok that was i think, but i take the example of #decompress: fromByteArray: at:  From Bitmap
> >> this method can be call to execute the primitive method primitiveDecompressFromByteArray
> >> And the smalltalk source code is inlined by the MiscPrimitivesPlugins. 
> >> Then may be we must give all the translated methods by MiscPrimitivePlugins and put in it.
> >> Then write a fallback code on all this method ?
> > 
> > This method is a special case. It is designed to be translated to C as
> > a primitive, and it is *also* used as a normal Smalltalk method that
> > first tries to call its own primitive in the VM but runs "normally" if
> > the primitive fails. It was written carefully so that it will work in
> > both ways.
> > 
> > I should mention that it is important to be careful when changing methods
> > like this, otherwise you may cause dependencies between versions of the
> > image and the VM.
> - why this choice ? it's seems it's harder to maintain that.
> 	- it's for used with the interpreterSimulator ?  
> - isn't more simple to have all of the translate method include into the plugin which inlined it ?
> 	Then we must have a clean fallback code, and centralize.
> 	the understanding of each plugin.

I do not know why it was done that way. But I can see the advantage of
using the same source code for the both the primitive and the run time
Smalltalk, since it eliminates the need to maintain two separate versions
of the same code.


More information about the Vm-dev mailing list