[Vm-dev] Re: [Pharo-dev] Parsing Pharo syntax to C/C++

[Eliot Miranda]

Hi All,

On Mon, Sep 15, 2014 at 6:01 AM, Thierry Goubier <thierry.goubier at gmail.com>
wrote:

>
>
> 2014-09-15 14:39 GMT+02:00 Clément Bera <bera.clement at gmail.com>:
>
>> Hello,
>>
>> Note that slang is a subset of smalltalk. The Slang compiler does not
>> allow to compile smalltalk to C. It allows to compile a smalltalk with
>> restricted message sends and classes to C.
>>
>
> Yes, I am aware of that. I remember that from the very beginnings of
> Squeak.
>
> Wasn't Smalltalk/X the one which had a more complete version of that C
> translation? I did an internship in a French company who had a Smalltalk to
> C translator done for them a long time ago.
>
>
>>
>> 2014-09-15 13:28 GMT+02:00 Thierry Goubier <thierry.goubier at gmail.com>:
>>
>>> Hi Phil,
>>>
>>> thanks for the update on Slang to C. Allways significant to have that.
>>>
>>
>>> Two open questions:
>>>
>>> - would a slang to x86 asm via NativeBoost be doable / a nice target?
>>>
>>
>> Yes it would be interesting. However, by having a Slang to C compiler,
>> we're platform-independent, we can compile the C code to x86, x86_64 and
>> ARM quite easily (some part of the VM are already processor dependent, but
>> not so much). Targeting direct machine code implies evolving the Slang
>> compiler for each new assembly code we support. It sounds like a lot of
>> engineering work compared to our resources and the gain.
>>
>
> It would allow JIT-type compilation experiments than a Slang-to-C chain
> isn't designed for :) With a lot more work doing the various NB ports, of
> course.
>
>
>>
>>> - would targetting LLVM-IR be of interest?
>>>
>>> If you compile the C code with Clang instead of gcc, which starts to be
>> the case because of the lack of support for gcc in the latest Mac OS X, you
>> are already using LLVM IR because Clang uses it. As the VM use the GNU C
>> extensions to improve performance, I do not think that targeting directly
>> the LLVM IR would greatly improve performance. So it sounds like quite some
>> engineering work for no gain.
>>
>
> I would not suggest replacing C by LLVM-IR for VM work, in part because
> LLVM-IR is not what I would call a readable source code format... But I do
> know that even when doing C to C rewritting for embedded compilation, there
> is some low-level code that you can't write in C.
>

I find this whole discussion depressing.  It seems people would rather put
their energy in chasing quick fixes or other technologies instead of
contributing to the work that is being done in the existing VM.  People
discuss using LLVM as if the code generation capabilities inside Cog were
somehow poor or have no chance of competing.  Spur is around twice as fast
as the current memory manager, has much better support for the FFI.
 Clément and I, now with help from Ronie, are making excellent progress
towards an adaptive optimizer/speculative inliner that will give us similar
performance to V8 (the Google JavaScript VM, lead by Lars Bak, who
implemented the HotSpot VM (Smalltalk and Java)) et al.  We are trying to
get person-power for a high-quality FFI and have a prototype for a
non-blocking VM.  When we succeed C won't be any better and so it won't be
an interesting target.  One will be able to program entirely in Smalltalk
and get excellent performance.  But we need effort.  Collaboration.

Personally I feel so discouraged when people talk about using LLVM or
libffi or whatever instead of having the courage and energy to make our
system world-class.  I have the confidence in our abilities to compete with
the best and am saddened that people in the community don't value the
technology we already have and can't show faith in our abilities to improve
it further.  Show some confidence and express support and above all get
involved.

Collaborators <http://www.mirandabanda.org/cogblog/collaborators/>
Cog Projects <http://www.mirandabanda.org/cogblog/cog-projects/>
Spur 1/3
<https://www.youtube.com/watch?v=k0nBNS1aHZ4&index=49&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X>
  Spur, a new object representa...
<http://www.slideshare.net/esug/spur-a-new-object-representation-for-cog>
Sista: Improving Cog's JIT performance 1/2
<https://www.youtube.com/watch?v=X4E_FoLysJg&list=PLJ5nSnWzQXi_6yyRLsMMBqG8YlwfhvB0X&index=76>
 Sista: Improving Cog’s JIT pe
<http://www.slideshare.net/esug/sista-talkesug2>..
Lowcode: Redoing NativeBoost ...
<http://www.slideshare.net/esug/03-lowcodeslides>


However, I think Ronie was interested in doing such work. If he succeeds
>> and reports performance improvement, then we can consider using his
>> compiler to compile the VM.
>>
>
> Keep us posted!
>
> Thierry
>

-- 
in hope,
Eliot
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20140915/2d8cbf92/attachment.htm