[Pharo-project] About inline: and var: varSymbol declareC: declString
Hi I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct? Stef
Adding 'Beeper beep' in the body of these two empty methods does not produce any sound. This is normal since methods that use these methods are primitive. Now, we could remove these two methods from Object, but it would be wise to leave the calls in the body of primitive methods. Could be a good example for aspects by the way. Alexandre On 23 Dec 2008, at 19:20, Stéphane Ducasse wrote:
Hi
I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
I will wait that somebody with VM building knowledge reply. I imagine that these two methods are handy when you want to debug a primitive in Squeak before generating C code. Stef On Dec 24, 2008, at 2:10 PM, Alexandre Bergel wrote:
Adding 'Beeper beep' in the body of these two empty methods does not produce any sound. This is normal since methods that use these methods are primitive. Now, we could remove these two methods from Object, but it would be wise to leave the calls in the body of primitive methods.
Could be a good example for aspects by the way.
Alexandre
On 23 Dec 2008, at 19:20, Stéphane Ducasse wrote:
Hi
I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
I imagine that these two methods are handy when you want to debug a primitive in Squeak before generating C code.
Not really actually. These methods are used by the translator to put the proper cast (else everything appear as 'int' and the C compiler emits warning when you do operation not suitable for int), and to inline methods (for performance reason). I am not expert in compilation, but I would expect a good C compiler to infer whether a method may be inlined or not. Is this inline: directive still necessary? Ideally, these should be set as pragmas I guess. Alexandre
Stef On Dec 24, 2008, at 2:10 PM, Alexandre Bergel wrote:
Adding 'Beeper beep' in the body of these two empty methods does not produce any sound. This is normal since methods that use these methods are primitive. Now, we could remove these two methods from Object, but it would be wise to leave the calls in the body of primitive methods.
Could be a good example for aspects by the way.
Alexandre
On 23 Dec 2008, at 19:20, Stéphane Ducasse wrote:
Hi
I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
Ok, well the ugly part of this is that we have some Slang in the base pharo, either as Slang code or doubling as primitive failure recovery code . Normally if we had say: primAddActiveEdgeTableEntryFrom: edgeEntry "Add edge entry to the AET." <primitive: 'primitiveAddActiveEdgeEntry' module: 'B2DPlugin'> (self canProceedAfter: self primGetFailureReason) ifTrue:[ ^self primAddActiveEdgeTableEntryFrom: edgeEntry ]. ^self primitiveFailed It would invoke the primitive 'primitiveAddActiveEdgeEntry' in the named plugin 'B2DPlugin' which is located either as a plugin, or compiled into the VM. If the primitive call fails or the primitive fails the call it would then execute the smalltalk failure code. In the case above it would execute the canProceedAfter: and either do the primAddActiveEdgeTableEntryFrom: or the primitiveFailed which would cause the walkback. So looking at var: varSymbol declareC: an example would be ByteString>>indexOfAscii: anInteger inString: aString startingAt: start | stringSize | <primitive: 'primitiveIndexOfAsciiInString' module: 'MiscPrimitivePlugin'> self var: #aCharacter declareC: 'int anInteger'. self var: #aString declareC: 'unsigned char *aString'. stringSize := aString size. start to: stringSize do: [:pos | (aString at: pos) asciiValue = anInteger ifTrue: [^ pos]]. ^ 0 This and others are in the MiscPrimitivePlugin, BUT BUT it's possible that aString isn't a byte or word array object, but understands size, and at: so the the C code will fail, but the Smalltalk code will run. Being clever here we are using the the method to contain both the smalltalk code and the Slang code because it's the same. So you can't remove the smalltalk code because it likely has a purpose in special cases. {"MiscPrimitivePlugin", "primitiveIndexOfAsciiInString", (void*)primitiveIndexOfAsciiInString}, {"MiscPrimitivePlugin", "primitiveCompareString", (void*)primitiveCompareString}, {"MiscPrimitivePlugin", "primitiveStringHash", (void*)primitiveStringHash}, {"MiscPrimitivePlugin", "primitiveConvert8BitSigned", (void*)primitiveConvert8BitSigned}, {"MiscPrimitivePlugin", "primitiveFindFirstInString", (void*)primitiveFindFirstInString}, {"MiscPrimitivePlugin", "primitiveDecompressFromByteArray", (void*)primitiveDecompressFromByteArray}, {"MiscPrimitivePlugin", "primitiveTranslateStringWithTable", (void*)primitiveTranslateStringWithTable}, {"MiscPrimitivePlugin", "primitiveFindSubstring", (void*)primitiveFindSubstring}, {"MiscPrimitivePlugin", "primitiveCompressToByteArray", (void*)primitiveCompressToByteArray}, Also see {"ADPCMCodecPlugin", "primitiveDecodeStereo", (void*)primitiveDecodeStereo}, {"ADPCMCodecPlugin", "primitiveDecodeMono", (void*)primitiveDecodeMono}, {"ADPCMCodecPlugin", "primitiveEncodeStereo", (void*)primitiveEncodeStereo}, {"ADPCMCodecPlugin", "primitiveEncodeMono", (void*)primitiveEncodeMono}, For inline: It's not quite clear if *all* code is in plugins since WarpBlt>>rgbMap: sourcePixel from: nBitsIn to: nBitsOut called via WarpBlt>>mixPix: pix sourceMap: sourceMap destMap: destMap called via WarpBlt>>warpBitsSmoothing: n sourceMap: sourceMap which might be called as a primitive failure case for primitiveWarpBits so you can't remove it. But maybe this is the only special case and you could put inline: in WarpBlt and remove from Object>> The same might apply to var: varSymbol declareC: but would you put that in the using class or retain in Object? Of course if your goal is to simplify Object you might consider moving it. However VMMaker likely would need to consider if it should extend Object. To fully remove var:declareC: & inline: I think you'd would end up with a method in Pharo, and a slightly different method in VMMaker, which isn't a good choice. On 23-Dec-08, at 2:20 PM, Stéphane Ducasse wrote:
Hi
I'm trying to learn something while reading Object methods. I was wondering whether var: varSymbol declareC: declString and inline: should not be put as Object extension in VMMaker instead of been kept in Object. Now I saw that these methods have senders in the image. Does it mean that part of the code of these senders can be executed when we consider that these two methods are doing nothing? This could be used to debug the code before generating C from it. are my hypotheses correct?
Stef
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- = = = ======================================================================== John M. McIntosh <johnmci@smalltalkconsulting.com> Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com = = = ========================================================================
participants (4)
-
Alexandre Bergel -
Alexandre Bergel -
John M McIntosh -
Stéphane Ducasse