Re: ada -> C translator

[dewar@merv.cs.nyu.edu (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.