[Vm-dev] Eliminating cCode:inSmalltalk:'s

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 30 14:34:46 UTC 2018

Hi Ben,

> On Oct 30, 2018, at 6:26 AM, Ben Coman <btc at openinworld.com> wrote:
>> On Tue, 30 Oct 2018 at 20:22, Eliot Miranda <eliot.miranda at gmail.com> wrote:
>> Hi Ben,
>>> On Oct 30, 2018, at 4:57 AM, Ben Coman <btc at openinworld.com> wrote:
>>> I'm sure this was explained somewhere before (even recently), 
>>> but I forget, and can't find anything in my usual search places.
>>>> On Tue, 30 Oct 2018 at 09:02, <commits at source.squeak.org> wrote:
>>>> Eliot Miranda uploaded a new version of VMMaker to project VM Maker:
>>>> http://source.squeak.org/VMMaker/VMMaker.oscog-eem.2479.mcz
>>>> ==================== Summary ====================
>>>> Name: VMMaker.oscog-eem.2479
>>>> Author: eem
>>>> Time: 29 October 2018, 6:00:57.748695 pm
>>>> UUID: b191888c-6777-483b-82b4-121103743ebf
>>>> Ancestors: VMMaker.oscog-eem.2478
>>>> Plugins:
>>>> Fix slip in primitiveDirectoryDelimitor.
>>>> Eliminate cCode:inSmalltalk:'s from the B3DAcceleratorPlugin
>>>> =============== Diff against VMMaker.oscog-eem.2478 ===============
>>>> <snip>
>>>> Item was changed:
>>>>   ----- Method: B3DAcceleratorPlugin>>primitiveAllocateTexture (in category 'primitives-textures') -----
>>>>   primitiveAllocateTexture
>>>>         | h w d result renderer |
>>>>         <export: true>
>>>>         interpreterProxy methodArgumentCount = 4
>>>>                 ifFalse:[^interpreterProxy primitiveFail].
>>>>         h := interpreterProxy stackIntegerValue: 0.
>>>>         w := interpreterProxy stackIntegerValue: 1.
>>>>         d := interpreterProxy stackIntegerValue: 2.
>>>>         renderer := interpreterProxy stackIntegerValue: 3.
>>>>         interpreterProxy failed ifTrue:[^nil].
>>>> +       result := self b3dxAllocateTexture: renderer _: w _: h _: d.
>>>> -       result := self cCode:'b3dxAllocateTexture(renderer, w, h, d)' inSmalltalk:[-1].
>>>>         result = -1 ifTrue:[^interpreterProxy primitiveFail].
>>>>         interpreterProxy pop: 5. "args+rcvr"
>>>>         ^interpreterProxy pushInteger: result.!
>>> What is the mechanism that allows cCode:inSmalltalk:'s to be replaced like above?
>>> I half expected  "b3dxAllocateTexture:_:_:_:"
>>> to be newly defined somewhere else in that commit.
>> Those implementations can come later.  Right now the plugin doesn’t simulate anyway.  You’re right I could have written them then and there, but I would rather do real o es than simple failing stubs.  If I find that I can’t simulate without stubs I’ll add them.  Feel free to provide them if you’re motivated.  I should have just fixed the digitCompare: issue but got carried away...
> I'm still missing something basic, but guessing... the "inSmalltalk:" part is what is performed by the simulator?

I’m sorry; yes.  Given
    self cCode: stringOrBlock inSmalltalk: block
the C translator will either emit stringOrBlock verbatim if stringOrBlock is a string, or emit the translation of stringOrBlock’s statements if it is a block.  The simulator simply evaluates block.  And the value of the expression is, effectively, the value of either block.

> and the "cCode:" is generated into a C-code-call that expects that function linked in from a library?

More accurately stringOrBlock is arbitrary code.  Look for uses in BirBltSimulation and you’ll see the code for invoking the fast bitblt code for the Raspberry Pi.  This assigns parameters for a bitblt invocation to a struct.  One can define a struct in Smalltalk (VMStructType ? an approach I take for Cog method headers, stack pages, spur memory segments, etc) but Tim took the short cut of merely writing the verbatim C.

One stereotypical use was to write the invocation of some platform support function and have the inSmalltalk: either simulate or answer a default value, and sometimes to reference variables used in the call but unused elsewhere, to avoid Smalltalk compiler earnings.  This is what we see here in the B3DAcceleratorPlugin.  But using a default value precludes simulation, and the code is ugly.  So I’ve started replacing as many cCode:inSmalltalk:’s with a message send where stringOrBlock is simply a call.  This is dependent on _: keyword support and the <doNotGenerate> pragma to instruct Slang not to generate the simulator implementation.  I added <doNotGenerate> several years ago; I added _: support a few weeks ago.

> and now there is no simulation and "b3dxAllocateTexture:_:_:_:" is generated to C-code-call?

That would generate a call of b3dxAllocateTexture with the given arguments.

> So is there a mechanism that any unknown message (i.e. "b3dxAllocateTexture:_:_:_:") is generated to a C-code-call?

Yes.  Look for VMMaker.oscog-eem.2440 and VMMaker.oscog-eem.2452.  And in general one can use 
    self foo: expr bar: rpxe 
to generate a call of foobar.  I simply added stripping out of _:, which means not having to split a call across several keywords; much more readable.

> cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181030/fe82d689/attachment-0001.html>

More information about the Vm-dev mailing list