Implementing an Ada compiler and libraries.

Implementing an Ada compiler and libraries.

[Lucretia]

Hi,

I started to implement the Ada/CS from the Crafting a compiler in C
book. I was doing this from scratch, but I decided that I'd rather
implement a real subset using the real rules from the standard. So,
now I'm looking into implementing an Ada 2005 subset.

I don't want to get into a flamewar over reasons why/not to do this,
I'd just like to do it ;D and not have this thread go massively off
topic ;)

Ok, here are my aims, in no particular order:

* Similar Ada/CS subset, but based on the Ada 2005 standard.
* Use ANTLR for the front-end.
* Restrict the input to ASCII.
* Use LLVM for the back-end.
* Also look into writing a back end from scratch (not a priority and
only for experience).
* Allow the use of multiple compilation units in 1 operating system
file.
* Also allow GNAT *.ad[sb] files.
* Experiment with libraries.

I've read some older threads from 1994-1995 which cover how older
compilers implemented a repository based Ada standard library in which
compilations units were added to.

But I'm interested in seeing how I can get the compiler to not have to
reparse other source files (when with'd) in order to compile a unit.
Also, I'd like to see how static/shared libraries can be implemented/
used to extend the Ada standard library. I don't want to have to have
tons of source files lying around for a static/shared library, I
honestly don't see the need. Surely, it's possible to build a compiler
that can get the information it needs from the library itself (or at
least a companion library rather than a ton of different ALI files)?

Now, I'd really like to hear from people who have implemented an Ada
compiler and people who have used other compilers (I've only used
GNAT). Basically, I'm interested in how other implementations handle
the library. Note that there are 2 ideas of library here:

1) The standard Ada library.
2) Link/shared libraries found on operating systems.

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Dmitry A. Kazakov]

On 9 May 2007 07:37:31 -0700, Lucretia wrote:

> I've read some older threads from 1994-1995 which cover how older
> compilers implemented a repository based Ada standard library in which
> compilations units were added to.
> 
> But I'm interested in seeing how I can get the compiler to not have to
> reparse other source files (when with'd) in order to compile a unit.

Why should it? Certainly, you would have some intermediate representation
which includes symbolic tables and other stuff the compiler creates after
semantic analysis before code generation. A compiled library unit will have
this stored in some appropriate format.

An interesting issue is cross-platform library units, I was playing with
this idea, but came to no conclusion.

> Also, I'd like to see how static/shared libraries can be implemented/
> used to extend the Ada standard library.

I don't think it is a good idea to mix Ada libraries and
object/dynamic-linking libraries, at least in existing OS'es. In some OO OS
with advanced containers it could work. But still, these are two different
abstraction levels. Object code is too close to the hardware. The library
units should probably be kept on the other side.

> I don't want to have to have
> tons of source files lying around for a static/shared library, I
> honestly don't see the need. Surely, it's possible to build a compiler
> that can get the information it needs from the library itself (or at
> least a companion library rather than a ton of different ALI files)?

Or a database, for that matter...

> Now, I'd really like to hear from people who have implemented an Ada
> compiler and people who have used other compilers (I've only used
> GNAT). Basically, I'm interested in how other implementations handle
> the library. Note that there are 2 ideas of library here:
> 
> 1) The standard Ada library.
> 2) Link/shared libraries found on operating systems.

I remember RSX-11 in which macro and object libraries were handled by the
same librarian tool.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 9, 5:51 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> > But I'm interested in seeing how I can get the compiler to not have to
> > reparse other source files (when with'd) in order to compile a unit.
>
> Why should it? Certainly, you would have some intermediate representation
> which includes symbolic tables and other stuff the compiler creates after
> semantic analysis before code generation. A compiled library unit will have
> this stored in some appropriate format.

True, but is it possible to include dependency info within the object
itself?

> An interesting issue is cross-platform library units, I was playing with
> this idea, but came to no conclusion.

LLVM would be capable of this.

> > Also, I'd like to see how static/shared libraries can be implemented/
> > used to extend the Ada standard library.
>
> I don't think it is a good idea to mix Ada libraries and
> object/dynamic-linking libraries, at least in existing OS'es. In some OO OS
> with advanced containers it could work. But still, these are two different
> abstraction levels. Object code is too close to the hardware. The library
> units should probably be kept on the other side.

Why? Are you saying that it would be better to store libraries in IR
rather than binary form? For a linux based compiler (for example) you
still need to be able to link with binary libs, and I do think it's
necessary to be able to build a shared lib with an Ada compiler - this
would not be possible with IR, unless the whole OS worked in this way.

> > I don't want to have to have
> > tons of source files lying around for a static/shared library, I
> > honestly don't see the need. Surely, it's possible to build a compiler
> > that can get the information it needs from the library itself (or at
> > least a companion library rather than a ton of different ALI files)?
>
> Or a database, for that matter...

Like the old Ada library? I was actually thinking, if I couldn't embed
the other information required by the compiler into the final object,
then a separate "lib" containing only this informaton would be
necessary.

> > Now, I'd really like to hear from people who have implemented an Ada
> > compiler and people who have used other compilers (I've only used
> > GNAT). Basically, I'm interested in how other implementations handle
> > the library. Note that there are 2 ideas of library here:
>
> > 1) The standard Ada library.
> > 2) Link/shared libraries found on operating systems.
>
> I remember RSX-11 in which macro and object libraries were handled by the
> same librarian tool.

