comp.lang.ada
 help / color / mirror / Atom feed
From: dewar@merv.cs.nyu.edu (Robert Dewar)
Subject: Re: ada -> C translator
Date: 1997/04/07
Date: 1997-04-07T00:00:00+00:00	[thread overview]
Message-ID: <dewar.860415922@merv> (raw)
In-Reply-To: 5i9r5t$nb6@mulga.cs.mu.OZ.AU


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!





  reply	other threads:[~1997-04-07  0:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1997-04-03  0:00 ada -> C translator Gabriel Monaton
1997-04-03  0:00 ` Robert A Duff
1997-04-03  0:00   ` Robert Dewar
1997-04-03  0:00     ` Robert Dewar
1997-04-04  0:00     ` Larry Kilgallen
1997-04-04  0:00       ` Robert Dewar
1997-04-05  0:00         ` Larry Kilgallen
1997-04-06  0:00           ` Robert Dewar
1997-04-04  0:00     ` Fergus Henderson
1997-04-04  0:00       ` Richard Kenner
1997-04-05  0:00         ` Fergus Henderson
1997-04-04  0:00       ` Robert Dewar
1997-04-05  0:00         ` Fergus Henderson
1997-04-06  0:00           ` Robert Dewar
1997-04-07  0:00             ` Fergus Henderson
1997-04-07  0:00               ` Robert Dewar [this message]
1997-04-08  0:00                 ` Richard A. O'Keefe
1997-04-08  0:00                   ` William Clodius
1997-04-09  0:00                     ` Fergus Henderson
1997-04-08  0:00                   ` Robert Dewar
1997-04-08  0:00                 ` Fergus Henderson
1997-04-08  0:00                   ` Robert Dewar
1997-04-08  0:00                     ` William Clodius
1997-04-09  0:00                     ` Fergus Henderson
1997-04-09  0:00                       ` Robert Dewar
1997-04-09  0:00                         ` Fergus Henderson
1997-04-09  0:00                           ` Robert Dewar
1997-04-10  0:00                             ` Fergus Henderson
1997-04-09  0:00                       ` William Clodius
     [not found] ` <lvlo6iwws8.fsf@sulu.fl.ensco.com>
1997-04-17  0:00   ` Lance Kibblewhite
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox