[Vm-dev] Re: Fwd: [Pharo-users] Understanding Slang for building a compiler to C++

[Dimitris Chloupis]

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
production state.
On Tue, 8 Mar 2016 at 15:25, phil at highoctane.be <phil at highoctane.be> wrote:

>
> Kilon,
>
> 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.
>
>
> http://www.smalltalkhub.com/#!/~philippeback/HOExtras/packages/CCodeGenerator-Core
>
> 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
> printString].
> c := PipeableOSProcess command: 'gcc -shared -m32 -o generated.dll
> generated.o'.
> (c output; succeeded)
> ifFalse: [ self error: 'Compilation error', c errorPipelineContents
> printString].
> 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.
>
> HTH
> Phil
>
>
> On Tue, Mar 8, 2016 at 11:15 AM, kilon.alios <kilon.alios at gmail.com>
> wrote:
>
>>
>> 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
>> Engine.
>>
>> I cannot do it via shared libraries because Unreal Engine is not made to
>> be
>> 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
>> to
>> 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
>> programming
>> 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
>> or
>> unique.
>>
>> 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
>> or
>> 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
>> readable
>> 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
>> C++.
>>
>>
>> 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:
>> http://forum.world.st/Fwd-Pharo-users-Understanding-Slang-for-building-a-compiler-to-C-tp4882613p4883161.html
>> Sent from the Squeak VM mailing list archive at Nabble.com.
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/vm-dev/attachments/20160308/f117059e/attachment-0001.htm