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

[Eliot Miranda]

Hi Alistair,

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

> 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
CCodeGenerator>>#initializeCTranslationDictionary)

Then field references are inst var accessors of instances of subclasses of
VMStructType, which get translated into
    foo.bar
    foo.bar = expr
    foo->bar
    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>