Re: SOLVED! Decoupled Mutual Recursion Challenger

[bobduff@dsd.camb.inmet.com (Bob Duff)]

In article <1994Oct17.205244.17450@swlvx2.msd.ray.com>,
John Volan <jgv@swl.msd.ray.com> wrote:
>bobduff@dsd.camb.inmet.com (Bob Duff) writes:
>
>>There is no requirement that type Address have the same representation
>                                                         ^^^^^^^^^^^^^^
>>as an access type.  In fact, there is no requirement that one access
>>type have the same representation as another access type.  There are, in
>                    ^^^^^^^^^^^^^^
>>fact, compilers that take advantage of this.  I believe that GNAT, for
>>example, stores access-to-unconstrained-arrray differently from
>>access-to-integer.
>
>I guess the question really hinges on the meaning of the word
>"representation".  When you say that two access types may be "stored
>differently", do you mean that the number of bits used to store an
>access type can be different, or do you only mean that the *contents*
>of those bits might be interpreted differently?

I meant both.  The number of bits can be different, and the meaning of
those bits can be different.

>All I really need is the relatively weak guarantee that all access types
>occupy the same number of bits, i.e.:
>
>    A1'Size = A2'Size, for any two access types A1 and A2

Sorry.  Ada makes no such guarantee.  In practice, you might be able to
write portable code across *many* (but not all) implementations,
especially if you're willing to restrict the designated type of the
access type.  After all, most implementations don't read the phase of
the moon clock to decide how many bits to use for a give type.

>(And perhaps this size is the same as System.Address'Size, but I don't
>even need that guarantee.)  If it's reasonably portable to assume
>that all access types occupy the same number of bits, then we can have
>a "dummy" access type act as a "black box" to store the bit-pattern
>of any other access type, via Unchecked_Conversion.  In other words,
>can we guarantee the following:
>
>    To_A1 (To_A2 (V1)) = V1
>
>where V1 is any value of access type A1, and
>
>    function To_A1 is new Ada.Unchecked_Conversion (A2, A1);   
>    function To_A2 is new Ada.Unchecked_Conversion (A1, A2);   
>
>That's all that my Identity package needs.

I'm not real clear on what you're trying to do, so I don't have much
useful advice here.  Perhaps Address_To_Access_Conversions would be of
some help?

>I do *not* need the much stronger guarantee that the *contents* of an
>address value be equivalent to the *contents* of a corresponding
>access value, i.e.:
>
>    For any object X of some designated type D:
>
>        X'Access = X'Address
>
>Evidently, Ada makes no such guarantee.  (For instance, X'Access might
>be an offset in longwords from the start of some storage pool, while
>X'Address might be an offset in storage units from the start of
>memory.

Right.  But one of those offsets might fit in 16 bits, while the other
fits in 32 bits.

> ...Or, if D is an unconstrained array type, X'Address might be
>the location where the first component of X resides, whereas X'Access
>might be the location where the "dope" of X begins.  I take it that
>the possibility of these kinds of variances are the rationale for the
>package System.Storage_Units.Address_To_Access_Conversions in
>RM9X-13.7.1;5.0.)  

Yes.

>At any rate, this stronger guarantee is *not* a requirement of my
>Identity package, whether you go with the System.Address implementation
>or the access-to-dummy-type implementation.  All we need is a portable
>way to "opaquely" store the bits of an access value.

GNAT stores an access-to-unconstrained array as a pair consisting of
address-of-dope, address-of-data.  So these things are twice the size of
other access types.  (One could imagine doing something similar for
discriminated and/or tagged types, but I don't think GNAT does.)  In the
unc-array case, the address-of-data is actually the address of the
zero-th element of the array (even if the array has no such element),
which makes indexing operations faster, because there's no need to fetch
the lower bound and subtract.

I'm not *sure* of the details of the GNAT implementation -- Robert,
please correct me if I'm wrong.

Another implementation I've heard about (from Rational, I think?),
creates a separate storage pool for every access type, and uses various
virtual memory tricks to make that efficient.  Access types end up being
represented in various numbers of bits, I believe.

Nonetheless, *most* implementations implement *most* access types as an
address, so in *many* cases, your code will work.  But you can't count
on it being portable in all cases.

- Bob
-- 
Bob Duff                                bobduff@inmet.com
Oak Tree Software, Inc.
Ada 9X Mapping/Revision Team (Intermetrics, Inc.)