From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.3 required=5.0 tests=BAYES_00,INVALID_MSGID autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 103376,37b5f16b9be86fec X-Google-Attributes: gid103376,public From: fjh@mundook.cs.mu.OZ.AU (Fergus Henderson) Subject: Re: ada -> C translator Date: 1997/04/05 Message-ID: <5i4jok$qiq@mulga.cs.mu.OZ.AU>#1/1 X-Deja-AN: 230844873 References: <33436B29.41C6@sema-grenoble.fr> <5i243c$i1h@mulga.cs.mu.OZ.AU> Organization: Comp Sci, University of Melbourne Newsgroups: comp.lang.ada Date: 1997-04-05T00:00:00+00:00 List-Id: dewar@merv.cs.nyu.edu (Robert Dewar) writes: >Fergus said > ><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 | "I have always known that the pursuit WWW: | of excellence is a lethal habit" PGP: finger fjh@128.250.37.3 | -- the last words of T. S. Garp.