Ada to C translator for small microcontrollers

[Tomi Saarnio]

Hi all,

As there exists at least one free decent C cross-compiler for smaller
8-bit and 16-bit architectures (Pic, Avr, 8051 etc.), but none Ada
compiler that I know of, I was wondering whether there is a demand for
an Ada to C translator, that would implement some sort of Ada subset
and output corresponding ANSI C source code. I am not a compiler or
Ada expert, so I cannot really estimate the effort how hard this would
be.

As far as I can see the problem, the first thing is to identify a
suitable subset(s) to be implemented, and then to come up with the
corresponding C source idioms.

Any comments on this subject?

Br,
Kalvin.

[Rego, P.]

> As there exists at least one free decent C cross-compiler for smaller
> 8-bit and 16-bit architectures (Pic, Avr, 8051 etc.), but none Ada
> compiler that I know of

For AVR, now you know...
http://libre.adacore.com/libre/download2?config=avr-elf-windows&version=2011

Actually you also have AVR-Ada. For RTOSes, RTEMS and MarteOS have support for Ada.

Regards.

[Niklas Holsti]

On 12-03-26 15:48 , Tomi Saarnio wrote:
> Hi all,
>
> As there exists at least one free decent C cross-compiler for smaller
> 8-bit and 16-bit architectures (Pic, Avr, 8051 etc.), but none Ada
> compiler that I know of,

A partial port of GNAT for the AVR exists:
sourceforge.net/apps/mediawiki/avr-ada/.

> I was wondering whether there is a demand for
> an Ada to C translator, that would implement some sort of Ada subset
> and output corresponding ANSI C source code.

SofCheck (www.sofcheck.com) provides such an Ada (95) compiler, a
version of their AdaMagic front-end.

> I am not a compiler or
> Ada expert, so I cannot really estimate the effort how hard this would
> be.

Quite large, I think, unless you take a very small subset. But one would
really like the subset to provide most of the compile-time advantages of
Ada: packages, user-defined types, type attributes, generics.

I think the realistic approach for an open-source implementation would
be to take the existing GNAT front-end and try to generate C code from
the intermediate representation, either the gcc IR or the llvm IR.

> As far as I can see the problem, the first thing is to identify a
> suitable subset(s) to be implemented, and then to come up with the
> corresponding C source idioms.

In the GNAT-based approach that I suggest above, the bottleneck is in
the IR-to-C translator. I don't know much about the gcc or llvm IRs, but
I would expect the subset to be defined by the limitations of whatever
IR-to-C translator is created, and it may not be easy to define the
corresponding subset on the Ada level. In any case, it seems simpler to
start building an IR-to-C translator and accept whatever limitations it
turns out to have.

There are some "Ada to C/C++" translators that work on the pure
source-to-source "idiom" basis, but I believe they are intended to help
porting Ada projects from Ada to C or C++, and probably require manual
assistance to finish the translation. The SofCheck tool is a fully
automatic, real compiler that generates complete and finished C source.

--
Niklas Holsti
Tidorum Ltd
niklas holsti tidorum fi
. @ .

[georg bauhaus]

Tomi Saarnio <kalvi...@gmail.com> wrote:
> Hi all,
>
> As there exists at least one free decent C cross-compiler for smaller
> 8-bit and 16-bit architectures (Pic, Avr, 8051 etc.), but none Ada
> compiler that I know of, I was wondering whether there is a demand for
> an Ada to C translator,

There is supply, SofCheck's Ada compiler
Outputs C (and, more recently, C++ if memory serves). Whether or not the
runtime is fully
Supported on each of the named platforms,
I don't know.

[Ludovic Brenta]

Niklas Holsti wrote on comp.lang.ada:

> I think the realistic approach for an open-source implementation would
> be to take the existing GNAT front-end and try to generate C code from
> the intermediate representation, either the gcc IR or the llvm IR.

That's a good thought. LLVM already comes with a C backend (i.e. a code
generator that emits C rather than assembly). I wonder how easy it would
be to configure a toolchain based on the GNAT Ada front-end and this C
back-end, bound together by LLVM's DragonEgg GCC plug-in.

--
Ludovic Brenta.
The thought leader thinks differently.

[Simon Wright]

Ludovic Brenta <lud...@ludovic-brenta.org> writes:

