Interfacing Ada to C

Interfacing Ada to C

[Rune Wemberg]

Hello!

In the Gnat reference manual, in the "Interfacing to C"
section, it says:

Packed Ada records map to C structures where all 
members are bit fields of the length corresponding
to the type'Size value in Ada.

Does anyone know what a packed Ada record is?

--
Rune Wemberg
ruw@ffi.no

Re: Interfacing Ada to C

[Robert Dewar]

Rune says

<<Packed Ada records map to C structures where all
members are bit fields of the length corresponding
to the type'Size value in Ada.

Does anyone know what a packed Ada record is?>>

It is a record to which pragma Pack is applied!

Re: Interfacing Ada to C

[Samuel Tardieu]

>>>>> "Rune" == Rune Wemberg <ruw@ffi.no> writes:

Rune> Does anyone know what a packed Ada record is?

It's a record on which you apply a pragma Pack. For example, the
following type R is a packed record:

  type My_Natural is range 0 .. 15;
  for My_Natural'Size use 4;

  type R is record
    A, B : My_Natural;
  end record;
  pragma Pack (R);
  for R'Size use 8;

If you do:

  My_R : aliased constant R := (1, 2);

then My_R will be represented in memory by a single byte containing
00010010 (or 00100001, depending on the endianness).

Here is the code generated by GNAT for the m68k:

.data
_t__my_r:
        .byte 0x12

Hope this helps.

  Sam
-- 
Samuel Tardieu -- sam@ada.eu.org

Re: Interfacing Ada to C

[Matthew Heaney]

In article <m3afle72cl.fsf@zaphod.enst.fr>, Samuel Tardieu <sam@ada.eu.org>
wrote:

>  type My_Natural is range 0 .. 15;
>  for My_Natural'Size use 4;
>
>  type R is record
>    A, B : My_Natural;
>  end record;
>  pragma Pack (R);
>  for R'Size use 8;
>
>If you do:
>
>  My_R : aliased constant R := (1, 2);
>
>then My_R will be represented in memory by a single byte containing
>00010010 (or 00100001, depending on the endianness).

I'm not sure that the statement "depending on the endianness" is correct. 
Isn't the compiler free to put A and B wherever it chooses?  You have no
guarantee that A comes later or earlier than B, no matter what the
endianess is.

All pragma Pack does is minimize the gaps between the components; it has
nothing to say about the location of the components within the enclosing
record (I think).

Which is why I wouldn't recommend it for interfacing to another language. 
A record representation clause should be used to explictly state the
location of each and every component, so it's absolutely unambiguous what
the layout is.  

for R use
   record
      A at 0 range 0 .. 3;
      B at 0 range 4 .. 7;
   end record;

for R'Size use 8;

for R'Bit_Order use Low_Bit_First;

This puts A on the right (least significant) end of the record, no matter
what the endianess is.

I don't use pragma Pack except on an array of Booleans, because the only
time that pragma Pack makes a guarantee about representation is on an array
whose component size is 1.

Sadly, there's no equivalent to Bit_Order for arrays.  What I would like to
be able to do is specify that the first bit (0) occupies the least
significant location of the storage element, ie

type Bit_Array is array (Natural range 0 .. 7) of Boolean;
pragma Pack (Bit_Array);

type Byte is range 0 .. 255;
for Byte'Size use 8;

function To_Byte is
   new Unchecked_Conversion (Bit_Array, Byte);

Bits : constant Bit_Array := (0 => True, others => False);

Bits_As_Byte : constant Byte := To_Byte (Bits);

On a little endian machine, Bits_As_Byte has the value 1.

On a big endian machine, Bits_As_Byte has the value 128.

It would be cool if there were an attribute analogous to Bit_Order for arrays:

for Bit_Array'Index_Order use Low_Order_First;

That way bit 0 would occupy the least significant bit.  Oh well, maybe Ada 0X.

--------------------------------------------------------------------
Matthew Heaney
Software Development Consultant
<mailto:matthew_heaney@acm.org>
(818) 985-1271

Re: Interfacing Ada to C

[Robert A Duff]

In article <mheaney-ya023680003005972336090001@news.ni.net>,
Matthew Heaney <mheaney@ni.net> wrote:
>I'm not sure that the statement "depending on the endianness" is correct. 
>Isn't the compiler free to put A and B wherever it chooses?  You have no
>guarantee that A comes later or earlier than B, no matter what the
>endianess is.

Correct.

>All pragma Pack does is minimize the gaps between the components; it has
>nothing to say about the location of the components within the enclosing
>record (I think).

Correct, but the RM goes to some trouble to say how *much* those gaps
are minimized.

>Which is why I wouldn't recommend it for interfacing to another language. 
>A record representation clause should be used to explictly state the
>location of each and every component, so it's absolutely unambiguous what
>the layout is.  

Agreed that Pack shouldn't be used for interfacing purposes.  But you
don't always need to use record rep_clauses -- you can often use pragma
Convention(C or whatever) instead.  Record rep clauses are a pain during
maintenance -- they (over)specify all those bit numbers, when all you
really want to say is, "Do it like the corresponding C struct", or "lay
it out in order, using sensible alignment considerations."

>I don't use pragma Pack except on an array of Booleans, because the only
>time that pragma Pack makes a guarantee about representation is on an array
>whose component size is 1.

