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: dewar@merv.cs.nyu.edu (Robert Dewar) Subject: Re: ada -> C translator Date: 1997/04/06 Message-ID: #1/1 X-Deja-AN: 231153579 References: <33436B29.41C6@sema-grenoble.fr> <5i243c$i1h@mulga.cs.mu.OZ.AU> <5i4jok$qiq@mulga.cs.mu.OZ.AU> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-06T00:00:00+00:00 List-Id: 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.