> Niklas Holsti wrote on comp.lang.ada:
>> I think the realistic approach for an open-source implementation would
>> be to take the existing GNAT front-end and try to generate C code from
>> the intermediate representation, either the gcc IR or the llvm IR.
>
> That's a good thought. LLVM already comes with a C backend (i.e. a code
> generator that emits C rather than assembly). I wonder how easy it would
> be to configure a toolchain based on the GNAT Ada front-end and this C
> back-end, bound together by LLVM's DragonEgg GCC plug-in.

Hmm, from [1], "The C backend has numerous problems and is not being
actively maintained. Depending on it for anything serious is not
advised."

[1] http://llvm.org/docs/ReleaseNotes.html#knownproblems

[an...@att.net]

There are some projects that may work.

But the power of GNU GCC and GNAT is that you can add code for any
processor you want. There are some infomation on the web that will
help in adding a new target processor.

Another way is to re-write the "Back_End.adb, trans.c, etc" files for GNAT.
Between 1994 and 1997 for fun I rewote those files in Ada. Actually the
code generated was far superior to GCC generated code. Plus, in this
version you can easy alter the format of the object code to fit the linker of
your choice. So, your not tied to GNU ld to produce executable binaries.

[kalvi...@gmail.com]

As Niklas and Georg pointed well out, SofCheck (www.sofcheck.com) provides such an Ada (95) compiler, which will emit corresponding C source as its output. This may not be freely available, though?.

maanantaina 26. maaliskuuta 2012 22.16.01 UTC+3 an...@att.net kirjoitti:
> But the power of GNU GCC and GNAT is that you can add code for any
> processor you want. There are some infomation on the web that will
> help in adding a new target processor.

Maybe this might be the easiest path to follow. Although GNAT implements full Ada language, it might be able to define smaller subset that the front-end and/or back-end will support for given target C language.

There is also GPL Ada to C/C++ translator, but I have not looked at this yet:
http://adatoccpptranslator.free.fr/
It seems that this tool is mainly aimed to aid the process of translating existing Ada source code to C/C++. However, the GPL'd source code is available.

Br,
Kalvin

[an...@att.net]

Full language translators are mostly used to move a project away from
one language to another more accessable language. So, why use Ada in
the first place.

Now, if you add the code for a new processor to GNU GCC and GNAT then
most languages are avialable for use. Not just Ada and C/C++, but you
can also have Fortran, Java, and etc.

Plus, before using language translators you should understand that most
only aid in the translating a subset of the full language. Like "C2Ada"
which partially converted C code to Ada.

And some translators are limited. Like a number of years ago when Adacore
drop the Glade package for Annex E (Distributed Systems) for polyorb I
wrote a pure Ada "RPC_Generator" program. This program convert the "Remote
Procedure Call" Language (a C like language) to Ada. Allowing Ada to use
the full functions of a RPC package. The program could be used with Ada
only design or injunction with other "RPCGEN" programs for other languages
to allow a more multiple language style of distributed system.


RPC_Generator -- "Remote Procedure Call" Language to Ada Language.

This utility creates both the client and server packages for the RPC in
Ada. In either a single standard Ada file package structure or the
body/specification files set used by GNAT.

[kalvi...@gmail.com]

tiistaina 27. maaliskuuta 2012 20.22.07 UTC+3 an...@att.net kirjoitti:
> Full language translators are mostly used to move a project away from
> one language to another more accessable language. So, why use Ada in
> the first place.

This is a very valid question. How large a software project needs to be in order to benefit from implementing it in Ada? Is it only a one person prjoect, two person project or project involving a small team. Why bother with Ada as we already have (free) C compiler avaiable.

If the project is a small one, and you don't have to share the code with others, C is just fine. But as soon as the project size get bigger (than a few thousand lines of code, or project contains more than ten source modules) and you need to collaborate with others, my guess is that Ada might be a right tool for the job. Of course, these estimates are pulled top of my head, but are based on a personal experience anyway.

> Now, if you add the code for a new processor to GNU GCC and GNAT then
> most languages are avialable for use. Not just Ada and C/C++, but you
> can also have Fortran, Java, and etc.

I do not know the internals of GCC, but I am in impression that GCC is optimized for 32/64-bit architectures, and 8/16-bit architectures are hardly supported. I do know, that some Hitachi (and maybe AVR) 8/16-bit controllers are supported, though.

