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/07 Message-ID: #1/1 X-Deja-AN: 231294977 References: <33436B29.41C6@sema-grenoble.fr> <5i243c$i1h@mulga.cs.mu.OZ.AU> <5i4jok$qiq@mulga.cs.mu.OZ.AU> <5i9r5t$nb6@mulga.cs.mu.OZ.AU> Organization: New York University Newsgroups: comp.lang.ada Date: 1997-04-07T00:00:00+00:00 List-Id: Fergus said <> 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!