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 16:27:29 GMT From: sampson@cod.nosc.mil (Charles H. Sampson) Subject: Re: Data Overlays Message-ID: <1993Aug18.162729.12036@nosc.mil> List-Id: 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