RSX-11 is before my time, got any more info on this?

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Dmitry A. Kazakov]

On 9 May 2007 10:21:20 -0700, Lucretia wrote:

> On May 9, 5:51 pm, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>>> But I'm interested in seeing how I can get the compiler to not have to
>>> reparse other source files (when with'd) in order to compile a unit.
>>
>> Why should it? Certainly, you would have some intermediate representation
>> which includes symbolic tables and other stuff the compiler creates after
>> semantic analysis before code generation. A compiled library unit will have
>> this stored in some appropriate format.
> 
> True, but is it possible to include dependency info within the object
> itself?

Sure, it is just another "with". Each "with" loads (maps into the memory)
the corresponding precompiled unit (compilation context). Some minor
relocation stuff will be needed, checksums and time stamping as Gautier has
mentioned. The symbolic tables (actually contexts) can be organized as a
tree-stack to reduce loading overhead. "Use" plants a tree in the forest. I
did such thing once. I guess it should make table look-ups slower. So the
net effect on the compilation speed is unclear, before you actually build
the thing.

>> An interesting issue is cross-platform library units, I was playing with
>> this idea, but came to no conclusion.
> 
> LLVM would be capable of this.

Then is not a cross-platform, I mean the only platform here is the VM.
Otherwise, it could be doable. Though many static things which are
platform-dependent will cease to be compile-time static. So you will be
unable to have certain things fully precompiled.

> Why? Are you saying that it would be better to store libraries in IR
> rather than binary form?

IR = infra red?

>>> I don't want to have to have
>>> tons of source files lying around for a static/shared library, I
>>> honestly don't see the need. Surely, it's possible to build a compiler
>>> that can get the information it needs from the library itself (or at
>>> least a companion library rather than a ton of different ALI files)?
>>
>> Or a database, for that matter...
> 
> Like the old Ada library?

It wasn't that bad. DEC Ada had a library, if I correctly remember. With an
integrated source control system it might become more attractive than the
GNAT model. If I designed Ada tool-chain (the compiler is only a part of),
I would probably choose this.

> I was actually thinking, if I couldn't embed
> the other information required by the compiler into the final object,
> then a separate "lib" containing only this informaton would be
> necessary.

You mean symbolic info for the debugger?

>>> Now, I'd really like to hear from people who have implemented an Ada
>>> compiler and people who have used other compilers (I've only used
>>> GNAT). Basically, I'm interested in how other implementations handle
>>> the library. Note that there are 2 ideas of library here:
>>
>>> 1) The standard Ada library.
>>> 2) Link/shared libraries found on operating systems.
>>
>> I remember RSX-11 in which macro and object libraries were handled by the
>> same librarian tool.
> 
> RSX-11 is before my time, got any more info on this?

It was too primitive to be used for Ada. But the idea is basically same.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Implementing an Ada compiler and libraries.

[Duncan Sands]

> > LLVM would be capable of this.
> 
> Then is not a cross-platform, I mean the only platform here is the VM.
> Otherwise, it could be doable. Though many static things which are
> platform-dependent will cease to be compile-time static. So you will be
> unable to have certain things fully precompiled.

LLVM, in spite of the name, is not a virtual machine like java.  It is
a compiler, or rather a compiler library, with a platform independent
IR.  The gcc C and C++ front-ends have been ported to LLVM, i.e. the
LLVM optimizers and IR are used instead of the gcc ones, and I'm currently
porting the Ada front-end to it.  The LLVM IR produced is not platform
independent, simply because the gcc trees produced by the front-ends are
not platform independent.

Ciao,

Duncan.

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 10, 8:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
wrote:
> > True, but is it possible to include dependency info within the object
> > itself?
>
> Sure, it is just another "with". Each "with" loads (maps into the memory)
> the corresponding precompiled unit (compilation context). Some minor
> relocation stuff will be needed, checksums and time stamping as Gautier has
> mentioned. The symbolic tables (actually contexts) can be organized as a
> tree-stack to reduce loading overhead. "Use" plants a tree in the forest. I
> did such thing once. I guess it should make table look-ups slower. So the
> net effect on the compilation speed is unclear, before you actually build
> the thing.

True, have been thinking about this today. Don't know about the speed,
it'd have to be tested with enough of a subset and enough compilation
units.

