Implementing an Ada compiler and libraries.
in [ADA]
|
From: Georg Bauhaus on 11 May 2007 04:39 On Thu, 2007-05-10 at 19:34 +0200, Pascal Obry wrote: > Why not play on a C generator for the Ada language ? > > Using ASIS as a start. You then don't have to play with backend > generation. Probably a project that is easier to tackle than a true Ada > compiler even if already quite a bit of work :) Given the C language, there might be a few platform issues in case you'd have to deal with such things as MIN_INT - 1 :-) There is at least one compiler front end that generates (readable) C. Maybe someone having worked with AdaMagic by SofCheck has a few hints? Also, several Eiffel compilers use C as the target language.
From: Ludovic Brenta on 11 May 2007 06:09 Pascal Obry writes: > Ludovic Brenta a écrit : >> That's what GNAT does, only it uses a simple checksum for performance >> reasons. Calculating the checksum and comparing it with the one in >> the library (.ali files in the case of GNAT) has to be faster than >> recompiling the file. > > No that's not a simple checksum since some time. It is now using md5. CRC32, by the looks of scng.adb (see Accumulate_Checksum). I do think that md5 would be overkill. -- Ludovic Brenta.
From: Duncan Sands on 11 May 2007 07:04 On Thursday 10 May 2007 23:00:59 Pascal Obry wrote: > Duncan Sands a écrit : > >> Why not play on a C generator for the Ada language ? > > > > I have one! I'm porting the GNAT Ada f-e to LLVM > > (http://llvm.org/), which replaces the gcc code > > optimizers with those of LLVM. LLVM has a C backend > > which turns its IR into C. > > Interesting, I'll probably have a look at some point. Thanks. It will most likely be available with LLVM 2.1. I will post an announcement here when I release it. Ciao, Duncan.
From: Pascal Obry on 11 May 2007 12:33 Ludovic Brenta a écrit : > CRC32, by the looks of scng.adb (see Accumulate_Checksum). I do think > that md5 would be overkill. Right, shame one me this is a part I've been working on, my memory is that bad :( Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595
From: Lucretia on 11 May 2007 13:39
On May 11, 8:14 am, Gautier <gaut...(a)fakeaddress.nil> wrote: > > What if the body of one or two require the subprogram three? Is this a > > form of forward declaration? Would interleaving specs and body's cause > > problems? Probably. > > Most Ada compilers allow multiple compilation units in the same file. > They are just treated the same way as if they were each in its file. > It would be surprising if this was not described somewhere in the Manual... There isn't as far as I've found. It's implementation dependent. > In your example, three is not visible by the body of one or two. > > package one is procedure z; end; > package two is procedure z; end; > procedure three is begin null; end; > package body one is procedure z is begin null; end; end; > package body two is procedure z is begin three; end; end; > > ObjectAda says to that: > multipack: Error: line 5 col 44 LRM:4.1(3), Direct name, three, is not > visible, Ignoring future references Yeah, my example wasn't complete, just an example ordering I slapped together. > conversely... > > package one is procedure z; end; > package two is procedure z; end; > procedure three is begin null; end; > package body one is procedure z is begin null; end; end; > with three; > package body two is procedure z is begin three; end; end; > > compiles fine. Now, I take it there would be a compiler error if three came after two? > And yes you can put others specs after bodies, just a spec of a package after > its body seems not ok: > > package body one is procedure z is begin null; end; end; > package one is procedure z; end; > > multipack: Error: line 1 col 15 LRM:7.2(4), corresponding package spec not > found, continuing Ok. So, it seems that Aonix just enforces that the dependencies within a file be sorted out by the programmer, and that the specs are always before the bodies. What if you do: package one is ... end one; package two is ... end two; package body one is ... end one; package body two is ... end two; I take it, this is allowed? Thanks, Luke. |