Re: Cross-toolchain for DS [was: Newcomers to

[Brian Drummond <brian3@shapes.demon.co.uk>]

On Wed, 15 Oct 2014 10:32:32 +0000, Natasha Kerensikova wrote:

> Hello,
> 
> On 2014-10-15, Brian Drummond <brian3@shapes.demon.co.uk> wrote:
>> On Sun, 12 Oct 2014 10:56:07 +0000, Natasha Kerensikova wrote:
>>> The reason why I'm asking, is I'm stilling working on updating gela
>>> and building on it a RTS-limited LLVM-based Ada 95 compiler seems
>>> realistic (albeit far away down the road).
>>
>> How is that coming along?
> 
> I don't have much time to put into it, so it is indeed coming along but
> very slowly.
> 
> From what I gathered, Gela doesn't even fully cover Ada 95, so my first
> intermediate goal is turning into a fully-featured Ada 95 ASIS provider
> (which is what I meant with "updating" in the quote above).

I thought it was pretty close. But completing Ada-95 coverage would be a 
necessary prerequisite (if only from learning how) to extending it to 
Ada-2005 coverage, so ... has very good longer term potential.

> To reach that intermediate goal, I'm using AdaControl as an ASIS test
> suite, so the very first step is plugging Gela into AdaControl. That
> plugging is what I'm currently dealing with, and it feels almost
> complete.

Now that could be an excellent project! As ASIS is only a specification, 
and implementations differ, how the differences affect a sizeable 
application *using* Asis, seems like fairly unexplored territory. 
I look forward to seeing it when it's ready, and learning from it. And if 
it "feels almost complete" that's encouraging, that the variations 
between at least two ASIS implementations are manageable.

>> For me, Gela built successfully, and I started to look at connecting it
>> to an intermediate representation which already has translators to gcc
>> and experimentally, LLVM (and more, specifically a JIT targetting x86,
>> which would make a very lightweight compiler).

This is part of GHDL, of course, and I expect to plunge back into GHDL 
which is overdue for another release. But along the way I want to look 
into the possibility of repurposing its IR language as a back end for 
Gela...

> Basically building a compiler is an awefully large task, and it would
> still feel daunting to me even if everybody here gathered to magically
> work on it without any communication/coordination overhead.

I don't pretend to have answers to that!

> For example, I recently realized that Standard package cannot be written
> in Ada (think of the declaration of Wide_Character type), it probably
> has to involve some compiler magic, but I don't know yet how compatible
> with Gela architecture such a magic is.

GHDL has possibly similar problems with its Standard package, and there 
is indeed some compiler magic involved. I can't remember the details 
offhand but I believe it involves the translation phase onwards mimicking 
the process of compilation so Gela may never encounter actual "standard.ad
[sb]" source, and I believe an Ada compiler could do likewise.

Please say a little more about the problems you see with Wide_Character, 
it's not obvious to me what they are.

> And once basic code generation is operation, only then would I starting
> looking at RTS issues, because once again, and RTS-less Ada compiler has
> some use, while RTS fragments without a good compiler is useless. I just
> wonder whether a significant part of the RTS can be targeting LLVM
> itself, and thereby be automatically portable across all backend
> targets. That would be a very nice perk for the project.

RTS is fairly separable from the compiler, and somewhat divisible into 
general and target-specific parts. When I moved the AVR-Ada minimal RTS 
(no tasking, basic exceptions) to MSP430 I found most of it transferred 
wholesale; possibly 40% of the files needed some change. I didn't attempt 
to divide it into target-dependent and target-independent parts. Yet...

One disappointment in Gnat is they don't separate the RTS sources from 
the compiler. That would make the process of plugging in a different RTS 
easier to understand. I learned a lot from the AVR-Ada project, and 
Luke's Tamp is another good starting point, but there will be more to 
learn as the RTS effort rolls on to encompass tasking.

So there may be no need to specifically target LLVM with the RTS (but 
when we get to tasking, priorities, scheduling there may be advantages in 
doing so.)

But there seem to be a bunch of people looking at RTS for ARM, possibly 
aiming at Ravenscar tasking, so that may happen independently of compiler 
work.

> However please note that this is only a personal strategic choice, I
> won't blame or criticize anybody starting to look at code generation
> now, I'm just explaining the rationale behind my not looking at it yet.

Agreed - but it's good to discuss and at least not duplicate effort! Not 
that it would be a problem if we did duplicate - at this stage anything I 
do on code generation will be throwaway junk, just to teach myself about 
the process. 

- Brian