Re: community-based compiler (was Re: What exactly is the licensing situation with GNAT?)

[Shark8 <OneWingedShark@gmail.com>]

On 15-Nov-14 05:44, Brian Drummond wrote:
>> I haven't found a good path, but then I'm more interested in a whole new
>> >project rather than tying ourselves down to a single implementation.
> At this stage, I'm happy to see several paths followed, some will
> inevitably turn out to be dead ends.

Agreed.
I do hope, however, that we don't get "watered-down" or "spread too 
thin" by having too many paths.

> I am (very tentatively) looking at ghdl's intermediate representation.
> which currently interfaces to three compiler backends - gcc,
> (experimentally) LLVM, and its own 32-bit x86 JIT compiler.
>
> A translation between ASIS and this IR would (based on the equivalent
> translation layer in ghdl) be something like a 30,000 line project in
> itself. Big, but more manageable than an entire compiler.

An interesting approach.

I do wonder about VHDL though: since it's a hardware-description 
language, could it be feasible to base a compiler backend on it so that 
targeting a new system is merely a matter of feeding it the description 
of that hardware? -- Or am I completely misinterpreting what its purpose is?

> Having just bought the book (DIANA : An intermediate language for Ada) it
> appears to me that DIANA was effectively obsoleted by ASIS (though
> perhaps a simple ASIS <-> DIANA translation might be feasible, assuming
> compatible Ada versions). I don't believe DIANA was ever updated for
> Ada-95 for one thing, so at this point ASIS looks like a better starting
> point.

I can see it both ways; the ASIS, having been updated through Ada-95, 
would have a lot of the Ada 2005 stuff in-place -- on the other hand, 
updating DIANA for Ada 2012 could allow for a bit of regularizing the IR 
to handle things in a more uniform manner, as well as [possibly] 
redefining the interface in terms of GENERICs and/or INTERFACEs.*

ASIS <-> DIANA translation you mention might be possible via a 
Translation-grammar; I came across them in a paper [I think on DIANA] 
and they sound pretty interesting even if I've not heard of them before.

* Another thing that might be interesting is an [portable] IR-executor, 
this would have much of the benefit of bytecode w/o [directly] depending 
on DOTNET or JVM... heck, if that translation-grammar module works very 
well we could, in theory, make it so that adding a new target is simply 
writing a new translation-grammar.