> >> An interesting issue is cross-platform library units, I was playing with
> >> this idea, but came to no conclusion.
>
> > LLVM would be capable of this.
>
> Then is not a cross-platform, I mean the only platform here is the VM.
> Otherwise, it could be doable. Though many static things which are
> platform-dependent will cease to be compile-time static. So you will be
> unable to have certain things fully precompiled.

Well, no, the target is the VM, but it can be translated into any back-
end, thus portable to some degree.

> > Why? Are you saying that it would be better to store libraries in IR
> > rather than binary form?
>
> IR = infra red?

;D Intermediate Representation

> >> Or a database, for that matter...
>
> > Like the old Ada library?
>
> It wasn't that bad. DEC Ada had a library, if I correctly remember. With an
> integrated source control system it might become more attractive than the
> GNAT model. If I designed Ada tool-chain (the compiler is only a part of),
> I would probably choose this.

That's actually not a bad idea.

> > I was actually thinking, if I couldn't embed
> > the other information required by the compiler into the final object,
> > then a separate "lib" containing only this informaton would be
> > necessary.
>
> You mean symbolic info for the debugger?

No, I mean't the dependency information required by the compiler.

> >> I remember RSX-11 in which macro and object libraries were handled by the
> >> same librarian tool.
>
> > RSX-11 is before my time, got any more info on this?
>
> It was too primitive to be used for Ada. But the idea is basically same.

What idea? Same as what?

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 10, 6:39 pm, Lucretia <lucret...@lycos.co.uk> wrote:
> On May 10, 8:59 am, "Dmitry A. Kazakov" <mail...@dmitry-kazakov.de>
> wrote:
>
> > > True, but is it possible to include dependency info within the object
> > > itself?
>
> > Sure, it is just another "with". Each "with" loads (maps into the memory)
> > the corresponding precompiled unit (compilation context). Some minor
> > relocation stuff will be needed, checksums and time stamping as Gautier has
> > mentioned. The symbolic tables (actually contexts) can be organized as a
> > tree-stack to reduce loading overhead. "Use" plants a tree in the forest. I
> > did such thing once. I guess it should make table look-ups slower. So the
> > net effect on the compilation speed is unclear, before you actually build
> > the thing.
>
> True, have been thinking about this today. Don't know about the speed,
> it'd have to be tested with enough of a subset and enough compilation
> units.

** This post may be a jumble of ideas ;D

To elaborate some more, I've been thinking along the lines of:

The parser matches a with statement, it then has to check to make sure
this package has not already been with'd. If it hasn't, check to see
if the package exists in binary form. If not, the compiler needs to
start another compilation - this library unit just with'd then with
the symbol table and go back to the original compilation.

Now this would make either a recursive compiler, or a compiler with
multiple tasks (if developed in Ada ;D).

Also, allowing multiple compilation units in the same file can be
problematic, e.g.

package one is ...;
package two is ...;
procedure three is ...;
package body one is ...;
package body two is ...;

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.

I now think that I understand why GNAT chooses the model it has done,
although I don't know whether the compiler handles dependency checking
or if gnatmake does - it looks like gnatmake does, but underneath it
could be the compiler.

Another area I've thought about is the symbol table:

1) For a package spec, there is a public (is this the limited view?)
and a private part, this can be compiled to symbol table.
2) For the package body, there is another private part which cannot be
accessed outside of the spec unless exported in the public part of the
spec, this can be compiled into the spec's symbol table or a separate
one.
3) All other compilation units compile down to 1 symbol table.

For a final build, only the public area of the package spec needs to
be in the symbol table, in a debug build, the whole lot needs to be
there.

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Dmitry A. Kazakov]

On 10 May 2007 11:06:28 -0700, Lucretia wrote:

> The parser matches a with statement, it then has to check to make sure
> this package has not already been with'd. If it hasn't, check to see
> if the package exists in binary form. If not, the compiler needs to
> start another compilation - this library unit just with'd then with
> the symbol table and go back to the original compilation.

Yes, this is roughly how I did it.
 
> Now this would make either a recursive compiler, or a compiler with
> multiple tasks (if developed in Ada ;D).

I did it recursively. There was a stack of contexts, so I put a stub on
that stack(s) and called the compiler again, quite simple.

> Also, allowing multiple compilation units in the same file can be
> problematic, e.g.
> 
> package one is ...;
> package two is ...;
> procedure three is ...;
> package body one is ...;
> package body two is ...;
> 
> 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.

The context of either body cannot include the body of three, only the
declaration of. (I don't consider inlining here)

> I now think that I understand why GNAT chooses the model it has done,
> although I don't know whether the compiler handles dependency checking
> or if gnatmake does - it looks like gnatmake does, but underneath it
> could be the compiler.
> 
> Another area I've thought about is the symbol table:
> 
> 1) For a package spec, there is a public (is this the limited view?)
> and a private part, this can be compiled to symbol table.

These are two different contexts. The private one refers to the public one.
If you kept them apart, you could reduce the number of recompilations.

