Atacc – Ada To Ansi C Compiler
This project aims to create an Ada compiler with a back-end that consists of an Ansi C compiler. I.e, the Ada compiler will produce Ansi C code which then in turn has to be run through a C compiler and linker to produce the final executable.
The project started as an idea to provide the possibility to use Ada in small embedded systems where no Ada compiler is available. Almost all embedded environments are however equipped with a C compiler, thus making C suitable as an intermediate language. It may be argued that this usage delegates C to what it really is; a nearly machine independent assembler :).
The project itself is hosted at SourceForge.net, more precisely here.
It is a gargantuan task to create an Ada compiler, and we are very aware of that. The language is huge and contains many features. Also, the very spirit of the Ada language is to detect software errors as early as possible, thus making the compiler construction more complicated than for most other programming languages (except, maybe, for C++ :).
The availability of standards documentation on the Ada language is quite good. Versions of the international standard (ISO/IEC 8652:1995): “Information Technology – Programming Languages – Ada” could be found here. Further, since the standard has been subject to usage, there exists interpretation notes, guide lines and amendments which are handled by the Ada Conformity Assessment Authority.
In terms of free software compilers, there already exist an
gcc, which Ada
front end is more commonly known as 'gnat', although the command
line invocation is still '
The ultimate scope of the project is to implement the core of the Ada language (i.e. Sections 1 through 13, Annex A,B and J in Ref ). This will have to be broken down into manageable pieces after we leave the planning stage.
The goal is also to make it easy to port
atacc to a new Ansi
C environment. This may seem as a contradiction since Ansi C is
after all Ansi C and it is standardized. Keep in mind though that
certain things aren't covered by the standard, such as e.g. the
size of an 'int' or a pointer. The
atacc compiler will thus
need a parameterized description of the target environment. Depending
on the needs of the Ada application, a small run-time environment
must also be provided (timer, heap allocation primitives etc).
The project time line is yet to be defined. As of now we are in the planning and prototyping stage. When our compiler is capable of compiling the Ada variant of 'Hello, World'!, we will make our first alpha release. This paragraph will be updated as soon as we know more.
atacc compiler itself will be written in Ada and
be used to compile it. Eventually
atacc will be self hosting, but
this is in the far future.
For the scanner and parser parts of the
atacc compiler two
free Ada tools will be used; Aflex and Ayacc. The former has the
capabilities of flex and the latter the capabilities of bison.
Both tools are written in Ada and generates Ada code instead of C
code. These tool are maintained by John
Since we are targeting small constrained environments we plan to keep the generated code size at a minimum by performing dead code removal. Dead code identification could be performed by compiling the whole application in a single sweep, which is one of the 'new' ideas we want to try out. This is possible to do for an Ada program (in contrast to e.g. a C application where all separate program components are not identifiable via the source code). Compiling the total code for an entire program at once may seem a waste of time, but remember that we target small stand-alone environments – not global distributed air traffic control systems. By performing this, we can deduce all code reachable from the main procedure. Unfortunately, this will not be sufficient for Ada library level packages that contains tasks so further investigation is necessary.
There have been (are?) commercially available Ada compilers that emit C or C++ code. Their intent, though, have been to produce readable and maintainable code. We don't have this intention. OTOH, we don't plan to obfuscate the code either! The emitted C code will be decorated with source file and line references to the original Ada source code, thus making basic level debugging possible. However, one will have to use 'mangled' names for external program entities and overloaded procedures and functions since name spaces and overloading doesn't exist in C.
Who are the initiators of this project?
We are two seasoned software developers, nicknamed seasword and czgnp. We have both been developing software in Ada since the mid-80's, so we are no green-horns on this matter.
Why is is called
It is a nice abbreviation. It could either mean 'Ada To Ansi C Compiler' or (self-referentially!) 'Atacc Translates Ada Code to C'. The military background of Ada has nothing to do with it.
Why do this when
gcc (gnat) exists?
Because porting the
gcc back end is no easy task. If a
port exists for a particular target, fine. By all means use it.
If not, you may consider to port the
gcc back end, although keep
in mind that it is not particularly well suited for 'small
architectures' with limited capabilities in terms of registers
and word size.
Will it ever be ready?
No, maybe not. But we do this for the fun of it. Part of the idea was to give me (seasword) something intellectually challenging to do during my parental leave (I'm home taking care of our twin daughters for nine months and, yes, they occasionally sleep at the same time).
Why is the background of this web page so ugly?
Beauty is in the eye of the beholder. It looks this way because it reminds me (seasword again) of my very first copy of the Ada Reference Manual! It was green because Ada was anonymously known as 'the Green Language' during the competition of which language should be adopted by the US Department of Defence in the late 70's and early 80's.
|||ISO/IEC 8652:1995(E): “Information Technology – Programming Languages – Ada”||COR. 1:2000|
This page was last updated 2004/05/07 and the project is hosted at