New to ada95: porting

New to ada95: porting

[Al Johnston]

I am starting to look at what it will take to port our ada8X code to an
ada95
compiler.  The code does a lot of interfacing between ada and c.
Regrettably
it does this in various way... most all of them are compiler
implementation
dependent.

I am trying to figure out the best way of interfacing various data types
and
have really gotten bogged down.  Is there a faq or howto on this topic
somewhere?

things of particular interests are
1) access types to 1-d unconstrained arrays
2) access types to 1-d unconstrained array whose elements are also
1-d unconstrained arrays.
3) using 'address on an ada string type when interfacing to a c
* char type
4) generation of ada strings by c-code (via calls to ada library
linked into a c program)


thanks

Re: New to ada95: porting

[james hopper]

In article <38BC5237.91FD3B95@mindspring.com>, Al Johnston
<sofeise@mindspring.com> wrote:
> it occupies the 4 longwords (128 bits) before the beginning
> of the data.  when you deference a pointer to the object
> or do a 'address on the object the address given is the
> address at the start of the data.  'size is the size of the
> data, excluding the size of the dope vector.  The
> vector is:
> 
>     size of Element
>     lower bound
>     upper bound
>     num of bytes occupied by data
> 


Al,

post the data structure for the dope vector and perhaps we can come up
with something more concreate.

jim

Re: New to ada95: porting

[James S. Rogers]

Al Johnston wrote in message <38BAF3B2.69D7A905@mindspring.com>...
>things of particular interests are
>1) access types to 1-d unconstrained arrays
>2) access types to 1-d unconstrained array whose elements are also
>1-d unconstrained arrays.
>3) using 'address on an ada string type when interfacing to a c
>* char type
>4) generation of ada strings by c-code (via calls to ada library
>linked into a c program)


Look at the standard C interface utilities in the packages
Interfaces.C and Interfaces.C.Pointers.

Interfaces.C provides a lot of commonly needed conversions, including
to and from C strings.

Interfaces.C.Pointers is a generic package providing a wealth of C-style
operations on pointers.

When in doubt read the Reference Manual.

Jim Rogers
Colorado Springs, Colorado

Re: New to ada95: porting

[tmoran]

>type NSV is array(positive range <>) of ordinal
>type NSVP is access NSV;
>type NI is record
>    id : positive
>    h : NSVP;
>end record;
>type HSV is array(positive range <>) of NI
>type HSVP is access HSV;
>
>This is used in an ada routine that calls a c routine.  currently
>the c routine allocates the memory (including two different
>types of dope vectors) and loads the structure and returns
>it as a pointer, so when the ada code receives its value
>for the inout arg of HSVP it thinks the unconstrained
>array parts are "normal" ada unconstrained arrays.
  So you have something like
    function In_C return  HSVP;
    pragma import(C, In_C, "InC");
and after calling it you can run the code:
and you can run the code
  P : HSVP := In_C;
begin
  for i in P.all'range loop
    Ada.Text_IO.Put_Line("id" & integer'image(P.all(i).id));
    for j in P.all(i).h.all'range loop
      Ada.Text_IO.Put_Line(ordinal'image(P.all(i).h.all(j)));
    end loop;
  end loop;
and it works?
  If the dope vector stuff as built by your C code does not match
what your (new) Ada compiler wants, you'll have to either change
the C to make something that does match, or else change the Ada
spec to match what the C code generates.  Have you decided on
the latter?  In which case the problem seems to be "how do I
specify in Ada 95 a data structure that matches the thing
returned by In_C", possibly ignoring some dope vector info while,
for instance, using other parts as discriminants to specify
array sizes.
  Or do you instead wish to leave the old Ada specs alone, but
change the C code to build the data structures those specs
now lead to?
  What did the old (publicly specified) dope vectors look like?
Do you have a lot of similar structures, or is the HSVP one
a worst case?

Re: New to ada95: porting

[Al Johnston]

> Look at the standard C interface utilities in the packages

Thanks, I have... I just don't know what to do with them..

for example:
1) cohen's book give an example of an interface to getenv() using
IF.C.Strings, but the gnat adainc code doesn't both with this
level, favoring a 'address of an unconstrained array.

2) how in the world do you implement a c char** as a
parameter in a procedure call?

3) I have a lot of these types of things in my current (8x) ada
code:

type NSV is array(positive range <>) of ordinal
type NSVP is access NSV;
type NI is record
    id : positive
    h : NSVP;
end record;
type HSV is array(positive range <>) of NI
type HSVP is access HSV;

This is used in an ada routine that calls a c routine.  currently
the c routine allocates the memory (including two different
types of dope vectors) and loads the structure and returns
it as a pointer, so when the ada code receives its value
for the inout arg of HSVP it thinks the unconstrained
array parts are "normal" ada unconstrained arrays.

Obviously, this is very nasty... and I have no expectation
that it will work under gnat (this stuff was written long ago
for sunAda; sun published there "dope vector" format and
my predecessor took advantage of it... and now I get to
pay).

