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

Eliot Miranda eliot.miranda at gmail.com
Tue Oct 30 22:13:14 UTC 2018

Hi Alistair,

On Tue, Oct 30, 2018 at 7:48 AM Alistair Grant <akgrant0710 at gmail.com>

> 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).

Very close!  This is TSendNode>>emitCCodeOn: aStream level: level
generator: aCodeGen
"Emit the receiver as a statement."

"If the selector is a built-in construct, translate it and return"
(aCodeGen emitBuiltinConstructFor: self on: aStream level: level) ifFalse:
["If it is a pointer dereference generate it"
(self emitCCodeAsFieldReferenceOn: aStream level: level generator:
aCodeGen) ifFalse:
["Otherwise generate the vanilla C function call."
self emitCCodeAsFunctionCallOn: aStream level: level generator: aCodeGen]]

The built-in constructs are many, but the ones that aren't arithmetic or a
function call, or control (ifTrue: => if () { ...) are
1. cCode: stringOrBlock [inSmalltalk: ] => emit stringOrBlock
2. cPreprocessorDirective: => emit whatever the argument is literally (very
similar to 1. but not indented)
3. cppIf:ifTrue:ifFalse: => #if EXPR ... #else ... #endif
4. addressOf: expr [put: block] => &expr
5. touch => nothing (allows referencing variables for 1.)
6. some unusual translations for shouldNotImplement, asInteger et al (see

Then field references are inst var accessors of instances of subclasses of
VMStructType, which get translated into
    foo.bar = expr
    foo->bar = expr
depending on the type of foo.

Only after this do sends get mapped to function calls.

> Cheers,
> Alistair
> (on phone)

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

More information about the Vm-dev mailing list