[Vm-dev] Re: Fwd: [Pharo-users] Understanding Slang for building
a compiler to C++
kilon.alios at gmail.com
Tue Mar 8 16:10:37 UTC 2016
Thanks Phil I was already informed about CCodeGenerator , it definitely
helps but your PDF helps even more , I see now why Esteban recommended
Slang. It looks like there is a lot I can use from both for my compiler. I
am studying them and will be back with questions. Is this the right place
to ask questions about Slang and CCodeGenerator ? I really like the idea of
Slang of two modes one interpreter mode for pure smalltalk code and one for
generating the c code. This was the direction I was going too. Prototype in
Pharo and worry about generating the C++ code only when your code reaches
On Tue, 8 Mar 2016 at 15:25, phil at highoctane.be <phil at highoctane.be> wrote:
> Check http://www.smalltalkhub.com/#!/~PavelKrivanek/CCodeGenerator as
> this is a standalone part for Slang support.
> I did some changes in the past but I think Pavel integrated them back.
> Basically this thing allows you to write Slang, emit C code.
> There is sample class to demonstrate:
> * C code generation from Slang
> * Using OSProcess to invoke C compiler to make a shared lib
> * Loading it using NativeBoost
> Here is the doc comment:
> Generate the C code into generated.c
> | cg |
> cg := CCodeGenerator new initialize.
> cg vmClass: CCGExample.
> cg addClass: CCGExample.
> CCGExample exportHeaders.
> cg storeCodeOnFile: 'generated.c' doInlining: false.
> Compile it
> gcc -c -m32 generated.c
> gcc -shared -m32 -o generated.dll generated.o
> | c |
> c := PipeableOSProcess command: 'gcc -c -m32 generated.c'.
> (c output; succeeded)
> ifFalse: [ self error: 'Compilation error: ', c errorPipelineContents
> c := PipeableOSProcess command: 'gcc -shared -m32 -o generated.dll
> (c output; succeeded)
> ifFalse: [ self error: 'Compilation error', c errorPipelineContents
> Try it
> NativeBoost clearNativeCode.
> CCGExample new nbFib4: 30.
> CCGExample new nbFactorial: 5.
> Slang code looking like this:
> factorial: anArgument
> "<var: #anArgument type: #'double'>"
> | count factorial |
> self export: true.
> count := anArgument.
> factorial := 1.
> [ count > 0 ] whileTrue:
> [ factorial := factorial * count.
> count := count - 1 ].
> ^ factorial
> Here is the PDF going into how to extend the VM with plugins and there is
> some Slang in there too.
> Sure Spur may have changed things and this may require adjustments.
> On Tue, Mar 8, 2016 at 11:15 AM, kilon.alios <kilon.alios at gmail.com>
>> Sorry for the late reply, I have been down with the flu lately.
>> My goal is mostly curiosity , I am itching to try messing with programming
>> languages but I also like keeping close with smalltalk syntax.
>> The why is that I am aiming for readable C++ code that is easy to mix with
>> existing C++ code. In my particular case is using and extending the Unreal
>> I cannot do it via shared libraries because Unreal Engine is not made to
>> used as a library , it actually messes with a lot of things as you can
>> imagine it has it own event loop, threading, GC and even adds reflection
>> C++. Also I need something that compiles statically for the iOS platform
>> where shared libraries are not allowed, and I am not sure if Android has
>> similar restrictions.
>> So even though its great to use pharo unlimited as a scripting language, I
>> think there is also usefuleness in limiting pharo usage (static types,
>> memory managment etc) when you want to generate code in another
>> language in my case C++.
>> My crazy dream would be that pharo would be able to be used in any project
>> inside a team, without any other team mates having to learn pharo. The
>> advantage would be you will be able to use pharo not just for prototyping
>> but even generate the source in another language and know would be able to
>> guess you wrote the code in Pharo. Of course this idea is not really new
>> However that dream is crazy , my more realistic dream is to build an
>> enviroment of a collection of tools that allow to annotate pharo code
>> without changing it, for example you can annotate what type a variable is
>> what variable is actually a pointer what kind of pointer (raw or smart)
>> which method would use C++ templates etc. Then a compiler will take the
>> pharo code plus the annotations and convert it to C++ code that is
>> as much as possible. That means of course there will be some sever
>> limitations of how one codes in Pharo in order to translate with ease to
>> I have been pointed here because you guys are doing something similar with
>> Slang though I am not sure whether Slang produces readable C code since it
>> looks like it does not impose any sever limitations to Smalltalk usage but
>> then I can be wrong.
>> In any case I am open to advice and suggestions.
>> View this message in context:
>> Sent from the Squeak VM mailing list archive at Nabble.com.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the Vm-dev