Re: ada -> C translator

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

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

>Fergus said
>
><<Yep, if you want efficiency, you may need to use machine-dependent
>code.  However, you can get this without sacrificing portability
>if you keep the less efficient but portable C code as a fallback.>>
>
>No, you missed the point.

I understood the point you were making.

>I am not talking about using non-portable constructs.

Yes you are!  You talk about it in the very next sentence (emphasis mine):

>The code you generate could be 100% ANSI code, but still
>NOT BE PORTABLE in the sense of being movable to another target
>environment.

The code could be 100% "conforming" ANSI/ISO C code, but the term
"conforming" applied to C code is basically useless.  The term just
means that there is one conforming ANSI/ISO C implementation somewhere that
accepts the code, and legalistically speaking ANSI/ISO C implementations
can accept Fortran code so long as they issue at least one diagnostic,
so legalistically speaking Fortran code could be called 100% "conforming"
ANSI C code.

The code could not be 100% "strictly conforming" ANSI/ISO C code,
because such code is not allowed to depend on implementation-defined
or unspecified behaviour.

>Here's another example. You might decide to model a variant record as
>an array of chars in the C code, to avoid the difficulty of having to
>give a high level model. But you know the alignment requirements for
>such an array of bytes and you put in alignment fill bytes explicitly
>into your data structures.

In that case what you are doing is non-portable.
If you want to be portable, you have to fall back to modelling
variant records using a high level model, e.g. as unions.

>Here's another example, you are generating calls to COBOL for implementing
>the IS annex.

This I admit is not something which can be done in strictly conforming
ANSI/ISO C code; there's no portable way of interfacing C and COBOL.
In an Ada to C compiler, the only foreign languages that you could
portably interface to would be C and C++.

>Fergus, what you say is true for general C code that tries to get better
>efficiency by using special non-portable constructs, but we are talking
>a completely different environment here when we talk about using C as
>a kind of low level pseudo machine language for compiler output.

I know what you're talking about.  I've written a compiler (not an Ada
compiler) that uses C in exactly this manner.  The output is not 100%
strictly conforming C (for example, we assume that there is some integral
type big enough to hold a pointer), but it is close enough to be quite
portable.  But we don't hesitate to conditionally take advantage of
non-portable features, such as shared libraries, mprotect(), struct sigcontext,
GNU C global register variables, taking addresses of labels, etc.,
in order to improve efficiency or functionality on particular platforms.
Because we do so only conditionally, this doesn't reduce portability.

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