[Vm-dev] Eliminating cCode:inSmalltalk:'s
Ben Coman
btc at openinworld.com
Tue Oct 30 13:26:15 UTC 2018
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?
and the "cCode:" is generated into a C-code-call that expects that function
linked in from a library?
and now there is no simulation and "b3dxAllocateTexture:_:_:_:" is
generated to C-code-call?
So is there a mechanism that any unknown message (i.e.
"b3dxAllocateTexture:_:_:_:") is generated to a C-code-call?
cheers -ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20181030/343b0d92/attachment.html>
More information about the Vm-dev
mailing list