ada -> C translator

ada -> C translator

[Gabriel Monaton]

Hello,

Where can I find an ada -> c translator ?

 

-- 
Gabriel Monaton - Sema Group/Energy Division
E-mail gmn@sema-grenoble.fr          Sema Group
tel.   (33) 04-76-41-46-00           B.P. 104 38243 Meylan CEDEX
fax    (33) 04-76-41-47-47           France

Re: ada -> C translator

[Robert A Duff]

In article <33436B29.41C6@sema-grenoble.fr>,
Gabriel Monaton  <gmn@sema-grenoble.fr> wrote:
>Where can I find an ada -> c translator ?

You don't read this newsgroup much, do you?  We just had a huge argument
about this subject.  ;-)

First, what do you want:

1. Do you want it to handle the entire Ada language correctly?

2. Do you want it to produce C that is understandable to humans (e.g. C
programmers)?  (I.e. do you want a compiler that happens to produce C,
and you'll maintain the Ada code, or do you want to throw away the Ada
code, and maintain the C code?)

3. Do you want the C code to be efficient?

- Bob

(e-mailed and posted)

Re: ada -> C translator

[Robert Dewar]

Just to give a bit more detail on the overflow issue, and a specific example.
Consider the PPC architecture with its sticky bit.

The proper efficient code is to compute a whole expression, or at least a cjunk
of it with no calls, and then do one test of the sticky bit. There is no
way I know of to persaude a C compiler to get anywhere near to optimal code.

Note: the reason that I know this particular technical problem very well
is that in its current form, gcc does not know how to generate efficient
overflow checks. So even though we are not generating C in GNAT, we suffer
from similar limitations. Yes, we can play some tricks, like ICC did, but
we can't get really efficient overflow checking, not till gcc is properly
taught to handle overflow (note that the reason that gcc does not know
how to generate efficient overflow checking is because C does not know
about overflows!)

Given that gcc started life as a C code generator, one of the dynamics
of the GNAT project is that we have faced many of the same problems that
one would face generating C, though not all -- critically GNU C has
nested procedures, which standard C does not!

A critical difference is that, unlike the situation where you are stuck
generating C, we can over time teach gcc to know more about Ada specific
requirements. We have taught it quite a bit -- it still needs to be taught
more, notably in the areas of overflow checking and exception handling.

Re: ada -> C translator

[Robert Dewar]

Bob Duff said

<<First, what do you want:

1. Do you want it to handle the entire Ada language correctly?

2. Do you want it to produce C that is understandable to humans (e.g. C
programmers)?  (I.e. do you want a compiler that happens to produce C,
and you'll maintain the Ada code, or do you want to throw away the Ada
code, and maintain the C code?)

3. Do you want the C code to be efficient?
>>


To this you should add a fourth question:

4. Do you want the C code to be portable?

If you get into the business of generating very low level C code, then
it may well be highly target dependent (e.g. have made decisions about
representation of primitive data items).

Re: ada -> C translator

[Fergus Henderson]

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

>Bob Duff said
>
><<First, what do you want:
>
>1. Do you want it to handle the entire Ada language correctly?
>
>2. Do you want it to produce C that is understandable to humans (e.g. C
>programmers)?  (I.e. do you want a compiler that happens to produce C,
>and you'll maintain the Ada code, or do you want to throw away the Ada
>code, and maintain the C code?)
>
>3. Do you want the C code to be efficient?
>>>
>
>To this you should add a fourth question:
>
>4. Do you want the C code to be portable?
>
>If you get into the business of generating very low level C code, then
>it may well be highly target dependent (e.g. have made decisions about
>representation of primitive data items).

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.

	#if THIS_SYSTEM_SUPPORTS_IT
	... nonportable efficient code ...
	#else
	... portable but not-so-efficient code ...
	#endif

Of course, this assumes that the answer to question 2 was "no".

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

Re: ada -> C translator

[Larry Kilgallen]

In article <dewar.860115718@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:

> To this you should add a fourth question:
> 
> 4. Do you want the C code to be portable?
> 
> If you get into the business of generating very low level C code, then
> it may well be highly target dependent (e.g. have made decisions about
> representation of primitive data items).