Anyway, the above is the class of thing I am having trouble
figuring out how to re-code.  I desperately need an example
of the right way of doing this.  I was thinking about using
IF.C.Pointers on this one... but the outer private "element"
has a component that would need to be a inner private
"element" and at that point I get lost.


Well, those are the major types of issues that I am
confused on...

tnx for any guidance... at the moment recoding everything
in c is looking attractive.  We have a hell of a lot of these
types of structures (they are related to RPC client code).

-al


>

> When in doubt read the Reference Manual.

I don't have a problem reading the RM.... understanding it, however, is
another story :{

-al

Re: New to ada95: porting

[Al Johnston]

Most of your questions are TBD at this point... I don't have enough
info yet on what and were the problems are or how to do this
in ada95 yet.  I am spending must of my time analyzing my source
to find where the problems are and what does my universe of
"problem" structures look like.  the one I gave you is typical,
but most of the stuff is a lot simpler... but there are quite a few
of this level of complexity and a half dozen or so that are
worse (2d unconstrained arrays).

I would have to look up the real definition which covers
any dimension unconstrained array... but for the 1-d case
it occupies the 4 longwords (128 bits) before the beginning
of the data.  when you deference a pointer to the object
or do a 'address on the object the address given is the
address at the start of the data.  'size is the size of the
data, excluding the size of the dope vector.  The
vector is:

    size of Element
    lower bound
    upper bound
    num of bytes occupied by data

the last entry is derivable from the first 3, and does not include the
size of the dope vector itself.

>   What did the old (publicly specified) dope vectors look like?
> Do you have a lot of similar structures, or is the HSVP one
> a worst case?

Re: New to ada95: porting

[tmoran]

If it doesn't cost too much in data copying, could you make a few
wrapper functions to take the C results, copy the data into an
Ada object, free the C allocated memory, and return the Ada object,
along the lines:

  type A is array(index_type <>) of some_element;

  function Wrapped_C_Fun(Params:whatever) return A is
    use System.Storage_Elements;
    Dope_Offset : constant Storage_Offset := 16; -- 128/8 bit Storage_Elements
    type Dummy_A is A(0 .. index_type'last);  -- fixed, though large, size
    package Addr_Acc_Dummy_A is new
      System.Address_To_Access_Conversions(Dummy_A);
    type C_Returned_Ptr_Type is access Dummy_A;
    function C_Fun(Params:whatever) return C_Returned_Ptr_Type;
    pragma Import(C, C_Fun, "CFun");
    Data_Ptr : C_Returned_Ptr_Type := C_Fun(Params);  -- call the C function
    Data_Address : constant System.Address
      := Addr_Acc_Dummy_A.To_Address(Data_Ptr);
    Dope_Address : constant System.Address := Dope_Address - Dope_Offset;
    type Dope is record
      Size, Lower_Bound, Upper_Bound, Byte_Count : Integer;
      Data : Dummy_A;
    end record;
    for Dope use
      Size        at 0 range 0 .. 31;
      Lower_Bound at 4 range 0 .. 31;
      Upper_Bound at 8 range 0 .. 31;
      Byte_Count  at 12 range 0 .. 31;
      Data        at 16 range 0 .. (index_type'last+1)*some_element'size-1;
    end record;
    type Dope_Ptr_Type is access Dope;
    package Addr_Acc_Dope is new
      System.Address_To_Access_Conversions(Dope_Ptr_Type);
    Dope_Ptr : constant Dope_Ptr_Type
      := Addr_Acc_Dope.To_Access(Dope_Address);
    Result : A(Dope_Ptr.Lower_Bound .. Dope_Ptr.Upper_Bound);
  begin
    if Dope_Ptr.Size /= some_element'size then raise an_exception;end if;
    if Dope_Ptr.Byte_Count /= Result'size/8 then raise an_exception;end if;
    -- first copy the returned array from the C structure to an A.
    Result := Data_Ptr.all(0 .. Result'length-1);
    -- free the C memory
    C_Free(Dope_Ptr);
    -- return result of type A.
    return Result;
  end Wrapped_C_Fun;

Note: this code untested and written after midnight.

Re: New to ada95: porting

[Al Johnston]

> post the data structure for the dope vector and perhaps we can come up
> with something more concreate.

Not sure what your asking for here... what we use in ada our ada83
code that manipulates the the vector is as follows:

type Dope_Vector is
  record
    element_size : integer;
    low_bound   : integer;
    hight_bound : integer;
    array_size    : integer;
  end if;

The doc says the following:

an
  array(I_1, I_2, ... I_N) of element_type
has a dope vector as follows:

low addres (each cell a 32 bit entity)
    E_0 = element_size
    F_1 = I_1'first
    L_1 = I_1'last
    E_1 = (L_1-F_1-1) * E_0
    F_2 = I_2'first
    L_2 = I_2'last
    .
    .
    .
    F_N = I_N'first
    L_N = I_N'last
    E_N = (L_N-F_N-1) * E(N-1)
hi address

but our worst case is a 2-d version.