Ada to C++: Pass an unsigned 64-bit value

8
votes

I need to pass 2 pieces of data from an Ada program to some C++ code for processing.

  • Data - double.
  • Time - unsigned 64 bits.

I was able to make a procedure in Ada that worked with my C++ method using a Long_Float (double in C++) and Integer (int in C++, obviously not 64-bits though). I used the following code (code not on me so syntax might be slightly off):

procedure send_data (this : in hidden_ptr; data : in Long_Float; time : in Integer);
pragma import (CPP, send_data, "MyClass::sendData");

Now that that's working, I'm trying to expand the time to the full 64-bits and ideally would like to have an unsigned long long on the C++ side. I don't see any types in Ada that match that so I created my own type:

type U64 is mod 2 ** 64;

When using that type with my send_data method I get an error saying there are no possible ways to map that type to a C++ type (something along those lines, again don't have the code or exact error phrase on me).

Is there a way to pass a user-defined type in Ada to C++? Perhaps there's another type in Ada I can use as an unsigned 64-bit value that would work? Is there a way to pass the address of my U64 type as a parameter to the C++ method instead if that's easier? I'm using the green hills adamulti compiler v3.5 (very new to ada, not sure if that info helps or not). Examples would be greatly appreciated!

1
c++interfaceada
mod 2 ** 64 should be correct. When I compile your example using that type with GNAT, it doesn't complain. Perhaps your Ada compiler doesn't think that C++ (or the C++ compiler it targets) supports a 64-bit unsigned type; standard C++ didn't get unsigned long long until the 2011 ISO standard. - Keith Thompson
@KeithThompson - Bah! Make these good comments of yours answers Keith, so my upvotes mean something, I can properly comment on them, and they can be accepted if they end up being the answer. - T.E.D.
You could try adding pragma Convention (CPP, U64);. - Simon Wright
Is your time actually one field or is it a record structure with seconds & milliseconds fields ? If so you could split it easily into 2 parameters... - NWS
Had a bit of time to play around with it again today. @Simon Wright Unfortunately pragma convention (CPP, U64) had no noticeable effect that I could see when added, received the same errors with everything I tried. - Xeelot

1 Answers

1
votes

As an addendum to @KeithThompson's comment/answer...

Ada's officially supported C interface types are in Interfaces.C, and there's no extra-long int or unsigned in there (in the 2005 version. Is the 2012 version official yet?).

You did the right thing to work around it. If your compiler didn't support that, more drastic measures will have to be taken.

The first obvious thing to try is to pass the 64-bit int by reference. That will require changes on the C side though.

I know C/C++ TIME structs tend to be 64-bit values, defined as unioned structs. So what you could do is define an Ada record to mimic one of those C structs, make sure it gets laid out the way C would (eg: with record representation and size clauses), and then make that object what your imported routine uses for its parameter.

After that you'll have to pull nasty parameter tricks. For example, you could try changing the Ada import's side of the parameter to a 64-bit float, unchecked_converting the actual parameter into a 64-bit float, and trying to pass it that way. The problem there is that a lot of CPU's pass floats in different registers than ints. So that likely won't work, and if it does it most certianly isn't portable.

There may well be other ways to fake it out, if you figure out how your compiler's CPP calling convention works. For example, if it uses two adajacent 32-bit registers to pass 64-bit ints, you could split your Ada 64-bit int into two and pass it in two parameters on the Ada side. If it passes 64-bit values by reference, you could just tell the Ada side that you're passing a pointer to your U64. Again, these solutions won't be portable, but they would get you going.