Re: Ada to C translator for small microcontrollers

[Rugxulo <rugxulo@gmail.com>]

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.