C-code generation is what I am interested in.

To integrate with third parties, one likes to put C-code strings directly in the Slang bits.

AsmJIT, not so much. Especially if we hook a debugger to the process and what to see what’s going on…

Phil

From: Pharo-users [mailto:pharo-users-bounces@lists.pharo.org] On Behalf Of Pavel Krivanek
Sent: mercredi 26 mars 2014 10:24
To: Any question about pharo is welcome
Subject: Re: [Pharo-users] Pavel's CCodeGenerator works under Windows MinGW: sweet

2014-03-26 9:11 GMT+01:00 Marcus Denker <marcus.denker@inria.fr>:

On 26 Mar 2014, at 09:06, Goubier Thierry <thierry.goubier@cea.fr> wrote:

>
>
> Le 26/03/2014 09:03, Marcus Denker a �crit :
>>
>> On 26 Mar 2014, at 06:37, Pavel Krivanek <pavel.krivanek@gmail.com> wrote:
>>
>>> Unbelievable... I stare how open source can work :-) I started this project yesterday so it can hardly translate more than the small examples and of course it had no announcement.
>>>
>>> So, CCodeGenerator is the standalone translator from Smalltalk to plain C extracted from VMMaker.
>>
>> One thing we need to do eventually is to have a SLANG that does not use the old AST and Parser… but the RB AST instead.
>
> I'm curious about that. I'll have a look to see how hard it would be to make the change (I'm deep in parser and AST land at the moment).
>
The nice thing would be that it would just a visitor… very similar to Opal: 1) do semantic analysis 2) a visitor emitting C code.

Later one could then even have a real intermediate representation (maybe the one of Sista?) and do some optimisation there, with all
control flow information instead of using the AST.

Ah, and there is Waterfall: http://hal.inria.fr/hal-00871353

This already contains a SLANG based on the RB AST… but compiling with native boost ASMJIT as a backend, not C.

Cool! I knew that Cami & Co. are working on something like that but not that they are so far.

We need to have both options, translate to C and to native code. One reason why I tried to make the translator standalone is to help to finally make VMMaker more modular. So the question is how far can we go to keep the linkage to VM development (that takes more Smalltalk implementations into account).

Cheers,

-- Pavel

Marcus