> 2) For the package body, there is another private part which cannot be
> accessed outside of the spec unless exported in the public part of the
> spec, this can be compiled into the spec's symbol table or a separate
> one.

This is a third context which is needed for separate bodies.

> 3) All other compilation units compile down to 1 symbol table.

Wait a minute (:-)), there also exist task and protected types, and, well
generics. Though the pattern is same.

Also, you will probably need special contexts for matching prefix notation
(be it damned (:-)), keyed associations, qualified names, aggregates. I
mean if you wanted to take the advantage of the approach. In my case I
postponed all this stuff until the semantic analysis, but the contexts were
needed anyway.

> For a final build, only the public area of the package spec needs to
> be in the symbol table, in a debug build, the whole lot needs to be
> there.

Well, contexts could serve as source of symbolic information, but the
debugger needs a lot more stuff. I am not sure if the format should be
preserved as-is. Clearly it could be a great advantage, but I cannot say
how realistic is that.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de

Re: Implementing an Ada compiler and libraries.

[Gautier]

Lucretia:

> Also, allowing multiple compilation units in the same file can be
> problematic, e.g.
> 
> package one is ...;
> package two is ...;
> procedure three is ...;
> package body one is ...;
> package body two is ...;
> 
> 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...
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

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.
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

HTH
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 11, 8:14 am, Gautier <gaut...@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.

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 11, 6:39 pm, Lucretia <lucret...@lycos.co.uk> wrote:
> > 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?

Also, further to the above, how do other compilers handle this? Janus?
SofCheck?

Does Tucker Taft still come here?

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Robert A Duff]

Lucretia <lucretia9@lycos.co.uk> writes:

> On May 11, 6:39 pm, Lucretia <lucret...@lycos.co.uk> wrote:
>> > 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?
>
> Also, further to the above, how do other compilers handle this? Janus?
> SofCheck?

Aonix uses the SofCheck front end.

Anyway, an implementation is allowed to impose some requirements on the
order of units within a file, but is not required to do so.  It's the
with_clauses that determine visibility of library units -- not their
order in the source file.

- Bob

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 11, 7:20 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> > Also, further to the above, how do other compilers handle this? Janus?
> > SofCheck?
>
> Aonix uses the SofCheck front end.

Ah yes.

> Anyway, an implementation is allowed to impose some requirements on the
> order of units within a file, but is not required to do so.  It's the

Yep.

> with_clauses that determine visibility of library units -- not their
> order in the source file.

True, but how would a compiler that didn't impose limits (are there
any?) manage to find compilation units with'd? At least with GNAT it
uses package name => filename, so that's easy to implement, but with
multiple compilation units per file, it's much more tricky. I've
basically thought the only way to partially do it is to compile the
source into a parse tree, then traverse it to generate the AST, symbol
tables, dependencies, etc. You then have the problem of finding a unit
within a file? i.e. how do you know in which file to look?

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Georg Bauhaus]

On Fri, 2007-05-11 at 11:49 -0700, Lucretia wrote:

> how would a compiler that didn't impose limits (are there
> any?) manage to find compilation units with'd? At least with GNAT it
> uses package name => filename,

GNAT also comes with gnatchop, pragma Source_File_Name, and naming
conventions.

>  i.e. how do you know in which file to look?

Have you had an opportunity to look at the contents of the library
and info files generated by the Aonix (SofCheck) compiler?

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 11, 9:34 pm, Georg Bauhaus <bauh...@futureapps.de> wrote:
> >  i.e. how do you know in which file to look?
>
> Have you had an opportunity to look at the contents of the library
> and info files generated by the Aonix (SofCheck) compiler?

No, I don't have a Windows installation at the moment.

Luke.

Re: Implementing an Ada compiler and libraries.

[Robert A Duff]

Lucretia <lucretia9@lycos.co.uk> writes:

> True, but how would a compiler that didn't impose limits (are there
> any?) manage to find compilation units with'd?

Here's one way:

I presume the way one invokes the compiler is via a "build" tool of some
sort (something like gnatmake or adabuild).

Keep a data structure that tells which compilation units are in which
source files.  Whenever the build tool is invoked, it first parses all
the files that changed since last time, and updates this data structure.
If any files are new, they need to be parsed.  If any files have been
deleted, all information about them in the data structure should be
deleted.  You can store this data structure on disk, if you like.

At this point, give an error if there are duplicate names (unless the
user has explicitly requested that one should override the other).

Now you have all the information you need to run the rest of the
compiler phases (after parsing) on everything in the right order
(or partially in parallel).

I know this method can be implemented efficiently, because I've done it
several times (not for Ada compilers, but for other language processing
tools (Ada and non-Ada)).

>... At least with GNAT it
> uses package name => filename, so that's easy to implement, but with
> multiple compilation units per file, it's much more tricky. I've
> basically thought the only way to partially do it is to compile the
> source into a parse tree, then traverse it to generate the AST,