> Plus, before using language translators you should understand that most
> only aid in the translating a subset of the full language. Like "C2Ada"
> which partially converted C code to Ada.

I do realize, that it might be almost impossible to produce efficient C source translation for corresponding Ada, compared to corresponding assembly.

- Kalvin

[KK6GM]

On Mar 27, 1:13 pm, kalvin.n...@gmail.com wrote:
> tiistaina 27. maaliskuuta 2012 20.22.07 UTC+3 an...@att.net kirjoitti:
>
> > Full language translators are mostly used to move a project away from
> > one language to another more accessable language. So, why use Ada in
> > the first place.
>
> This is a very valid question. How large a software project needs to be in order to benefit from implementing it in Ada? Is it only a one person prjoect, two person project or project involving a small team. Why bother with Ada as we already have (free) C compiler avaiable.

Even the smallest microcontroller projects could greatly benefit from
Ada's realtime and concurrency features.

[Niklas Holsti]

On 12-03-27 23:13 , kalvi...@gmail.com wrote:
> tiistaina 27. maaliskuuta 2012 20.22.07 UTC+3 an...@att.net
> kirjoitti:
>> Full language translators are mostly used to move a project away
>> from one language to another more accessable language. So, why use
>> Ada in the first place.

Because it is so much better than C, of course :-)

I know of more than one project that used Ada as a high-level design and
specification language, and then implemented the design in some
lower-level language (in one case, an assembly language). In some cases,
the Ada code was complete and runnable and could be used as a test
oracle for the lower-level implementation.

> This is a very valid question. How large a software project needs to
> be in order to benefit from implementing it in Ada?

IMO, basically there is no lower limit, with the possible exception of
the null program.

> Is it only a one
> person prjoect, two person project or project involving a small team.
> Why bother with Ada as we already have (free) C compiler avaiable.

We also have a free Ada compiler available, for many platforms -- but
not for many small processors, I grant.

But many projects developing in C for microcontrollers use non-free,
commercial compilers, IDEs, and other expensive tools (in-circuit
debuggers, etc.) The question IMO is not whether there is a benefit from
using the Ada language; the question is if the benefit can be
convincingly quantified in money and schedule terms.

> If the project is a small one, and you don't have to share the code
> with others, C is just fine.

No! C is a like a Model-T Ford that for some strange reason is allowed
on modern roads. You can survive and not be too uncomfortable on short
trips, but you should really consider changing to a better car.

IMO the only reasons that would make me use C instead of Ada are:
- No Ada compiler available within my budget
- Need to use large C libraries/APIs for which no Ada binding exists.

> I do realize, that it might be almost impossible to produce efficient
> C source translation for corresponding Ada, compared to corresponding
> assembly.

It is true that C does not provide all the features of assembly
language, for all that it is called a "portable assembler". But I'm not
sure that this would be a large handicap for an Ada compiler that uses C
as an intermediate language (like the SofCheck one).

The C level could be a performance bottleneck if one wanted to support
wider numbers in Ada than the C compiler supports -- for example, an Ada
64-bit Long_Integer with a C compiler that supports only 32-bit integers
-- but this is a marginal effect, I think.

[KK6GM]

On Mar 28, 9:36 am, Niklas Holsti <niklas.hol...@tidorum.invalid>
wrote:

> On 12-03-27 23:13 , kalvin.n...@gmail.com wrote:
>
> > tiistaina 27. maaliskuuta 2012 20.22.07 UTC+3 an...@att.net
> > kirjoitti:
> >> Full language translators are mostly used to move a project away
> >> from one language to another more accessable language. So, why use
> >> Ada in the first place.
>
> Because it is so much better than C, of course :-)

That is the crux of the matter.

> > Is it only a one
> > person prjoect, two person project or project involving a small team.
> > Why bother with Ada as we already have (free) C compiler avaiable.
>
> We also have a free Ada compiler available, for many platforms -- but
> not for many small processors, I grant.
>
> But many projects developing in C for microcontrollers use non-free,
> commercial compilers, IDEs, and other expensive tools (in-circuit
> debuggers, etc.) The question IMO is not whether there is a benefit from
> using the Ada language; the question is if the benefit can be
> convincingly quantified in money and schedule terms.

