Hi, I have some question about VM.
i the InterpreterSimulator is still maintain ? Because i am interest about this stuff. Who maintain this stuff ?
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 ?
regards
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.
Dave
thank
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:
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.
ok thank a lot
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.
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
thank
- 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.
regards JB
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:
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 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.
Dave
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.
Cheers, - Andreas
On Tue, Dec 01, 2009 at 08:44:43AM -0800, Andreas Raab wrote:
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.
Thanks for this explanation. I updated the class comment for MiscPrimitivePlugin as follows:
This plugin pulls together a number of translatable methods with no particularly meaningful home. See class>translatedPrimitives for the list.
The primitives in this plugin consist of various methods in the image that can benefit greatly from translation to C, but that do not inherently require translation. These may be thought of not as traditional primitives, but as methods that have been annotated for translation to C by this plugin. This approach allows performance critical methods to be written entirely in Smalltalk, then marked for translation as needed to achieve improved performance.
Dave
vm-dev@lists.squeakfoundation.org
-
Andreas Raab -
arnaud Jean Baptiste -
David T. Lewis