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/08
Message-ID: <5idcjq$8lh@mulga.cs.mu.OZ.AU>#1/1
X-Deja-AN: 231529521
References: <33436B29.41C6@sema-grenoble.fr> <E833ux.337@world.std.com>
 <dewar.860115718@merv> <5i243c$i1h@mulga.cs.mu.OZ.AU> <dewar.860160369@merv>
 <5i4jok$qiq@mulga.cs.mu.OZ.AU> <dewar.860361046@merv>
 <5i9r5t$nb6@mulga.cs.mu.OZ.AU> <dewar.860415922@merv>
Organization: Comp Sci, University of Melbourne
Newsgroups: comp.lang.ada
Date: 1997-04-08T00:00:00+00:00
List-Id: <comp.lang.ada>


dewar@merv.cs.nyu.edu (Robert Dewar) writes:

>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).

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?

>Also, another point you are missing is that if you are interested in
>efficiency, you will tailor the C in different ways.

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

>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.

Or alternatively, instead of choosing which code to generate at Ada-to-C
translation time, you could generate C code that chooses which approach to
take a preprocessing time, via conditional compilation.

For example, when incrementing the Mercury stack pointer,
the Mercury compiler generates code that looks like this:

	incr_sp(1);

Here `incr_sp' is a macro defined in a header file, and
conditional compilation is used to determine whether or not
it checks for overflow.  On some systems, the Mercury runtime
uses mprotect() to get the OS to detect stack overflow.

--
Fergus Henderson <fjh@cs.mu.oz.au>   |  "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh>   |  of excellence is a lethal habit"
PGP: finger fjh@128.250.37.3         |     -- the last words of T. S. Garp.