Re: Data Overlays

[sampson@cod.nosc.mil (Charles H. Sampson)]

In article <1993Aug18.125540.1393@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wri
tes:
>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.)
>
>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.

     You're having a problem separating the semantics of Unchecked_conversion
from the way it's implemented.  Its semantics are those of a function, with a
return value.  It's almost never implemented that way.  The bucket of bits
lying in memory is simply looked at as though it represents a different data
structure.

     In order to write to the object, you only need to define the inverse
unchecked conversion.  You originally needed Structure_as_byte_array.  Now
you need Byte_array_as_structure.

>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 overlay
s
>of objects...  Any program using address clauses to achieve such effects is
>erroneous.  What is the rationale for this?

     The rationale is to avoid overlays, which engender horrendous mainten-
ence costs.

>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.

     Actually, cache memory is no problem (in a correct program), at least
from the user's viewpoint.  The compiler writer has to make the program work
as specified in the LRM, even if the hardware guys have thrown him a curve.

     As for the compiler being smart enough, it certainly could be, if the
language required it to be.  However, the designers have prohibited over-
laying and restricted to the greatest degree practical other forms of
aliasing.  A very wise choice, IMNSVHO.

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

     Don't.  Your love of the overlay leads me to believe that you've never
had to maintain code that uses overlaying.  I estimate that aliasing in gen-
eral is the single greatest source of bugs in programs.  Ada gives you 
Unchecked_conversion, which is a self-documenting way of looking at a datum
from two different points of view.  If you need to overlay to share memory
in a record structure, variant records are available.  If you need to over-
lay to avoid permanently allocating memory to objects that don't need to be
around permanently, the block statement is available.  I've been programming
in Ada for a number of years now, in some cases very close to the bare hard-
ware, and I haven't seen the need for an overlay yet.

				Charlie