comp.lang.ada
 help / color / mirror / Atom feed
From: "Robert I. Eachus" <rieachus@comcast.net>
Subject: Re: C array to ada record interface
Date: Tue, 27 Jul 2004 22:42:49 -0400
Date: 2004-07-27T22:42:49-04:00	[thread overview]
Message-ID: <0ZudnShYIIM3j5rcRVn-uA@comcast.com> (raw)
In-Reply-To: <KrzNc.180996$JR4.87585@attbi_s54>

tmoran@acm.org wrote:

>     package B_Ptr_Conversion is new System.Address_To_Access_Conversions(B);
>     subtype B_Ptr is B_Ptr_Conversion.Object_Pointer;
> which works on three different compilers.  But neither
> 
>     pragma Convention (C, B_Ptr);
> nor
>     pragma Convention (C, B_Ptr_Conversion.Object_Pointer);
> is then legal.

That is correct, see the limitations on where representation pragmas can 
appear in RM 13.1 as ammended.  (The wordsmithing in the 2000 Ammendment 
in this area is extensive, but I don't think it affected this issue one 
way or the other.)

> The program works without the pragma Convention on all three Ada compilers
> I tried, but it's not clear to me that's guaranteed to be OK, and if some
> system does need the pragma, is there a compiler-agnostic way to solve
> this problem?

No!  But remember here that what can't be compiler agnostic is the 
choice of C compiler and options to match the Ada compiler (and 
options).  If the Ada compiler uses the same type of addresses as the C 
compiler there is no problem.  But if you have a 64-bit Ada compiler and 
a 32-bit C compiler (or vice-versa) it can't work.

Well, not quite, but you know what I mean.  For example, with the new 
AMD64 chips--including Intel's newest Xeon--you can have a library that 
is compiled for IA-32, and another library compiled in long mode, and 
the hardware will convert the addresses if possible on the calls and 
returns so that a program can use either one.  But you can't link 32-bit 
code and long mode code into the same executable, you have to use .dlls.

The best you can do is to specify the sizes of the addresses, so that 
the compiler will reject your program if they don't match.  In fact a 
better example of why this is an insoluble problem is that the new Xeon 
(Nocona) does not have an IOMMU, while the Opteron and Athlon64 use the 
CPU's MMU for all memory references.  The net effect is that I/O drivers 
have to be written differently for the two families.  There is no magic 
wand that either a C compiler or an Ada compiler can wave to fix that 
semantic mismatch.

-- 

                                           Robert I. Eachus

"The flames kindled on the Fourth of July, 1776, have spread over too 
much of the globe to be extinguished by the feeble engines of despotism; 
on the contrary, they will consume these engines and all who work them." 
-- Thomas Jefferson, 1821




  parent reply	other threads:[~2004-07-28  2:42 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-07-14 23:17 C array to ada record interface Francisco Javier Loma Daza
2004-07-15  0:36 ` Brian May
2004-07-15  1:23 ` Jeffrey Carter
2004-07-22 18:02   ` Francisco Javier Loma Daza
2004-07-24 18:48     ` Ludovic Brenta
2004-07-25 17:26       ` Francisco Javier Loma Daza
2004-07-25 19:28       ` tmoran
2004-07-26 21:42         ` Ludovic Brenta
2004-07-27 21:04           ` tmoran
2004-07-27 22:15             ` Martin Dowie
2004-07-28  2:42             ` Robert I. Eachus [this message]
2004-07-29  5:56               ` tmoran
2004-07-29 19:58                 ` Robert I. Eachus
replies disabled

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