Generate the AST from the parse tree?  I normally generate the syntax
tree directly during parsing.

You can save the syntax trees on disk, if you like.  Or in memory.  The
nice thing about saving syntax trees is that they depend only on one
source file.  When you modify one source file, you might need to do
semantic analysis and code gen on many things, but you only need to
parse one thing.

If you store things on disk, you have to be very careful to prevent them
from becoming corrupt.  Otherwise, the user will end up having to start
over from scratch all the time, defeating the purpose.

>... symbol
> tables, dependencies, etc. You then have the problem of finding a unit
> within a file? i.e. how do you know in which file to look?

- Bob

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 11, 11:06 pm, Robert A Duff <bobd...@shell01.TheWorld.com>
wrote:
> Lucretia <lucret...@lycos.co.uk> writes:
> > True, but how would a compiler that didn't impose limits (are there
> > any?) manage to find compilation units with'd?
>
> Here's one way:
>
> I presume the way one invokes the compiler is via a "build" tool of some
> sort (something like gnatmake or adabuild).
>
> Keep a data structure that tells which compilation units are in which
> source files.  Whenever the build tool is invoked, it first parses all
> the files that changed since last time, and updates this data structure.
> If any files are new, they need to be parsed.  If any files have been
> deleted, all information about them in the data structure should be
> deleted.  You can store this data structure on disk, if you like.

So, essentially you're saying create a project file which lists which
compilation units are in which files then the build tool will know
where they are?

> At this point, give an error if there are duplicate names (unless the
> user has explicitly requested that one should override the other).
>
> Now you have all the information you need to run the rest of the
> compiler phases (after parsing) on everything in the right order
> (or partially in parallel).
>
> I know this method can be implemented efficiently, because I've done it
> several times (not for Ada compilers, but for other language processing
> tools (Ada and non-Ada)).
>
> >... At least with GNAT it
> > uses package name => filename, so that's easy to implement, but with
> > multiple compilation units per file, it's much more tricky. I've
> > basically thought the only way to partially do it is to compile the
> > source into a parse tree, then traverse it to generate the AST,
>
> Generate the AST from the parse tree?  I normally generate the syntax
> tree directly during parsing.

Well, I was thinking that as you didn't know which compilation units
were in which files, then building a tree without checking, you can
then parse the tree and when you hit a "with" node, you then start
looking for other compilation units.

Just a thought ;D

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Randy Brukardt]

"Lucretia" <lucretia9@lycos.co.uk> wrote in message
news:1178905389.489947.61760@o5g2000hsb.googlegroups.com...
> On May 11, 6:39 pm, Lucretia <lucret...@lycos.co.uk> wrote:
> > > 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?
>
> Also, further to the above, how do other compilers handle this? Janus?
> SofCheck?

Janus/Ada works roughly the same as Aonix; the compilations are run as if
they are separate compilations given to the compiler in the order that they
exist in the source file. Personally, I don't think anything else makes
sense, but as someone noted, there isn't any rule specifying how this must
work.

                                         Randy.

Re: Implementing an Ada compiler and libraries.

[Robert A Duff]

Lucretia <lucretia9@lycos.co.uk> writes:

> But I'm interested in seeing how I can get the compiler to not have to
> reparse other source files (when with'd) in order to compile a unit.

Presumably by storing information (symbol tables and whatnot) in
permanent disk files.  If you do that, I think you should design it as a
_pure_ optimization.  That is, the system should behave exactly as if
everything is compiled from source every time, except that it's faster.
Don't mimic the Ada 83 compilers that had a notion of "compiling things
into the library", where a source file sitting right there in the source
directory is ignored, unless "compiled into...".

If you do this, you need to design a permanent (on disk) representation
that is small.  I think it's possible, but it's not easy -- the
"obvious" representation of symbol tables will be 10 times larger than
the source code.  If it's 10 times larger, then it defeats the purpose
-- reading it in from disk will be slower than re-analyzing the original
source code.

You also suggested storing the info in the object files.  Yes, that is
possible, given a reasonable object file format that allows arbitrary
information to be stored, in addition to the actual machine code.

Building a complete Ada implementation is a daunting task (many
person-years).  You said you're doing a subset of Ada 2005, and I assume
you're doing this "just for fun".  Keep your subset small, or you will
never finish.

- Bob

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 9, 9:48 pm, Robert A Duff <bobd...@shell01.TheWorld.com> wrote:
> Presumably by storing information (symbol tables and whatnot) in
> permanent disk files.  If you do that, I think you should design it as a
> _pure_ optimization.  That is, the system should behave exactly as if
> everything is compiled from source every time, except that it's faster.
> Don't mimic the Ada 83 compilers that had a notion of "compiling things
> into the library", where a source file sitting right there in the source
> directory is ignored, unless "compiled into...".

Yes, I have no intention of having to add stuff to the library before
it can compile. I'm looking at a hybrid of what GNAT does combined
with the ability to use precompiled units in binary form.

> If you do this, you need to design a permanent (on disk) representation
> that is small.  I think it's possible, but it's not easy -- the
> "obvious" representation of symbol tables will be 10 times larger than
> the source code.  If it's 10 times larger, then it defeats the purpose
> -- reading it in from disk will be slower than re-analyzing the original
> source code.
>
> You also suggested storing the info in the object files.  Yes, that is
> possible, given a reasonable object file format that allows arbitrary
> information to be stored, in addition to the actual machine code.

DWARF?

> Building a complete Ada implementation is a daunting task (many
> person-years).  You said you're doing a subset of Ada 2005, and I assume
> you're doing this "just for fun".  Keep your subset small, or you will
> never finish.

Nope, just a subset.

Luke.

Re: Implementing an Ada compiler and libraries.

[Randy Brukardt]

"Robert A Duff" <bobduff@shell01.TheWorld.com> wrote in message
news:wccfy65n2pq.fsf@shell01.TheWorld.com...
...
> If you do this, you need to design a permanent (on disk) representation
> that is small.  I think it's possible, but it's not easy -- the
> "obvious" representation of symbol tables will be 10 times larger than
> the source code.  If it's 10 times larger, then it defeats the purpose
> -- reading it in from disk will be slower than re-analyzing the original
> source code.

I don't quite buy this. "10 times larger" seems to be a gross overestimate
(for Janus/Ada, it tends to be more like 2-3 times, and we did little to
make the disk files smaller -- they're not the limited factor for
compilation speed). It's necessary to keep the symbol table memory use
reasonable (else paging costs will eat you up), and directly translating
that to disk files is straightforward.

Also, the cost of reading files vs. reparsing depends very much on how much
effort is encoded in the files. Reading text is slower than known size
binary files to begin with (although on modern machines, the difference
isn't that significant), and there is a lot of other work that needs to go
on to analyze a source file. My experience is that Janus/Ada is faster than
Gnat on most compilations (although the difference isn't really significant,
except on very large files where Gnat is faster because the Janus/Ada
optimizer is worse than quadratic in program size).

                     Randy.

Re: Implementing an Ada compiler and libraries.

[Gautier]

Hello,

You seem to look for a model where each unit compilation ands into a file that 
contains, roughly, the following information (with overlaps):
- the specification, "digested"
- the contents of the .ali file
- unit dependencies
- time stamps to check need of recompilations
- the compiled code (the .o object file itself).

This model exists and works fine (esp., less files and a way faster 
compilation!), it is the one of Turbo Pascal's .TPU files (~1988...) and its 
descendants (TPW, Delphi). You just have to take a close look at it. No need 
to reinvent anything...
______________________________________________________________
Gautier         -- http://www.mysunrise.ch/users/gdm/index.htm
Ada programming -- http://www.mysunrise.ch/users/gdm/gsoft.htm

NB: For a direct answer, e-mail address on the Web site!

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 9, 10:15 pm, Gautier <gaut...@fakeaddress.nil> wrote:
> Hello,
>
> You seem to look for a model where each unit compilation ands into a file that
> contains, roughly, the following information (with overlaps):
> - the specification, "digested"
> - the contents of the .ali file
> - unit dependencies
> - time stamps to check need of recompilations
> - the compiled code (the .o object file itself).
>
> This model exists and works fine (esp., less files and a way faster
> compilation!), it is the one of Turbo Pascal's .TPU files (~1988...) and its
> descendants (TPW, Delphi). You just have to take a close look at it. No need
> to reinvent anything...

I'd forgotted about this. Do you have any pointers?

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Stefan Bellon]

Gautier wrote:

> - time stamps to check need of recompilations

I've always wondered about the focussing on time stamps. I think the way
to do it would be to calculate a hash sum (md5, sha1, ...) on the token
stream without comments. This way you wouldn't have to recompile if you
do layout and commentary changes, and even if you touch the file, you
don't inadvertently trigger a recompilation.

In fact, this is the idea of the "compilercache" project for C and C++:
It intercepts calls to gcc/g++, builds a hash value on the
concatenation of the command line (minus a few switches that do not
influence code generation) and the preprocessed source and then stores
the resulting object file in the cache with the name of the hash value.
If the same hash value is to be compiled again, it is fetched from the
cache and a lot of compilation time is saved.

-- 
Stefan Bellon

Re: Implementing an Ada compiler and libraries.

[Jean-Pierre Rosen]

Stefan Bellon a �crit :
> Gautier wrote:
> 
>> - time stamps to check need of recompilations
> 
> I've always wondered about the focussing on time stamps. I think the way
> to do it would be to calculate a hash sum (md5, sha1, ...) on the token
> stream without comments. This way you wouldn't have to recompile if you
> do layout and commentary changes, and even if you touch the file, you
> don't inadvertently trigger a recompilation.
> 
Gnatmake can do that (see option -m)

-- 
---------------------------------------------------------
            J-P. Rosen (rosen@adalog.fr)
Visit Adalog's web site at http://www.adalog.fr

Re: Implementing an Ada compiler and libraries.

[Ludovic Brenta]

Jean-Pierre Rosen <rosen@adalog.fr> writes:

> Stefan Bellon a écrit :
>> Gautier wrote:
>>
>>> - time stamps to check need of recompilations
>>
>> I've always wondered about the focussing on time stamps. I think the way
>> to do it would be to calculate a hash sum (md5, sha1, ...) on the token
>> stream without comments. This way you wouldn't have to recompile if you
>> do layout and commentary changes, and even if you touch the file, you
>> don't inadvertently trigger a recompilation.
>>
> Gnatmake can do that (see option -m)

Ah yes, I forgot... I always have -k -m in my project files... quite
handy when recompiling GPS :)

