From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.8 required=5.0 tests=BAYES_00,INVALID_DATE autolearn=no autolearn_force=no version=3.4.4 X-Google-Language: ENGLISH,ASCII-7-bit X-Google-Thread: 1108a1,93fa00d728cc528e X-Google-Attributes: gid1108a1,public X-Google-Thread: 103376,93fa00d728cc528e X-Google-Attributes: gid103376,public X-Google-ArrivalTime: 1994-10-19 12:05:04 PST Newsgroups: comp.lang.ada,comp.object Path: bga.com!news.sprintlink.net!howland.reston.ans.net!europa.eng.gtefsd.com!news.mathworks.com!noc.near.net!inmet!dsd!bobduff From: bobduff@dsd.camb.inmet.com (Bob Duff) Subject: Re: SOLVED! Decoupled Mutual Recursion Challenger Message-ID: Sender: news@inmet.camb.inmet.com Organization: Intermetrics, Inc. References: <1994Oct12.224944.25566@swlvx2.msd.ray.com> <1994Oct17.154812.9104@swlvx2.msd.ray.com> <1994Oct17.205244.17450@swlvx2.msd.ray.com> Date: Mon, 17 Oct 1994 22:10:47 GMT Xref: bga.com comp.lang.ada:7097 comp.object:7568 Date: 1994-10-17T22:10:47+00:00 List-Id: In article <1994Oct17.205244.17450@swlvx2.msd.ray.com>, John Volan 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.)