From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.5-pre1 (2020-06-20) on
	ip-172-31-74-118.ec2.internal
X-Spam-Level: 
X-Spam-Status: No, score=-1.9 required=3.0 tests=BAYES_00 autolearn=ham
	autolearn_force=no version=3.4.5-pre1
Date: 18 Aug 93 12:55:40 GMT
From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail
!alcyone!rgilbert@ucbvax.Berkeley.EDU  (Bob Gilbert)
Subject: Re: Data Overlays
Message-ID: <1993Aug18.125540.1393@iplmail.orl.mmc.com>
List-Id: <comp.lang.ada>

In article C64@irvine.com, adam@irvine.com (Adam Beneschan) writes:
>In article <1993Aug17.202435.20364@iplmail.orl.mmc.com> rgilbert@orl.mmc.com 
>(Bob Gilbert) writes:
>
>>   The problem I have with using Unchecked_Conversion is that I beleive that
>>   it produces an additional copy of the data. . . .
>
>Only if you're using an inferior compiler.  A good compiler should
>recognize Unchecked_Conversion and use it to treat the data at
>whatever address as an object of whatever type.  It shouldn't generate
>a copy or any other code.
>
>Check the code your compiler is producing.  If it's generating code to
>copy the object, call your compiler vendor and bawl them out for
>stupidity.  :-)  (Don't mind me, I'm in an intolerant mood today.)
>
>                                -- Adam
>
>--
>The above opinions are my own and do not necessarily reflect the
>opinions of Irvine Compiler Corporation.
>
>

Well OK, the Unchecked_Conversion function by itself does not produce a
copy of the data, but the return parameter is either being assigned to some
other object (copy) or it can only be used for a comparison for some decision.
Also the return parameter is going to be the entire object, not just the
element of the object that is of interest.  Unchecked_Conversion provides
read-only access, I can't write to the same object using different types.
For the purpose of producing a true data overlay, I don't see how using
Unchecked_Conversion is going to accomplish this.

As far as the technique of:

       X : TYPE_1;
       Y : TYPE_2;
       for Y use at X'address;

The LRM 13.5 states that address clauses should not be used to achieve overlays
of objects...  Any program using address clauses to achieve such effects is
erroneous.  What is the rationale for this?

Now I understand that there could be potential problems using the above 
technique because of various optimization and code generation methods used by
the compiler that could result in a delayed store (value assigned still held
in a register and not accually written to memory).  Also I could envision
problems when using processors which make use of cache.  But there should
be some method (pragma) to insure that an assignment truely affects the
mapped memory location.  Heck, the compiler is smart enough to caution me
about using the above method, I think it could take the precautions necessary
to make this safe.

Still looking for a proper method to produce a data overlay.

                             Bob