[Gambas-user] Replacing the JIT component

[PICCORO McKAY Lenz]

i never like the stuffs linked or related with things that has no backguard
compatibility..

the LLVM it's like python.. in every new version all the old learned things
are "gone and trasted"

the last #3 solution seems good but take in consideration that by example
until gambas 3.9 , are compilable and compatible to build and install into
any linux sinde 2011, in my case i use debian lenny and gambas still are
installable there!


Lenz McKAY Gerardo (PICCORO)
http://qgqlochekone.blogspot.com

2018-05-06 17:19 GMT-04:00 Jussi Lahtinen <jussi.lahtinen at gmail.com>:

> I think the #3 is excellent idea.
> I think it makes the debugging much easier (I have no clue what current
> JIT does to the code), if the C code is generated that point in mind.
> Moreover I think it would very well fill the place of the missing/broken
> feature. If you want to keep some of the code in native Gambas and need
> high performance, then you can write two programs (one native and one
> translated to C) and communicate between pipe, DBUS or whatever.
>
> No need to have function level compilation.
>
>
> Jussi
>
>
>
>
> On Sun, May 6, 2018 at 10:43 PM, Benoît Minisini <g4mba5 at gmail.com> wrote:
>
>> Hi,
>>
>> This is just an idea in the fly. There is nothing concrete at the moment.
>>
>> As you may know, there is a JIT component in Gambas (not made by me)
>> based on LLVM. Alas it does not work with recent versions of LLVM, because
>> apparently this huge project is not able to keep backward compatibility
>> between minor versions. (Worse than GTK+, I couldn't imagine it was
>> possible!)
>>
>> What to do now?
>>
>> 1) Rewriting the JIT compiler for newer versions of LLVM. Alas the
>> original author does not give any news, and I have no knowledge about LLVM,
>> and its C++ interface looks horrible to me.
>>
>> 2) gcc has now a JIT library, but it is an alpha version with a big
>> warning that everything may change between releases, even if it is
>> apparently relatively stable. Moreover, no idea about how many bugs the
>> library has.
>>
>> 3) Writing a Gambas -> C translator.
>>
>> My idea is that the compiler, or maybe an external program eventually
>> written in Gambas, takes a class/module source code, and transform it into
>> a C source file.
>>
>> That C source file will call the interpreter functions when needed
>> through a dedicated interpreter API.
>>
>> Then the C source file will be transform into a shared library loaded at
>> runtime by the interpreter (calling the C compiler that hence must be
>> installed).
>>
>> The advantages are:
>>
>> - C syntax is thousand times more stable than a JIT compiler library that
>> changes at each version.
>>
>> - Maybe better optimizations.
>>
>> The disadvantages are:
>>
>> - You need the compiler. But the JIT library needs most of it too, so...
>>
>> - Compiling is slower than calling a JIT library.
>>
>> - JIT library can compile at the function level. This is not practical
>> with a compiler (we won't make a shared library for each JIT function!).
>> One shared library for each class, or even one for the entire project may
>> be the solution.
>>
>> Now I'm waiting for your comments!
>>
>> Regards,
>>
>> --
>> Benoît Minisini
>>
>> --------------------------------------------------
>>
>> This is the Gambas Mailing List:
>> https://lists.gambas-basic.org/listinfo/user
>>
>> Search the list:
>> https://lists.gambas-basic.org/cgi-bin/search.cgi
>>
>> Hosted by https://www.hostsharing.net
>>
>
>
>
> --------------------------------------------------
>
> This is the Gambas Mailing List:
> https://lists.gambas-basic.org/listinfo/user
>
> Search the list:
> https://lists.gambas-basic.org/cgi-bin/search.cgi
>
> Hosted by https://www.hostsharing.net
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20180506/2b54f5f1/attachment.html>