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
> [email protected]
> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
--
=
=
=
========================================================================
John M. McIntosh <[email protected]>
Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com
=
=
=
========================================================================
_______________________________________________
Pharo-project mailing list
[email protected]
http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
