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

[Alistair Grant]

Hi Ben,

Disclaimer: I haven't gone through the code, but this is my understanding.




On Tue., 30 Oct. 2018, 14:26 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:
>>
>>
>>
>> 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?
>

Not quite.  There is a table of special messages, e.g ifTrue:ifFalse: is
converted to the normal C if else statement.

Every other message send is converted to a function call.  The function is
either internal, i.e. Supplied by another method, or external (which the
linker should find).


Cheers,
Alistair
(on phone)

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