Re: ada -> C translator

[fjh@mundook.cs.mu.OZ.AU (Fergus Henderson)]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>One of
>the requirements of an Ada compiler is that it properly duplicate
>calling sequences to other languages, paying attention to ABI requirements.
...
>Short of writing one compiler that
>supports all known and unknown targets, you cannot use this approach
[the approach of compiling to C and using conditional compilation]
>to solve the problem.

It is true that interfacing to COBOL or Fortran cannot be done in
a portable manner using C.  I've already acknowledged that.
However, an Ada compiler is not required to support that;
such support is optional.

>Furthermore, since such choices can be quite fundamental
>the amount of stuff you are talking about would be huge and infeasible.

There is a trade-off between efficiency, portability, and simplicity.
The approach I'm talking about is certainly feasible for Mercury:
we have an existence proof.  Ada is more complicated than Mercury,
and it may have more features that don't map nicely into C, 
but it's not _that_ much more complicated, so I remain unconvinced
by claims that this sort of approach would be infeasible.

>For example, what shall we do with exceptions in C?

I implemented exceptions for Mercury without much difficulty;
it took about a day.  (The reason it was so easy was that the
mechanism needed is similar to that needed for backtracking,
which Mercury already supports, so I could reuse the same mechanism.)

>There are two answers
>that I know of. One is to always pass an implicit exception boolean around
>on every call. The other is to use setjmp/longjmp.

A third is to not use the C stack at all.  Then exception handling is no
problem.  That's the approach taken by the Mercury implementation.
In the general case, this can be fairly costly -- a factor of two or so --
but if you take advantage of GNU C extensions (using conditional compilation,
of course) then the cost is very small (in some cases it can even be a win).

>To generate correct and efficient code for all possible targets using
>conditional compilation might be conceptually possible, but in practice
>is out of the question from a complexity standpoint. FAR out of the
>question. 

I was not suggesting that.  I was talking about generating code that is
correct for all targets and that is efficient for the most important targets.

(In practice you may want to relax the requirement that it be "correct for
all targets" and instead just aim for miminizing the difficulty of porting.
For example, this may be necessary to support features that cannot be
portably implemented in C, such as interfacing with COBOL.)

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.