The free vs not-free issue should not be discounted. People who would
be open to trying Ada on small platforms need to be able to get it
into their hands easily. Free now to help make the sale, pay later
for support. It would be fabulous, IMO, if the SofCheck Ada->C
product would be made available in some free form. I know I would
start using it immediately, and start trying to convert my
organization to Ada. There is so much sub $5-$10 hardware now that
could run Ada code very effectively, but continues to be programmed in
C/C++ in part because of the intertia of the free or very low cost
compilers available.

> > If the project is a small one, and you don't have to share the code
> > with others, C is just fine.
>
> No! C is a like a Model-T Ford that for some strange reason is allowed
> on modern roads. You can survive and not be too uncomfortable on short
> trips, but you should really consider changing to a better car.

"The 1980s will probably be remembered as the decade in which
programmers took a gigantic step backwards by switching from secure
Pascal-like languages to insecure C-like languages. I have no rational
explanation for this trend." -Per Brinch Hansen

I can only agree wholeheartedly.

[Georg Bauhaus]

On 28.03.12 18:36, Niklas Holsti wrote:
> On 12-03-27 23:13 , kalvi...@gmail.com wrote:

>> This is a very valid question. How large a software project needs to
>> be in order to benefit from implementing it in Ada?
>
> IMO, basically there is no lower limit, with the possible exception of the null program.

There are few programming languages that let the programmer
say that he wishes the null program to really be the null
program. Ada has null, Python has pass. In other languages,
the no-op needs to be either emulated or is implicit.

I do not know (yet) why a no-op in the language is a must
in a theory-friendly programming language, I have seen that
it is. Ada has it, in any case.

[phil.c...@lineone.net]

On Wednesday, March 28, 2012 10:03:14 PM UTC+1, Georg Bauhaus wrote:
> I do not know (yet) why a no-op in the language is a must
> in a theory-friendly programming language, I have seen that
> it is. Ada has it, in any case.

At a practical level, without null, using rules to reason about programs can become tedious. For example, null statements allow us to write the rule

if C
then
P
else
null;
end if;
=
if C
then
P
end if;

where C is a boolean expression and P is any program statement.

That is useful because no other rules then need to deal with an implicit else null branch. Without null statements and the above rule, we would then need four versions of the following rule, for all combinations of omitting the else branch:

if C
then
if C
then
P
else
Q
else
R
end if;
=
if C
then
P
else
R
end if;

At a more abstract level, a null statement may be needed so that sequential composition has an identity to appeal to some other theoretical result.

[kalvi...@gmail.com]

keskiviikkona 28. maaliskuuta 2012 19.36.37 UTC+3 Niklas Holsti kirjoitti:
> It is true that C does not provide all the features of assembly
> language, for all that it is called a "portable assembler". But I'm not
> sure that this would be a large handicap for an Ada compiler that uses C
> as an intermediate language (like the SofCheck one).
>
> The C level could be a performance bottleneck if one wanted to support
> wider numbers in Ada than the C compiler supports -- for example, an Ada
> 64-bit Long_Integer with a C compiler that supports only 32-bit integers
> -- but this is a marginal effect, I think.

Yes, the translator should be implemented so, that it would be compatible with the target C ie. no support for 64-bit integers etc. if the target C compiler doesn't support that.

Nested procedures are also a bit tricy to implement in C, as the local stack frame needs to made visible to the inner procedure. This is doable with the struct of pointers passed as parameters for the "inner procedure", I guess. It is up to target C compiler optimization how much penalty there will be.

Br,
Kalvin

[Rugxulo]

Hi,

On Mar 31, 10:46 am, kalvin.n...@gmail.com wrote:
> keskiviikkona 28. maaliskuuta 2012 19.36.37 UTC+3 Niklas Holsti kirjoitti:
>
> > It is true that C does not provide all the features of assembly
> > language, for all that it is called a "portable assembler". But I'm not
> > sure that this would be a large handicap for an Ada compiler that uses C
> > as an intermediate language (like the SofCheck one).
>
> > The C level could be a performance bottleneck if one wanted to support
> > wider numbers in Ada than the C compiler supports -- for example, an Ada
> > 64-bit Long_Integer with a C compiler that supports only 32-bit integers
> > -- but this is a marginal effect, I think.
>
> Yes, the translator should be implemented so, that it would be compatible with the target C ie. no
> support for 64-bit integers etc. if the target C compiler doesn't support that.