Now that's a bit harsh.  First of all, if what you want is to minimize
space, but you don't care what the exact layout is, then pragma Pack is
perfectly fine, even for non-Booleans.  Second, the RM *does* guarantee
a lot about how much packing is done (if the SP annex is supported).
E.g. a record containing three components of subtype "Integer range
1..2**5-1" and two components of subtype "Character range 'a'..'z'", and
three Booleans, is guaranteed to fit in 32 bits (on a typical 32-bit
machine).

>Sadly, there's no equivalent to Bit_Order for arrays.

Agreed.  I had mixed feelings during the Ada 9X project: should we beef
up the chap 13 features to really be complete, or should we weaken them,
since they cause a lot of extra compiler work for little benefit?  The
former is too tough, IMHO -- I mean, consider what additional
functionality would be needed to specify a bunch of records that map to
the 80386 instruction set?  Or the 386 segment tables (where fields are
split into pieces, and numbers are measured in bytes vs. pages,
according to some other bit)?

In the end, I decided that Ada isn't being used particularly because of
chap 13 features, and even if we eliminated chap 13 entirely, we would
be no worse off than other languages like C.  So, my approach was to
codify the meaning of existing features, mostly relying on existing Ada
83 AI's, and not go any further.  Yeah, pragma Bit_Order is a
counter-example to this philosophy, but the rules are pretty weak --
almost all Ada compilers today are for machines where the non-default
bit order is not required to be supported (i.e. byte-addressable
machines).

After all, people were agitating for the OOP features, and protected
types, and child packages -- we had no mandate to add a whole bunch of
stuff to chap 13.

- Bob

Re: Interfacing Ada to C

[Robert Dewar]

Bob Duff said

<<Agreed that Pack shouldn't be used for interfacing purposes.  But you
don't always need to use record rep_clauses -- you can often use pragma
Convention(C or whatever) instead.  Record rep clauses are a pain during
maintenance -- they (over)specify all those bit numbers, when all you
really want to say is, "Do it like the corresponding C struct", or "lay
it out in order, using sensible alignment considerations."
>>

In GNAT, it is well defined that a packed record with Convention C has
identical layout to the corresponding C type in which each field has the
length in bits coresponding to the size of the Ada type, we have found
this quite useful.

Re: Interfacing Ada to C

[Robert A Duff]

In article <m3afle72cl.fsf@zaphod.enst.fr>,
Samuel Tardieu  <sam@ada.eu.org> wrote:
>  type My_Natural is range 0 .. 15;
>  for My_Natural'Size use 4;

The 'Size clause should not be necessary.  My_Natural'Size = 4 by
default.  At least this is true for a compiler that conforms to the SP
Annex -- without that, most of chapter 13 means nothing anyway.

>  type R is record
>    A, B : My_Natural;
>  end record;
>  pragma Pack (R);
>  for R'Size use 8;
>
>If you do:
>
>  My_R : aliased constant R := (1, 2);
>
>then My_R will be represented in memory by a single byte containing
>00010010 (or 00100001, depending on the endianness).

That's misleading.  The RM says that it will fit in 8 bits.  The RM says
nothing about the order of the components.  The order need not have
anything to do with endianness -- it's up the whim of the compiler
writer.  Consider a record with three components -- there are 6 possible
orders to lay them out in memory (assuming the compiler isn't doing
anything really weird, like splitting components into pieces), and the
compiler can choose any one of those 6.  Some of those orders may be
more efficient than others.  I would like my compiler to choose an
efficient order (unless I do pragma Convention(C) or whatever, in which
case I want the order to match the source code).  I want to write my
record type in some logical order, without worrying too much about what
the most efficient layout is.  This is true whether or not I choose to
use pragma Pack.

- Bob

Re: Interfacing Ada to C

[Robert A Duff]

In article <5mjvk9$sm7$1@luna.ffi.no>, Rune Wemberg <ruw@ffi.no> wrote:
>Does anyone know what a packed Ada record is?

Look up pragma Pack.

- Bob

Interfacing Ada to C

[Drew]

I've built a static library with C code using MS developer
studio.  When I use our DDCI Ada'83 compiler to link into
it, it works perfectly.  When I use Microsofts MSlink to
link the ada code into the C library, it works find.  When
I use GNAT (gcc) to link into the library, I have
problems.  Here's what's happening.

Ada call

Send_Message;

C code

void Test (void) {

printf("Inside test.");
}

void Send_Message (void) {

printf("Inside send message.");

//This works fine.  But when the C code calls another
//procedure inside the library, it crashes.  This only
//happens with the GNAT compiler.

test;
//it crashes here.
}

Does anyone know why this happens, and how to solve it???



**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****

Interfacing Ada to C

[Drew]

I've built a static library containing C code using MSDEV
Studio.  When I link into the library using our DDCI Ada'83
compiler, everything works fine.  If I use MSDEV's mslink
to link the Ada code into the library, it works fine.  When
I use GNAT (gcc), I have problems.  Here's what's happening.

Ada code

Send_Message;

C code

void test (void) {

printf("In test.\n");

}

void Send_Message (void) {

printf("In send message."\n);

//This works fine.

test;
//It crashes when I try and call test.
}

Does anyone know why this is happening, and how to fix it?
It's important that we use the GNAT compiler to link into
it.



**** Posted from RemarQ - http://www.remarq.com - Discussions Start Here (tm) ****

Re: Interfacing Ada to C

[Steve Quinlan]

Assuming this is a job-related thing and not personal or academic, if it is important
that you use GNAT, then don't you (meaning your company) have a support contract with
ACT to deal with situations like this?