Re: Access type representations.

Re: Access type representations.

[Bob Wells #402]

G'day,
Thanks for all the responses to my question concerning alternative
representations of access type. It inded makes me realize my mistake
in simply using access types to interface to C pointers.
Once again thanks for the responses (both publicly to the list and
privately to me).
Bob W. (-:

Access type representations.

[Bob Wells #402]

G'day,
Getting back to that thread of using access types to interface with
pointers in C, David emery said that my assumption that the access
type in Ada does not necessarily have to contain the address.

My question is are there compilers out there that do *not* use the
address within the access type for the representation of the allocated
object? If there are, what do they use?

Thanks,
Bob W. (-:

Re: Access type representations.

[Tucker Taft]

In article <9410281131.AA15384@eurocontrol.de>,
Bob Wells #402  <wel@EUROCONTROL.DE> wrote:

>G'day,
>Getting back to that thread of using access types to interface with
>pointers in C, David emery said that my assumption that the access
>type in Ada does not necessarily have to contain the address.
>
>My question is are there compilers out there that do *not* use the
>address within the access type for the representation of the allocated
>object? If there are, what do they use?

There are three basic alternatives to addresses:

   1) the "offset" part of a segmented address;

      This makes sense on the old X86 architecture,
      where the full address requires two registers,
      but one could decide to put all heap data into
      a single segment.

   2) offsets relative to the beginning of the heap;

      This is similar to (1), but doesn't depend
      on the hardware having a segmented architecture.

   3) indices into a heap of same-sized objects.

      This is similar to (2), except that it reduces
      the number of bits needed for an access value even
      further by dividing the offset by the number of
      bytes per object.

(1) and (2) work when the heap is contiguous and of
some limited size, e.g. when the 'Storage_Size attribute
is specified for the access type.

I don't know how many compilers use the above alternatives.
I know some RR compilers used to use (1), and some Rational
compilers used to use (2) or (3).

>Thanks,
>Bob W. (-:

-Tucker Taft  stt@inmet.com
Intermetrics, Inc.

Re: Access type representations.

[Robert Dewar]

In addition to Tucker's list of non-pointer representations of access types,
consider also the GNAT representation for pointers to unconstrained types.
These are two words long, one word points to the template containing the
bounds, and the other word points to the data of the array. Eventually we
expect to change this second word so that it points to the virtual origin
of the array, instead of the actual origin, thus avoiding the need to
subtract lower bounds when indexing into the array, but we have not don
e this yet.

Re: Access type representations.

[Mitch Gart]

Bob Wells #402 (wel@EUROCONTROL.DE) wrote:

I have heard of compilers where an object of type "access string"
points to the string descriptor, rather than to the first 
character of the string.  Then the contents of the string are
reachable from the descriptor, either by being right next to the
descriptor in memory or through another level of indirection.

So I'm not sure what the answer would be to this question:

: Getting back to that thread of using access types to interface with
: pointers in C, David emery said that my assumption that the access
: type in Ada does not necessarily have to contain the address.

In this case, 

- yes, the Ada access object is a 32-bit address of a part of the 
  object, like a C pointer, but 
  
- no, the Ada access object doesn't contain the address of the 
  first character of the string like the C pointer.

If you want to pass the address of an Ada string to a C function,

    func(s(s'first)'address)

should work for all compilers.

	Mitch Gart

Re: Access type representations.

[Robert Dewar]

Note also that in Ada 9X, for a function that is pragma Interfaced C, 
parameters of type Char_Array are required to be passed by passing the
address of the first element.

Note that GNAT does not yet do this correctly (it's on the list!), and in
fact our plan is that for any function that has convention C, we will
pass unconstrained arrays by simply passing the address of the first 
element.

It is of course possible to use pragma Interface (Ada, .. and still write
the body in C, and then the C function must know exactly how Ada passes
unconstrained parameters.

Re: Access type representations.

[Keith Thompson]

In <CyE7DD.5J8@inmet.camb.inmet.com> mg@asp.camb.inmet.com (Mitch Gart) writes:
> If you want to pass the address of an Ada string to a C function,
> 
>     func(s(s'first)'address)
> 
> should work for all compilers.

Unless s is a null string (i.e., s'length = 0); in this case, evaluation
of s(s'first) will raise Constraint_Error.

In practice, this isn't generally a problem for passing Ada strings
to C functions.  Since most C string functions expect nul-terminated
strings, the Ada code generally needs to append an ASCII.NUL character
to the string, which guarantees that it's non-null.

-- 
Keith Thompson (The_Other_Keith)  kst@alsys.com
TeleSoft^H^H^H^H^H^H^H^H Alsys, Inc.
10251 Vista Sorrento Parkway, Suite 300, San Diego, CA, USA, 92121-2718
/user/kst/.signature: I/O error (core dumped)