[Vm-dev] InterpreterSimulator and Primitive Code convention

David T. Lewis lewis at mail.msen.com
Tue Dec 1 15:15:49 UTC 2009


On Tue, Dec 01, 2009 at 10:01:22AM +0100, arnaud Jean Baptiste wrote:
> 
> On Nov 30, 2009, at 10:41 PM, David T. Lewis wrote:
> > 
> > On Mon, Nov 30, 2009 at 01:28:29PM +0100, arnaud Jean Baptiste wrote:
> >> 
> >> Some primitive have smalltalk code and this code is call only if the primitive fail.
> >> But i have see some primitive code is using to be inline when generate the Virtual Machine via VMMaker. 
> >> Then what is the true convention about the primitive code ?
> > 
> > I am not sure that I understand your question. There are methods that
> > call primitives, and have fallback code that is executed if the primitive
> > fails. These methods are not part of the primitive, they are just ordinary
> > methods that happen to call primitives.
> > 
> > Methods that are inlined, and that are used to generate the VM via
> > VMMaker, are a different thing. They are Smalltalk methods that are
> > designed to be translated into C to form the actual primitives in
> > the VM. The inlining is just a part of the translation process.
> > 
> 
> 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.

Dave
 


More information about the Vm-dev mailing list