I was under the impression that ANSI C did not provide anything
equivalent to Ada tasking.  Therefore I thought that a translator
would have to choose between portability and feature completeness.

Larry Kilgallen

Re: ada -> C translator

[Richard Kenner]

In article <5i243c$i1h@mulga.cs.mu.OZ.AU> fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
>>If you get into the business of generating very low level C code, then
>>it may well be highly target dependent (e.g. have made decisions about
>>representation of primitive data items).
>
>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 Robert's point.

The issue isn't support of non-portable constructs, but representation
of data items.  Specifically, discriminated records.  You will
probably be forced to generate code that has specific offsets encoded
into it.  These offsets will depend on the sizes of primitive
datatypes.

It just *might* be possible to write all these in terms of type sizes
at the C level and make it portable, but that's *really* hard if
possible at all.

Re: ada -> C translator

[Robert Dewar]

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 am not talking about using non-portable
constructs. The code you generate could be 100% ANSI code, but still
not be portable in the sense of being movable to another target
environment. For example, specific shifts might be generated whose
direction depends on the endianness of the target machine. Such code
could be ported, but would not behave as expected on a target of the
other endianness.

The point here is that if you are generating *really* low level C, it
will start having the same kind of knowledge of the target architecture
as a real object code generator would.

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.

Here's another example, you are generating calls to COBOL for implementing
the IS annex. You know on a specific target what COBOL passes by value
and what it passes by reference, and exactly how it orders its arguments
etc. You generate C code that reflects it. The C code is portable from
the point of view of C semantics, but might well not be able to interface
properly with the COBOL compiler on the new target.

There are many many more such examples

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.

Re: ada -> C translator

[Robert Dewar]

<<I was under the impression that ANSI C did not provide anything
equivalent to Ada tasking.  Therefore I thought that a translator
would have to choose between portability and feature completeness.>>

Wrong level of thinking. At the generated code level, tasking translates
into calls to the runtime library. Deciding to generate C does not remove
the task of coding a runtime library -- presumably this would be coded in
C, although it could also be coded in Ada (using the compiler to bootstrap,
the GNAT compiler uses VERY little of the runtime in the compiler itself).
But all tasking would be accomplished by using either the existing GNAT
(or other Ada technology) runtime, or creating a new runtime specially for
the purposes of this translator.

Have a look at the -gnatdg output from GNAT, you will see that, although
basically still Ada, it is a MUCH simplified subset of Ada.

Re: ada -> C translator

[Larry Kilgallen]

In article <dewar.860170469@merv>, dewar@merv.cs.nyu.edu (Robert Dewar) writes:
> <<I was under the impression that ANSI C did not provide anything
> equivalent to Ada tasking.  Therefore I thought that a translator
> would have to choose between portability and feature completeness.>>
> 
> Wrong level of thinking. At the generated code level, tasking translates
> into calls to the runtime library. Deciding to generate C does not remove
> the task of coding a runtime library -- presumably this would be coded in
> C, although it could also be coded in Ada (using the compiler to bootstrap,
> the GNAT compiler uses VERY little of the runtime in the compiler itself).
> But all tasking would be accomplished by using either the existing GNAT
> (or other Ada technology) runtime, or creating a new runtime specially for
> the purposes of this translator.

In that case I would count that runtime library as part of the
"translation" of the Ada program into C, and it seems unlikely
to be portable for the tasking implementation.

Or does the specification of ANSI C include Posix thread calls ?

Larry

Re: ada -> C translator

[Fergus Henderson]

kenner@lab.ultra.nyu.edu (Richard Kenner) writes:

>The issue isn't support of non-portable constructs, but representation
>of data items.  Specifically, discriminated records.  You will
>probably be forced to generate code that has specific offsets encoded
>into it.  These offsets will depend on the sizes of primitive
>datatypes.
>
>It just *might* be possible to write all these in terms of type sizes
>at the C level and make it portable, but that's *really* hard if
>possible at all.

Well, it's certainly possible.  Whether it is practical or not is
another question.

One possibility is to use

	union Word { long l; void *p; };