If you stick to standard C, that shouldn't be a problem. C99 supports
"long long" (64-bit), and even GCC has supported it for longer than
that. Besides, it's probably? fairly trivial to hack up similar
support with only 32-bit ints. (I know there was a small section an
AMD manual which showed the basic arithmetic in assembly for such
operations.)

> Nested procedures are also a bit tricy to implement in C, as the local stack frame needs to made
> visible to the inner procedure. This is doable with the struct of pointers passed as parameters for
> the "inner procedure", I guess. It is up to target C compiler optimization how much penalty there will be.

GCC supports nested procedures. Something like p2c (Pascal to C) had
some weird workaround to support it in generic C, too. I imagine that
using p2c is preferable to writing from scratch in C, though I know
Pascal isn't quite Ada (but still less painful, no?).

Anyways, it may be easier to just use an interpreter, something like
old NYU Ada/Ed, which was written in C, but I haven't ever looked
close enough nor tried to recompile it. In other words, I don't know
how portable that C code is, it was (AFAIK) 16-bit for an old Intel C
compiler. Perhaps someone in this newsgroup has recompiled it before,
who knows. I realize that's not native speed, but it's probably not
too bad. It certainly is better than nothing.

[kalvi...@gmail.com]

P2C (Pascal-to-C) might also be a viable starting point for the translator. However, in order to take advantage of mature GNAT compiler front-end, the GCC looks tempting path. GCC seems to be quite complicated beast, but maybe it can be tamed for the purpose.

[Niklas Holsti]

On 12-03-31 22:52 , Rugxulo wrote:

> Anyways, it may be easier to just use an interpreter, something like
> old NYU Ada/Ed, which was written in C, but I haven't ever looked
> close enough nor tried to recompile it. In other words, I don't know
> how portable that C code is, it was (AFAIK) 16-bit for an old Intel C
> compiler. Perhaps someone in this newsgroup has recompiled it before,
> who knows.

Wasn't Ada/Ed implemented in the SETL very-high-level-language? Perhaps
SETL is implemented in C, however. There is a GNU SETL at http://setl.org/.

> I realize that's not native speed, but it's probably not
> too bad. It certainly is better than nothing.

IIRC, Ada/Ed was described as quite slow. Of course it should be much
faster on modern machines, but it is Ada 83...

[BrianG]

If the target has a GCC port, it is not that difficult to create a
cross-compiler from GNAT, using No_Run_Time (i.e. no tasking, etc; you
have to build your own binding to the target libraries or registers). I
did this once for a uC board I have (there was an in-work Ada project at
the time, but I only used their instructions for building the
cross-compiler). I have no compiler or GCC experience, and was able to
get it working - not sure if I could, or want to, do it again.

I wonder if it's possible to create a C-target back end? :-)

--
---
BrianG
000
@[Gee, Mail!]
.com

[J-P. Rosen]

Le 02/04/2012 23:46, Niklas Holsti a écrit :
> On 12-03-31 22:52 , Rugxulo wrote:
> Wasn't Ada/Ed implemented in the SETL very-high-level-language? Perhaps
> SETL is implemented in C, however. There is a GNU SETL at http://setl.org/.

There were two versions of it. The first one was in SETL, the second one
was a translation to C.

> IIRC, Ada/Ed was described as quite slow. Of course it should be much
> faster on modern machines, but it is Ada 83...
>

Especially version 1. That's why it was moved to C. (SETL is an
interpreted language, so we had an interpreter written in an interpreted
language...)

--
J-P. Rosen
Adalog
2 rue du Docteur Lombard, 92441 Issy-les-Moulineaux CEDEX
Tel: +33 1 45 29 21 52, Fax: +33 1 45 29 25 00
http://www.adalog.fr

[Georg Bauhaus]

On 03.04.12 04:08, BrianG wrote:

> I wonder if it's possible to create a C-target back end? :-)

Won't it be a lot easier, and more flexible for industry,
if there is some commonly accepted intermediate language
for µControllers that supports C well, but also supports
other languages?
the intermediate language then removes the need (and cost!)
for implementers to implement the complicated C stuff correctly.

