liberty-eiffel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Liberty-eiffel] LLVM backend status


From: Paolo Redaelli
Subject: Re: [Liberty-eiffel] LLVM backend status
Date: Thu, 02 Jan 2014 13:34:06 +0100
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20131103 Icedove/17.0.10

Il 29/12/2013 23:32, Raphael Mack ha scritto:

Hello, let me ask the question about the state of the LLVM wrappers and the Smarteiffel LLVM backend and the plans for the (near *) future. Currently api doc generation fails in master due to missing loadpaths... Cheers, Rapha * near means the next two releases

First of all, Happy GNU Year to anyone!
I owe you at least an explanation for my silence which is - surprise, surprise - real life took its toll with a couple of unexpected tasks in addition to the usual efforts on an university course (Structural Analysis and Design for architecture students). I always understimate the time required for them.
Given that, the relationships between LLVM and a GNU project are quite delicate, IMHO.
I chose to "wrap" and use LLVM because it was much more easier to deal with, much more documented, providing a library-like, clean interface. At least interfacing with LLVM didn't resembled black magic like building a new gcc frontend. Well, it isn't really fair to call it black magic. Just ancient magic, as it let you feel how designs were made back in the 70-80 s. Which requires you to deal with c, write in c and use c to develop our frontend.
No way. We know that with the notable exception of bootstrap SmallEiffel, SmartEiffel and LibertyEiffel were all implemented in the language it compiles.
The fact that LLVM is released under a BSD license wouldn't have harmed, at least in any foreseeable future. Quite understandably this high quality academic project attracted the attention of many companies which liked the lack persistent freedom typical of BSD licenses so they could fork into proprietary version.
I'm pretty sure that it is a somehow required behaviour for an usa university to either patent their research or let us companies to leverage of that. Not that I am against making money of course! Luckily we have the gnu Ada compiler as an effective counterexample.
A couple of months ago I read that next gcc version will see a deep redesign of its internals, offering a much more clean, easier to interface with and documented api for front end writers. That is us.
Work is going on in the gcc repositories but I would rather approach them when they will have reached some milestone.

So I think we could stick to llvm for a while. A moving target itself thought.
The example in llvm wrappers (should) build an hello world programmatically. I wrote it when current llvm was 2.9. I know it to work with 3.2 and 3.4. I don't know if more recent llvm versions will work
Then there is src/smarteiffel/generation/llvm/ which is nothing more than a (multi-process) skeleton. The version in my github repository should fork a worker for each CPU and "scan" all the classes sending a "compile class x" to each worker; the aim is to parallelize the equivalent of  C emitting.
But it's only a skeleton.

I'm retaking some grasp on the messy code of my repository, so please keep hold on for some days (<10).

Thanks in advance for your attetion
  an overloaded (and currently sick BTW) Paolo

reply via email to

[Prev in Thread] Current Thread [Next in Thread]