-- 
Ludovic Brenta.

Re: Implementing an Ada compiler and libraries.

[Stefan Bellon]

Ludovic Brenta wrote:

> Ah yes, I forgot... I always have -k -m in my project files... quite
> handy when recompiling GPS :)

Ah, ok, forgot about -m. Apart form debugging information being out of
sync with the actual line numbers, is it otherwise always safe to use
-m?

-- 
Stefan Bellon

Re: Implementing an Ada compiler and libraries.

[Ludovic Brenta]

Stefan Bellon <sbellon@sbellon.de> writes:
> Gautier wrote:
>
>> - time stamps to check need of recompilations
>
> I've always wondered about the focussing on time stamps. I think the way
> to do it would be to calculate a hash sum (md5, sha1, ...) on the token
> stream without comments. This way you wouldn't have to recompile if you
> do layout and commentary changes, and even if you touch the file, you
> don't inadvertently trigger a recompilation.

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.

-- 
Ludovic Brenta.

Re: Implementing an Ada compiler and libraries.

[Stefan Bellon]

Ludovic Brenta wrote:

> Stefan Bellon <sbellon@sbellon.de> writes:
> > Gautier wrote:
> >
> >> - time stamps to check need of recompilations
> >
> > I've always wondered about the focussing on time stamps. I think
> > the way to do it would be to calculate a hash sum (md5, sha1, ...)
> > on the token stream without comments. This way you wouldn't have to
> > recompile if you do layout and commentary changes, and even if you
> > touch the file, you don't inadvertently trigger a recompilation.
> 
> 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.

But timestamps are considered as well. If you touch a file without
modifying it otherwise, it triggers a recompilation.

-- 
Stefan Bellon

Re: Implementing an Ada compiler and libraries.

[Ludovic Brenta]

Stefan Bellon writes:
> Ludovic Brenta wrote:
>
>> Stefan Bellon writes:
>> > Gautier wrote:
>> >
>> >> - time stamps to check need of recompilations
>> >
>> > I've always wondered about the focussing on time stamps. I think
>> > the way to do it would be to calculate a hash sum (md5, sha1, ...)
>> > on the token stream without comments. This way you wouldn't have to
>> > recompile if you do layout and commentary changes, and even if you
>> > touch the file, you don't inadvertently trigger a recompilation.
>> 
>> 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.
>
> But timestamps are considered as well. If you touch a file without
> modifying it otherwise, it triggers a recompilation.

Not in my experience.  Changing the timestamp causes a recalculation
of the checksum, that's all.  Even after adding whitespace or
pretty-printing the file, there is no recompilation.

-- 
Ludovic Brenta.

Re: Implementing an Ada compiler and libraries.

[Stefan Bellon]

Ludovic Brenta wrote:

> Stefan Bellon writes:

> > But timestamps are considered as well. If you touch a file without
> > modifying it otherwise, it triggers a recompilation.
> 
> Not in my experience.  Changing the timestamp causes a recalculation
> of the checksum, that's all.  Even after adding whitespace or
> pretty-printing the file, there is no recompilation.

Hmmmm:

bellonsn@cube$ gnatmake foo.adb
gnatmake: "foo" up to date.
bellonsn@cube$ touch foo.adb    
bellonsn@cube$ gnatmake foo.adb
gcc -c foo.adb
gnatbind -x foo.ali
gnatlink foo.ali


-- 
Stefan Bellon

Re: Implementing an Ada compiler and libraries.

[Jacob Sparre Andersen]

Stefan Bellon <sbellon@sbellon.de> writes:
> Ludovic Brenta wrote:
>> Stefan Bellon writes:

>> > But timestamps are considered as well. If you touch a file
>> > without modifying it otherwise, it triggers a recompilation.
>> 
>> Not in my experience.  Changing the timestamp causes a
>> recalculation of the checksum, that's all.  Even after adding
>> whitespace or pretty-printing the file, there is no recompilation.
>
> Hmmmm:
>
> bellonsn@cube$ gnatmake foo.adb
> gnatmake: "foo" up to date.
> bellonsn@cube$ touch foo.adb    
> bellonsn@cube$ gnatmake foo.adb
> gcc -c foo.adb
> gnatbind -x foo.ali
> gnatlink foo.ali