OTOH, the makers of C compilers will not be happy, I guess,
if there is a solution that makes switching languages easy.
Oh well, I guess the makers of Ada compilers will feel the
same.

[kalvi...@gmail.com]

I found this paper "No Assembly Required: Compiling Standard ML to C" which presents some ideas and experience in using the C as compiler target language.

http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.70.154&rep=rep1&type=pdf

The Standard ML differs quite a lot from C, and "The generated code achieves an execution speed that is about a factor of two slower than a native code compiler". However, as Ada is closer to C, the resulting overhead is supposed be less. Also, implementing only a carefully selected subset of Ada language might help in creating better translation to target C language.

[Georg Bauhaus]

ATS, which adds linear types and proofs to ML (not that I really
know what linear types are, except that they are not ref types
like those for scalars in ML), uses C a a target language too,
and is about as fast, or faster.

Eiffel also generates C; there is a GPL edition of
the compiler. Don't know whether it is suitable
for 湣ontrollers, though.

[Marco]

> for µControllers, though.

SmartEiffel
http://en.wikipedia.org/wiki/SmartEiffel
http://smarteiffel.loria.fr/

Could be used for ideas on creating a subset Ada to C "compiler".

[kalvi...@gmail.com]

lauantai, 2. kesäkuuta 2012 18.27.06 UTC+3 Marco kirjoitti:
> On Monday, May 21, 2012 5:27:07 AM UTC-7, Georg Bauhaus wrote:

> > On 21.05.12 12:35, kalvin wrote:
>
> > Eiffel also generates C; there is a GPL edition of
> > the compiler. Don't know whether it is suitable
> > for µControllers, though.
>
> SmartEiffel
> http://en.wikipedia.org/wiki/SmartEiffel
> http://smarteiffel.loria.fr/
>
> Could be used for ideas on creating a subset Ada to C "compiler".

Good pointer, thanks!

Actually, there have been quite a few good suggestions on how to create an translator.

As Niklas Holsti suggested sometime above, the translation from GNAT IR to C might be the easiest way. I thought about this, and as there exists a GNAT Ada Pretty Printer, and if I have understood it correctly, it uses GNAT IR for recreating the source code. This might be the easiest way to create the translator, as rewriting the source code formatting rules to produce C source instead. Any comments on this possible approach?

Br, Kalvin.

[Brian Drummond]

On Tue, 05 Jun 2012 02:18:11 -0700, kalvin.news wrote:

> As Niklas Holsti suggested sometime above, the translation from GNAT IR
> to C might be the easiest way. I thought about this, and as there exists
> a GNAT Ada Pretty Printer, and if I have understood it correctly, it
> uses GNAT IR for recreating the source code. This might be the easiest
> way to create the translator, as rewriting the source code formatting
> rules to produce C source instead. Any comments on this possible
> approach?

For the C back-end, it might be worth looking at an old version of f2c,
(from before it became g77 or gfortran) to see how some other-language
constructs were translated into c. It's probably not pretty, but I
remember it as being a fairly small program.

- Brian

[J-P. Rosen]

Le 05/06/2012 14:17, Brian Drummond a écrit :
> For the C back-end, it might be worth looking at an old version of f2c,
> (from before it became g77 or gfortran) to see how some other-language
> constructs were translated into c. It's probably not pretty, but I
> remember it as being a fairly small program.
>

Once upon a time, I had to analyze Fortran code, and I considered
adapting f2c. I gave up when I discovered a goto from the outside into
the middle of a three-level nested loop. f2c is a hopeless mess.

[Brian Drummond]

On Wed, 06 Jun 2012 07:21:09 +0200, J-P. Rosen wrote:

> Le 05/06/2012 14:17, Brian Drummond a écrit :
>> For the C back-end, it might be worth looking at an old version of f2c,
>>

> Once upon a time, I had to analyze Fortran code, and I considered
> adapting f2c. I gave up when I discovered a goto from the outside into
> the middle of a three-level nested loop. f2c is a hopeless mess.

well, scratch THAT idea then! Thanks for the warning.

- Brian

[Marco]

Create a small Ada program with some short procedures and functions (skip tasks and IO) and try to "hack up" the GNAT Ada Pretty Printer to output equivalent C to see if this is a viable option forward. At the very least you will learn more about GNAT.