as essentially your only data type in the generated C code.
Then you can use arrays instead of structs and you can calculate
offsets portably.

Of course, this is not efficient.  But you can use conditional compilation...

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

Re: ada -> C translator

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

Re: ada -> C translator

[Robert Dewar]

Larry said

<<In that case I would count that runtime library as part of the
"translation" of the Ada program into C, and it seems unlikely
to be portable for the tasking implementation.

Or does the specification of ANSI C include Posix thread calls ?>>

We were talkk
We were talking about using C instead of assembler as a translation
mechanism for Ada. Certainly if you want tasking, you will have to
program a runtime library. That runtime library might lie on top
of Posix threads, but it might well include all the threads mechanism.
For example, the FSU threads package could be ported and used. So
yes, the runtime library is most certainly part of the translation,
but there is no conceptual problem in doing a complete implementation
of the runtime library, including Ada tasking, in pure ANSI C. It
would be work, yes, of course, but there is no conceptual problem,
and you certainly do not need posix threads to be supplied in the
environment to get Ada tasking working!
b

Re: ada -> C translator

[Robert Dewar]

Fergus quoting Robert
  I am not talking about using non-portable constructs.

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

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

Robert replies

You are still missing the point. The C code that you generate would be
portable in the sense that it would do EXACTLY the same thing on all
targets, BUT remember what this code is. It is a translation of the
Ada code for a particular target. The Ada code means different things
on different targets for all sorts of reasons (e.g. the sizes of
the appropriate types in standard, or all sorts of other impementation
dependent features which for one reason or another you want to implement
differently in different target enbvironments.

So although there is no problem in generaing completely portable C it is
NOT what you want.

For example, I have an Ada program, I compile it on machine X, and I
compile it on machine Y. It quite expectedly runs differently on the
different machines, since the Ada program depends on some implementation
dependent features (e.g. it convers an integer to a packed array using
unchecked conversion, and expects the bit numbering to change as a result^H
of changing endianness.

Now when we compile this on machine X generating the low level C for
machine X, we get the expected semantics from the portable C we are
generating.

Furthermore, you could move that C to machine Y, and it would do exactly
the same thing it did on machine X, BUT THAT IS WRONG! Because you expect
different semantics for the Ada on machine Y.

The whole point here is that just because you are generating C, it does not
mean that you would generate the same C on every machine. And the fact that
you are generating completely standard portable ANSI-C does not change this.

I don't know how to be clearer, perhaps you need to know more about the
mechanics of compilers to see what I am getting at. It is kind of a critical
point in this discussion.

A lot of people think as you do that what you want is to take the "portable"
Ada and convert it into "portable" C. This informal concept makes sense if
the semantic level of the C you generate is approximately the same as the
semantic level of the Ada that you start with.

But we are talking here about generating very low level C, which will for
instance have to reflect various requirements for the ABI in which it
is generated (e.g. length of standard types, representation of types,
calling sequence rules etc). 

So I will say it again, and maybe this time you will see that these
statements are NOT incompatible.

  The C you will generate does not use any non-portable constructs.

  BUT it still will not be portable in the sense of being [usefully]
  movable to another target environment!

The rest of what Fergus said is not relevant because of this fundamental
misunderstanding.

Re: ada -> C translator

[Fergus Henderson]

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

>But we are talking here about generating very low level C, which will for
>instance have to reflect various requirements for the ABI in which it
>is generated (e.g. length of standard types, representation of types,
>calling sequence rules etc). 

Why will the C generated C code have to reflect ABI requirements?
Does conformance to the Ada standard require using a particular ABI?
Can't an Ada implementation make up its own ABI?

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

Re: ada -> C translator

[Robert Dewar]

Fergus said

<<Why will the C generated C code have to reflect ABI requirements?
Does conformance to the Ada standard require using a particular ABI?
Can't an Ada implementation make up its own ABI?>>

Not if it wants to properly interface to the rest of the world (pragma
Import and Export are part of the langauge).

Also, another point you are missing is that if you are interested in
efficiency, you will tailor the C in different ways. For example, suppose
you have a C compiler in which overflow checking can be done by generating
code in some very particular (completely portable) manner, but on some other
C compiler, this particular approach is too inefficient.

Let me be very specific.

suppose we have

    A := B + C;

where all quantities are 32 bits.

One approach to overflow checking is to do the arithmetic in 64 bits, and
do range checking, but this requires a C compiler that supports 64 bit
arithmetic, and a machine where 64-bit arithmetic is efficient.

Another approach is to do the arithmetic in 32-bit unsigned, and then check
sign bits.

Both these generated C programs are completely portable, but you will choose
which one to generate in a target dependent manner.

(actually there *is* a portability question here which is the availability
of 64-bit arithmetic in C -- that leads to an even sharper example, on some
machines you might have to generate runtime calls to do 64-bit arithmetic).

There are many, many other examples (e.g directions of shifts for packed
stuff being dependent on endianness to maintain mapping with record rep
specs in the expected manner).

I perfectly understand why someone who does not know much about compilers
would try to maintain, as Fergus does, a view that portable C is portable
C and that should be that, but I am afraid that this viewpoint is plain
wrong when applied at this level!

Re: ada -> C translator

[Fergus Henderson]

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

>Fergus said
>
><<Why will the C generated C code have to reflect ABI requirements?
>Does conformance to the Ada standard require using a particular ABI?
>Can't an Ada implementation make up its own ABI?>>
>
>Not if it wants to properly interface to the rest of the world (pragma
>Import and Export are part of the langauge).

Ah, but pragma Import and Export are defined so as to allow the
Ada calling convention, data sizes, etc. to be different from those
used by the imported or exported code, aren't they?

>Also, another point you are missing is that if you are interested in
>efficiency, you will tailor the C in different ways.

Of course!  To elaborate on my earlier remarks:

	#if MACHINE_SUPPORTS_THIS
	    ... code tailored for efficiency on machines that support this...
	#elif MACHINE_SUPPORTS_THAT
	    ... code tailored for efficiency on machines that support that...
	#elif MACHINE_SUPPORTS_THE_OTHER
	    ... code tailored for efficiency on machines that support the other
	#else
	    ... portable but less efficient code ...
	#endif

>Let me be very specific.
>
>suppose we have
>
>    A := B + C;
>
>where all quantities are 32 bits.
>
>One approach to overflow checking is to do the arithmetic in 64 bits, and
>do range checking, but this requires a C compiler that supports 64 bit
>arithmetic, and a machine where 64-bit arithmetic is efficient.
>
>Another approach is to do the arithmetic in 32-bit unsigned, and then check
>sign bits.
>
>Both these generated C programs are completely portable, but you will choose
>which one to generate in a target dependent manner.

Or alternatively, instead of choosing which code to generate at Ada-to-C
translation time, you could generate C code that chooses which approach to
take a preprocessing time, via conditional compilation.

For example, when incrementing the Mercury stack pointer,
the Mercury compiler generates code that looks like this:

	incr_sp(1);

Here `incr_sp' is a macro defined in a header file, and
conditional compilation is used to determine whether or not
it checks for overflow.  On some systems, the Mercury runtime
uses mprotect() to get the OS to detect stack overflow.

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

Re: ada -> C translator

[Robert Dewar]

Fergus said

<<Ah, but pragma Import and Export are defined so as to allow the
  Ada calling convention, data sizes, etc. to be different from those
  used by the imported or exported code, aren't they?>>

Robert replies

Of course, but, if you understand the point I was making (which I think
you still miss), you will see that this is totally irrelevant. One of
the requirements of an Ada compiler is that it properly duplicate
calling sequences to other languages, paying attention to ABI requirements.

Fergus said

<<Of course!  To elaborate on my earlier remarks:

        #if MACHINE_SUPPORTS_THIS
            ... code tailored for efficiency on machines that support this...
        #elif MACHINE_SUPPORTS_THAT
            ... code tailored for efficiency on machines that support that...
        #elif MACHINE_SUPPORTS_THE_OTHER
            ... code tailored for efficiency on machines that support the other
        #else
            ... portable but less efficient code ...
        #endif>>

Robert replies

Sorry, that still misses the point. Short of writing one compiler that
supports all known and unknown targets, you cannot use this approach to
solve the problem. Furthermore, since such choices can be quite fundamental
the amount of stuff you are talking about would be huge and infeasible.

For example, what shall we do with exceptions in C? 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. The choice between these
two will radically affect the compiler, the code it generates, and the
natural of the runtime library. Just trying to generate code that supported
both of these possibilities would enormously complicate the compiler, and
of course if I give you K more examples, then you have a 2**K way explosion
of interactions that have to be considered.

You are still thinking in terms of conventional C generated by humans.
Sorry -- wrong level of thinking, not applicable here!

Your discussion of the incr_sp approach is flawed for the same reason.
It is hard enough to generate correct efficient code for a single target.
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. 

Re: ada -> C translator

[Robert Dewar]

iRichard O'Keefe said

<<Nor has Fergus said that "portable C is portable C and that is that".
His claim, as I understood it, was that one can translate a source
program that is intended to be portable to C that can adapt to particular
targets but is usable on many.  Talking about interfacing to COBOL misses
_his_ point, because in that case the source program isn't _intended_ to
be portable (the porting target might not _have_ a COBOL compiler).>>

I gave many other examples.

The problems that people have in understanding the nature of target
dependence make me think that people do not really understand what we
are talking about. They still probably are thinking in terms of translation
into reasonably high level C, but that's NOT possible. What we are talking
about is generating very low level C, much of it at the level of semantics
of assembly, and much of it incorporating target semantics.

And if you do not think it is possible to write portable Ada programs that
interface with COBOL, you completely misunderstand the intention of section
B.4 of the RM.

Sure it might be the case that a partiular source program does not use this
feature of Ada 95, and you only need a subset of the language compiled.

Well that of course changes the viewpoint. If you restrict the subset
severely enough (no exceptions, pragma suppress assumed, no nested 
procedures, no variant records etc. etc. etc.), then you WILL be able
to translate the Ada subset directly into C.

But if you want to cover the whole language, even if you restrict yourself
to the required part of the language, you will find situations in which you
have to play low level games, and where it is hard, or probably impossible,
to avoid target dependences in the generated C code.

Re: ada -> C translator

[William Clodius]

Richard A. O'Keefe wrote:
> <snip>
> Nor has Fergus said that "portable C is portable C and that is that".
> His claim, as I understood it, was that one can translate a source
> program that is intended to be portable to C that can adapt to particular
> targets but is usable on many.  Talking about interfacing to COBOL misses
> _his_ point, because in that case the source program isn't _intended_ to
> be portable (the porting target might not _have_ a COBOL compiler).
> <snip>

Both Robert Dewar and Fergus Henderson are talking past one another.
Robert argues that there are significant machine dependencies in the
translation of Ada, Fergus argues that any given machine dependency can
be handled using conditional compilation. Both statements are valid and
not in contradiction, but both are misleading.

Fergus's points are perfectly valid for Mercury, however, this thread is
not about compiling Mercury to C, but about compiling Ada to C. As a
logic programming language Mercury is much more distant from the machine
than is Ada. An Ada compiler to retain efficiency and correctness of
translation has to be more sensitive than Mercury to machine (and C
compiler) differences.  If the amount of code that is processor
independent is relatively small, then the usefullness of C as a portable
language vanishes. The problem is not that conditional compilation
cannot in principle be used to address these issues, which is what
Robert Dewar's arguments seem to suggest, but rather that in the case of
Ada what is possible in principle is impractical in practice.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: ada -> C translator

[William Clodius]

Robert Dewar wrote:
> <snip>
> You are still thinking in terms of conventional C generated by humans.
> Sorry -- wrong level of thinking, not applicable here!
> <snip>

Do not assume that Fergus is thinking of C generated by humans. When you
assume that you argue from an invalid position. This assumption leads to
statements that imply that it is always impractical to include
conditional compilation for C generated by a machine. Further, other
valid statements that you make will often be ignored or misunderstood,
due to the buttons such a statement will push. Fergus works all the time
with C generated automatically by a compiler to C that takes into
account the dependencies of a variety of systems, and is well aware that
machine generated C that includes conditional compilation directives is
a practical solution for many cases.  The problem is not whether the
code is machine or human generated, but whether for Ada in particular
the complexity becomes impractical.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: ada -> C translator

[Richard A. O'Keefe]

dewar@merv.cs.nyu.edu (Robert Dewar) writes:
>I perfectly understand why someone who does not know much about compilers
>would try to maintain, as Fergus does, a view that portable C is portable
>C and that should be that, but I am afraid that this viewpoint is plain
>wrong when applied at this level!

As Fergus has pointed out, only a bit more modestly, he actually knows
quite a lot about compilers, and is currently _working_ on a delivered
compiler for a rather interesting language, which compiler generates C.
The Mercury group want the best performance they can get out of the
code they generate, which means they are interested in code that adapts
to the target appropriately.  The possible point of difference here is
that Mercury programmers expect the *same* semantics for their programs
whenever possible; if I compile a Mercury program on UNIX machine X and
get one set of results, I expect the _same_ results on UNIX machine Y.

Nor has Fergus said that "portable C is portable C and that is that".
His claim, as I understood it, was that one can translate a source
program that is intended to be portable to C that can adapt to particular
targets but is usable on many.  Talking about interfacing to COBOL misses
_his_ point, because in that case the source program isn't _intended_ to
be portable (the porting target might not _have_ a COBOL compiler).


-- 
Will maintain COBOL for money.
Richard A. O'Keefe; http://www.cs.rmit.edu.au/%7Eok; RMIT Comp.Sci.

Re: ada -> C translator

[Fergus Henderson]

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

>You may remain unconvinced, but it just goes to show that you have not
>really looked at the detailed issues of implementing Ada this way.

Well, I do remain unconvinced.  In fact, so far with each detailed
issue that you have raised, the more unconvinced I have become, because
the issues you have raised are either issues that the Mercury implementation
deals with or issues which seem easily solvable.

>Also, it becomes clear that what you have in mind for an Ada compiler
>written this way is more of a small subset Ada toy than a real compiler

What I had in mind was not a small subset Ada toy; I had in mind
something that could be validated.

(Some Ada features might require small amounts of non-portable code,
but porting would still be a lot easier than porting a native-code
compiler.)

>(it is out of the question for example, for a real Ada compiler, which
>must implement pragma Import and pragma Export properly to consider not
>using an invocation stack).

I don't know what you're trying to say here.  I think this statement is
at best vacuous, and at worst false.  Certainly any implementation of a
language that supports recursion is going to need an invocation stack.
But an Ada implementation could use a different invocation stack than
the languages that it interfaces with via pragma Import and pragma
Export, and an Ada compiler that worked via compilation to C need not
use the C stack as its invocation stack.   Why do you suggest that this
would be "out of the question"?  (In case you were wondering, the
Mercury implementation has a C interface which supports functionality
quite similar to Ada's "pragma import" and "pragma export", and it does
not use the C stack as its invocation stack.)

What do you mean by a "real" Ada compiler?

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

Re: ada -> C translator

[Robert Dewar]

Fergus said

<<What I had in mind was not a small subset Ada toy; I had in mind
something that could be validated.>>

Oh dear! I thought that at this stage there was *no one* left who thought
that validated meant usable -- oh well. Fergus I guess you are too young
to remember the early versions of Ada/Ed :-)

Those who do were hopefully permanently cured of the naive assumption
that validated means usable. Ada/Ed was very much a toy compiler, and
yes, you certainly could create an Ada/ed equivalent in portable C, but
I do not think that is what is interesting.

I am giving up on trying to convince you since I don't think you have a
sufficient frame of reference. If you want to prove me wrong, go ahead
and translate a decent sized Ada program which uses the features of the
language, including those in Annexes A-C reasonabley extensively, into
the kind of C, and write the runtime that goes with it.

Yes, I know that's a big job -- in fact remember that my contention is
that it is an impossible job. Your work on Mercury is not even close to
an example for all sorts of reasons.

So, bottom line, I say that X does not exist and cannot exist, where X is

a completely portable, reasonably complete, reasonabley efficient translation
of Ada into C, and you say it can exist.

Fine, since we are talking about existence, I see the only final proof
being actual existence!

Re: ada -> C translator

[William Clodius]

Fergus Henderson wrote:
> <snip>
> 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.
> <snip>

For Fortran you can probably do it for a wide variety of platforms by
supporting F2C or NAG's F90 to C compiler. If you rely on gcc for your C
compiler I suspect that you could also support g77.

-- 

William B. Clodius		Phone: (505)-665-9370
Los Alamos Nat. Lab., NIS-2     FAX: (505)-667-3815
PO Box 1663, MS-C323    	Group office: (505)-667-5776
Los Alamos, NM 87545            Email: wclodius@lanl.gov

Re: ada -> C translator

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

Re: ada -> C translator

[Fergus Henderson]

William Clodius <wclodius@lanl.gov> writes:

>An Ada compiler to retain efficiency and correctness of
>translation has to be more sensitive than Mercury to machine (and C
>compiler) differences.  If the amount of code that is processor
>independent is relatively small, then the usefullness of C as a portable
>language vanishes.

I don't think that follows.  Even if the amount of machine-indendent
code in the compiler and/or runtime is dwarfed by the amount of
machine-dependent code, the ability to easily port to new machines is
useful.  It may require lots of additional work to make such ports
efficient, but an inefficient port (or one that doesn't support
interfacing to COBOL, or one that doesn't support shared libraries,
etc.) is still a lot better than none at all.

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

Re: ada -> C translator

[Robert Dewar]

Fergus said

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


You may remain unconvinced, but it just goes to show that you have not
really looked at the detailed issues of implementing Ada this way.
Obviously Mercury has *much* simpler compilation semantics than Ada
if it can be handled in this way -- that's entirely possible certainly.

Also, it becomes clear that what you have in mind for an Ada compiler
written this way is more of a small subset Ada toy than a real compiler
(it is out of the question for example, for a real Ada compiler, which
must implement pragma Import and pragma Export properly to consider not
using an invocation stack).

I think you are trying to solve a much simpler problem with Mercury 
(certainly sounds much simpler from all your descriptions), and you
assume that this experience can be projected on to Ada, it cannot!

Re: ada -> C translator

[Fergus Henderson]

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

>Fergus said
>
><<What I had in mind was not a small subset Ada toy; I had in mind
>something that could be validated.>>
>
>Oh dear! I thought that at this stage there was *no one* left who thought
>that validated meant usable -- oh well.

I don't think validated necessarily means usable, but validatation does
indicate that something is not a small subset.

I had in mind something that was usable as well as validatable.

>I am giving up on trying to convince you since I don't think you have a
>sufficient frame of reference. If you want to prove me wrong, go ahead
>and translate a decent sized Ada program which uses the features of the
>language, including those in Annexes A-C reasonabley extensively, into
>the kind of C, and write the runtime that goes with it.

Does using someone else's Ada -> JVM and JVM -> C compilers count?

Do consider the AdaMagic (or is it AppletMagic?) Ada to JVM
compiler to be a toy?  Do you consider it to be usable?


When I originally wrote

	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.

I did not expect this to be a controversial statement.

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

Re: ada -> C translator

[Lance Kibblewhite]

Erik Magnuson <erik@fl.ensco.com> wrote:

>Gabriel Monaton <gmn@sema-grenoble.fr> writes:
>
>> Where can I find an ada -> c translator ?
>
>Here is my attempt to provide a answer for this FAQ. Unless someone objects,
>I propose to trot this out each time I see this question. Hopefully, this
>will enable use to discuss more important things like the proper
>capitalization of keywords and identifiers ;-)
>
>
>Short Answer:
>

[good answer clipped]

>Medium Answer:

[better answer clipped]

>Long Answer:

[best answer clipped]

>In summary:
>* It's technically possible
>* It's even been done (for Ada 83 and a few specific targets)
>* It's difficult (and a lot of effort) to do correctly even for a single target 
>* No one has even tried to do it for the "general case" (e.g. portable C)
>* It's not an interesting enough solution for paying customers for there to 
>  be an active market.  

So then, why do others insist on calling 'C' the universal assembler?

(Yes, that was rhetorical).


-- Lance.