I suspect that the difference in your experience is that Ludovic keeps
the "-m" flag among his default flags for "gnatmake".

Try:

   gnatmake -m foo.adb
   touch       foo.adb
   gnatmake -m foo.adb

Greetings,

Jacob
-- 
"There are two ways of constructing a software design. One way is to
 make it so simple that there are obviously no deficiencies. And the
 other way is to make it so complicated that there are no obvious
 deficiencies."                                    -- C. A. R. Hoare

Re: Implementing an Ada compiler and libraries.

[Simon Wright]

Stefan Bellon <sbellon@sbellon.de> writes:

> Ludovic Brenta wrote:
>
>> Stefan Bellon writes:
>
>> > But timestamps are considered as well. If you touch a file without
>> > modifying it otherwise, it triggers a recompilation.
>> 
>> Not in my experience.  Changing the timestamp causes a recalculation
>> of the checksum, that's all.  Even after adding whitespace or
>> pretty-printing the file, there is no recompilation.
>
> Hmmmm:
>
> bellonsn@cube$ gnatmake foo.adb
> gnatmake: "foo" up to date.
> bellonsn@cube$ touch foo.adb    
> bellonsn@cube$ gnatmake foo.adb
> gcc -c foo.adb
> gnatbind -x foo.ali
> gnatlink foo.ali

This is the gnatmake -m flag:
   if the timestamp hasn't changed: do nothing
   elif the semantic content of the file hasn't changed: do nothing
   else: recompile

Re: Implementing an Ada compiler and libraries.

[Pascal Obry]

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.

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

Re: Implementing an Ada compiler and libraries.

[Ludovic Brenta]

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.

Re: Implementing an Ada compiler and libraries.

[Pascal Obry]

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

Re: Implementing an Ada compiler and libraries.

[Pascal Obry]

Stefan Bellon a �crit :
> Gautier wrote:
> 
>> - time stamps to check need of recompilations
> 
> I've always wondered about the focussing on time stamps. I think the way
> to do it would be to calculate a hash sum (md5, sha1, ...) on the token
> stream without comments. This way you wouldn't have to recompile if you
> do layout and commentary changes, and even if you touch the file, you
> don't inadvertently trigger a recompilation.

That's exactly what GNAT does BTW.

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

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 10, 4:34 pm, Stefan Bellon <sbel...@sbellon.de> wrote:
> Gautier wrote:
> > - time stamps to check need of recompilations
>
> I've always wondered about the focussing on time stamps. I think the way
> to do it would be to calculate a hash sum (md5, sha1, ...) on the token
> stream without comments. This way you wouldn't have to recompile if you
> do layout and commentary changes, and even if you touch the file, you
> don't inadvertently trigger a recompilation.
>
> In fact, this is the idea of the "compilercache" project for C and C++:
> It intercepts calls to gcc/g++, builds a hash value on the
> concatenation of the command line (minus a few switches that do not
> influence code generation) and the preprocessed source and then stores
> the resulting object file in the cache with the name of the hash value.
> If the same hash value is to be compiled again, it is fetched from the
> cache and a lot of compilation time is saved.

Another really good idea ;D

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Pascal Obry]

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 :)

That's something I wanted to start at some point, and I think now that I
won't have time to start this anytime soon :)

Just thinking out loud :)

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

Re: Implementing an Ada compiler and libraries.

[Lucretia]

On May 10, 6:34 pm, Pascal Obry <pas...@obry.net> 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 :)
>
> That's something I wanted to start at some point, and I think now that I
> won't have time to start this anytime soon :)
>
> Just thinking out loud :)

No, this is something I'm not that interested in doing as I do want to
play with other parts of the compiler as well.

Thanks,
Luke.

Re: Implementing an Ada compiler and libraries.

[Duncan Sands]

> 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.  So you can put Ada in and
get C out.  Unfortunately the C is not always compilable.
For example, if you compile an instance of GNAT.Table with
Natural as the index type, in the C you end up with the
declaration of a very big C array, corresponding to
Big_Table_Type.  This array is rejected by the gcc C
compiler as too big.  Still, it works most of the time.

Ciao,

Duncan.

Re: Implementing an Ada compiler and libraries.

[Pascal Obry]

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.

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

Re: Implementing an Ada compiler and libraries.

[Duncan Sands]

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.

Re: Implementing an Ada compiler and libraries.

[Ludovic Brenta]

Duncan Sands writes:
> 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.

In the mean time, do you have a public repository?  Do you welcome
contributions?

-- 
Ludovic Brenta.

Re: Implementing an Ada compiler and libraries.

[Pascal Obry]

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.

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

Re: Implementing an Ada compiler and libraries.

[Georg Bauhaus]

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.