InterpreterSimulator and Primitive Code convention

>
> On Mon, Nov 30, 2009 at 01:28:29PM +0100, arnaud Jean Baptiste wrote:
>>
>> Hi,
>> I have some question about VM.
>>
>> i the InterpreterSimulator is still maintain ? Because i am interest about this stuff. Who maintain this stuff ?
>
> The InterpreterSimulator is maintained as part of the VMMaker package on
> SqueakSource. It does not receive much attention, but the intent is to
> keep it working. Bugs and fixes reported on Mantis are appreciated.
>
> If you search through the archives of squeak-dev and vm-dev, you will
> find discussions of how to use it and what images it seems to work with.
> If you have specific questions, there are a number of folks on this list
> (or on squeak-dev) who can help.

>
>> Then,
>> 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.
>

>
> 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 ?

>
> 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
>

> 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.

>
> David T. Lewis wrote:
> >I do not know why it was done that way.
>
> I do. The idea was to add type annotations to a snippet of code that
> could be helped a lot by translating them to C but doesn't inherently
> require it. For example John Maloney "prototyped" the sound prims, then
> threw in the required type annotations so we could translate them to C
> and speed them up by few orders of magnitude.
>
> It does make sense if you think about the issue in the way that this is
> code with type annotations to make them translatable instead of thinking
> about them as primitives that can also be run directly.