Data Overlays

Data Overlays

[Bob Gilbert]

Thanks to those who replied to my earlier post about exceptions occuring
in the declarative region.

Now I've got another one:

Many times I have wanted to create two different types to look at the
same object.  An example might be a record structure which is to be
output via some DMA device which expects the data to look like an 
array of bytes.  Anyway I've come up with two different methods to
implement this.

Method 1 :  Use an access type of one of the types and assign the address
            (using unchecked conversion) of the object declare of the
            other type.

      type SAMPLE_REC_TYPE is
        record                                      -- Size is
          Word_1  : INTEGER;                           -- 32 +
          Word_2  : SOME_32_BIT_TYPE;                  -- 32 +
          Word_3  : SOME_OTHER_32_BIT_TYPE;            -- 32 +
          Word_4  : MORE_32_BIT_STUFF;                 -- 32 +
          Word_5  : A_16_BIT_TYPE;                     -- 16 +
          Word_6  : A_16_BIT_TYPE;                     -- 16 =
        end record;                                    -- 160 bits

      for SAMPLE_REC_TYPE'size use 160;   -- Guarantees known size

      ---------------------------------------------
      -- Declare array type of appropiate size to -
      -- map to above record definition.          -
      ---------------------------------------------     
      Sample_Rec_Words : constant := SAMPLE_REC_TYPE'size / 8;

      type BYTE_ARRAY_TYPE is array (1 .. Sample_Rec_Words) of BYTE;
      pragma Pack(BYTE_ARRAY_TYPE);

      type INT_ARRAY_PTR is access BYTE_ARRAY_TYPE;

      ---------------------------------------------
      -- Declare Unchecked_Conversion function to -
      -- permit assigning the address of X to Y.  -
      --         Y := X'address;                  -
      ---------------------------------------------
      function To_Ptr is new Unchecked_Conversion(ADDRESS, INT_ARRAY_PTR);

      ------------------------------------
      -- Declare object of record type   -
      -- and access object of array type -
      ------------------------------------
      X : SAMPLE_REC_TYPE;
      Y : INT_ARRAY_PTR := To_Ptr(X'address);     -- Don't use 'new'

   I have used this method on several occasions and it works just fine.  Howeve
r,
   it does seem a little complicated and makes the assumption that an object
   of an access type is implemented using the address of the object.

Method 2:  Just use a representation clause to map one of the objects to the
           address of the other.

      X : SAMPLE_REC_TYPE;
      Y : BYTE_ARRAY_TYPE;
      for Y use at X'address;

   This seems to be much more straight forward and makes no assumptions about
   the implementation.  But when this method is used a compiler (Telesoft)
   warning is issued to the affect that the representation clause should not
   be used to produce overlayed data?

Question:  Which of the above methods is prefered?  Is there a better way?

                           Bob

Re: Data Overlays

[cgl!sgiblab!darwin.sura.net!mlb.semi.harris.com!x102a!scook]

In article <1993Aug13.124835.18422@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr
ites:
>    *** Stuff Deleted *** 
>
>Many times I have wanted to create two different types to look at the
>same object.  An example might be a record structure which is to be
>output via some DMA device which expects the data to look like an 
>array of bytes.  Anyway I've come up with two different methods to
>implement this.
>
>Method 1 :  Use an access type of one of the types and assign the address
>            (using unchecked conversion) of the object declare of the
>            other type.
>
>   I have used this method on several occasions and it works just fine.  Howev
er,
>   it does seem a little complicated and makes the assumption that an object
>   of an access type is implemented using the address of the object.
>
>Method 2:  Just use a representation clause to map one of the objects to the
>           address of the other.
>
>      X : SAMPLE_REC_TYPE;
>      Y : BYTE_ARRAY_TYPE;
>      for Y use at X'address;
>
>   This seems to be much more straight forward and makes no assumptions about
>   the implementation.  But when this method is used a compiler (Telesoft)
>   warning is issued to the affect that the representation clause should not
>   be used to produce overlayed data?
>
>Question:  Which of the above methods is prefered?  Is there a better way?
>
>                           Bob

My first question is why not use Unchecked Conversion?  Do you have some size
or time constraints?  I have used something similar to your method 2, so I'll
address just that one....Note that in the RM 13.5 states "Address clauses
should not be used to achieve overlays of objects...Any program using address
clauses to achieve such effects is erroneous." 

In my embedded work I have had need to perform some low-level operations on the
hardware ( accessing devices, RAM tests, ect.) and have used run-time 
elaboration of memory-mapped objects successfully.  Consider the following:

	procedure Write_HW_Register(
	  Destination_Address : in system.address;
	  Value               : in integer ) is
	
	Register : integer;
	for Register use at Destination_Address;

	begin
	  Register := Value;
	end Write_HW_Register;

You can take this concept further and write simple routines that some
people might implement in assembly (How about a Move Data routine with
two addresses and a size...).  Be aware you can get yourself into some trouble
with this one. :)

I'll let other people argue against using this, but I would rather code these
things in Ada and be able to reuse them on different architectures than
rewrite them each time in assembley.

Stephen R. Cook
Harris Government Aerospace    

Re: Data Overlays

[Charles H. Sampson]

In article <1993Aug13.124835.18422@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr
ites:
>
>Many times I have wanted to create two different types to look at the
>same object.  An example might be a record structure which is to be
>output via some DMA device which expects the data to look like an 
>array of bytes.  Anyway I've come up with two different methods to
>implement this.
>
>Method 1 :  Use an access type of one of the types and assign the address
>            (using unchecked conversion) of the object declare of the
>            other type.
>
> [Example deleted]
>
>Method 2:  Just use a representation clause to map one of the objects to the
>           address of the other.
>
>      X : SAMPLE_REC_TYPE;
>      Y : BYTE_ARRAY_TYPE;
>      for Y use at X'address;
>
>   This seems to be much more straight forward and makes no assumptions about
>   the implementation.  But when this method is used a compiler (Telesoft)
>   warning is issued to the affect that the representation clause should not
>   be used to produce overlayed data?
>
>Question:  Which of the above methods is prefered?  Is there a better way?

     If you truly have to look at the data structure from two different
aspects, use Unchecked_conversion.  That's what it's there for.  There
seems to be an opinion circulating that Unchecked_conversion is a feature
of Ada that should never be used.  Not so.  It's in the language precisely
for the kind of situation described.  On the other hand, it should not be
used for some cutesy trick whose effect can be easily achieved in some
other, more portable, fashion.

     There are some portability considerations, because the exact rules on
which types can participate in unchecked conversions are implementation
dependent.  In my experience, compilers allow unchecked conversions between
most types of the same size.  I'm sure there are exceptions to my experience.

     I don't see any advantage in using Unchecked_conversion on the access
types instead of the record structures themselves.  The indirection adds a
level of obscurity, whereas a straightforward use of Unchecked_conversion
says, "Hey, look.  I'm approaching this bucket of bits from a different
point of view."

     As for creating an overlay by using an address clause, here's the kind
of problem you could get into.  Consider the following very simplified
example:

          X : Integer;
          Y : Integer:
          FOR X USE AT Y'Address;

          X := 1;
          ...
          IF Y = 1 THEN ...

It might be that your compiler, using standard code generation techniques,
is using a delayed store on the value of X, which means basically that the
1 is held in a register for a period of time rather than being immediately
placed into the memory location of X.  As a result, Y does not have the
expected value when the IF statement is executed.  Since the overlaying has
created an erroneous program, the compiler writers are not obligated to
take it into account in their code generation schemes, which is a blessing
if you've every had to consider all the side effects of overlaying.  As a
matter of fact, since this program is erroneous, the compiler writers are
legally allowed to do bizarre things, such as erasing your disk, but that's
another story.

                              Charlie

Re: Data Overlays

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!cs.utexa]

In article <1993Aug13.124835.18422@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr
ites:
>
>Many times I have wanted to create two different types to look at the
>same object.  An example might be a record structure which is to be
>output via some DMA device which expects the data to look like an 
>array of bytes.  Anyway I've come up with two different methods to
>implement this.
>
			.
			.
>
>Method 2:  Just use a representation clause to map one of the objects to the
>           address of the other.
>
>      X : SAMPLE_REC_TYPE;
>      Y : BYTE_ARRAY_TYPE;
>      for Y use at X'address;
>
>   This seems to be much more straight forward and makes no assumptions about
>   the implementation.  But when this method is used a compiler (Telesoft)
>   warning is issued to the affect that the representation clause should not
>   be used to produce overlayed data?
>


O.k., Here's my problem:

I have a system which receives "messages" from a number of other
systems. The messages come via POSIX queues. On any one queue, I
can receive a number of different messages, mostly with record
structures defined by the C code where the message originated.

I do not know a priori what the next message will be. I have to
"receive" the message into a Byte_Array. Once I have the message,
I can access a standard header and extract a message identifier,
which then tells me what kind of message I've just received.
Once I have a message in a Byte_Array, and once I know what kind
of message it is, I can then convert the message to an Ada record
which has the right structure for the message.

I've considered both methods above. Certainly, Unchecked_Conversion
is one alternative. But I have used another method which seems to
work, seems to be portable, and, moreover, SEEMS to be in line with
what the language designers intended. To wit:

Given an Ada type, Messages:

generic
  type Byte_Arrays is private;
function Extract_Message ( A_Message : in Byte_Arrays ) return Messages;

where the body looks like

function Extract_Message ( A_Message : in Byte_Arrays ) return Messages is
  Temp_Message : Messages;
  for Temp_Message use at A_Message'address;
begin
  return Temp_Message;
end Extract_Message;

In many cases, I have actually created a more "Ada-like" message
type, and I do far more than just return the C structure.

I like the "feel" of this method. It uses the representation
specification which allows a structure to be placed "at" an address.
If this usage is not what the language designers had in mind, then
what was the purpose of the rep spec?

Is there any inherent danger or "wrongness" in this technique? And
yes, I have read the "for the purpose of overlaying....erroneous"
section in the LRM. Is this overlaying? Is it erroneous?

Incidently, I use this same technique in bindings where I have to
deal with structures created in C. The C code malloc's the memory
and places structs in it, and then just passes back the C pointer.
I make the assumption (possibly in error in some cases) that a C
pointer and a System.Address are coincident. Then I can calculate
the address in the malloc'ed memory where a specific C structure
exists, and I can assign an Ada record "at" that address in order
to extract the information from it.

This technique evokes no complaints from the DEC compiler, and it
seems to work properly. We're running ULTRIX workstations.

Comments/observations/suggestions (hell, maybe even a flame or two
8-{) would be appreciated.

Regards,

Bill Lee

(Not at work, at home. We're so damned secure there that it's hard
to work!)

bill@leeweyr.sccsi.com

Re: Data Overlays

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!math.ohio-state.edu!howland.]

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.

Re: Data Overlays

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!usenet.ins.cwru.edu!agate!do]

In article <1993Aug18.003940.2208@leeweyr.sccsi.com> bill@leeweyr.sccsi.com 
(Bill Lee) writes:

>   O.k., Here's my problem:
>
>   I have a system which receives "messages" from a number of other
>   systems. The messages come via POSIX queues. On any one queue, I
>   can receive a number of different messages, mostly with record
>   structures defined by the C code where the message originated.
>
>   I do not know a priori what the next message will be. I have to
>   "receive" the message into a Byte_Array. Once I have the message,
>   I can access a standard header and extract a message identifier,
>   which then tells me what kind of message I've just received.
>   Once I have a message in a Byte_Array, and once I know what kind
>   of message it is, I can then convert the message to an Ada record
>   which has the right structure for the message.
>
>   I've considered both methods above. Certainly, Unchecked_Conversion
>   is one alternative. But I have used another method which seems to
>   work, seems to be portable, and, moreover, SEEMS to be in line with
>   what the language designers intended. To wit:
>
>   Given an Ada type, Messages:
>
>   generic
>     type Byte_Arrays is private;
>   function Extract_Message ( A_Message : in Byte_Arrays ) return Messages;
>
>   where the body looks like
>
>   function Extract_Message ( A_Message : in Byte_Arrays ) return Messages is
>     Temp_Message : Messages;
>     for Temp_Message use at A_Message'address;
>   begin
>     return Temp_Message;
>   end Extract_Message;
>
>   In many cases, I have actually created a more "Ada-like" message
>   type, and I do far more than just return the C structure.
>
>   I like the "feel" of this method. It uses the representation
>   specification which allows a structure to be placed "at" an address.
>   If this usage is not what the language designers had in mind, then
>   what was the purpose of the rep spec?

I believe the purpose of the "for...use at" clause is to allow you to
declare data whose address is fixed by, say, the processor
architecture or the operating system.

>   Is there any inherent danger or "wrongness" in this technique? And
>   yes, I have read the "for the purpose of overlaying....erroneous"
>   section in the LRM. Is this overlaying? Is it erroneous?

Yep, it's overlaying, since you have two Ada objects (A_Message and
Temp_Message) that you've declared to be at the same location.

>   Incidently, I use this same technique in bindings where I have to
>   deal with structures created in C. The C code malloc's the memory
>   and places structs in it, and then just passes back the C pointer.
>   I make the assumption (possibly in error in some cases) that a C
>   pointer and a System.Address are coincident. Then I can calculate
>   the address in the malloc'ed memory where a specific C structure
>   exists, and I can assign an Ada record "at" that address in order
>   to extract the information from it.

I'm assuming here that you're using PRAGMA IMPORT_FUNCTION or
something to get at your C code.  If that's the case, why not just
make the Ada function declaration return an ACCESS type to the desired
Ada structure?  (Unless, of course, you don't know beforehand which
Ada type the C function result will point to.)  You shouldn't even
have to worry about possible differences in representation between a C
pointer and an Ada access object; DEC Ada is good at taking care of
those things for you.

                                -- Adam

Re: Data Overlays

[cis.ohio-state.edu!math.ohio-state.edu!howland.reston.ans.net!europa.eng.gtefsd.com!fs7.ece.cmu.edu!news.sei.cmu.edu!firth]

In article <1993Aug18.003940.2208@leeweyr.sccsi.com> bill@leeweyr.sccsi.com (Bi
ll Lee) writes:

>function Extract_Message ( A_Message : in Byte_Arrays ) return Messages is
>  Temp_Message : Messages;
>  for Temp_Message use at A_Message'address;
>begin
>  return Temp_Message;
>end Extract_Message;

As one who, when writing a compiler many years ago, took great pains to
ensure that this construct would work, I can sympathise with the above.

It is formally incorrect, but as far as I can see should work in all
reasonable circumstances, regardless of whether the parameters are
passed by value or by reference.  Of course, some compilers will
screw up when handling the return value, but that's their problem.

However, be warned that this approach might be a lot less efficient
than necessary - you could have upto two copies of the data in the
byte array.  That's the main reason I prefer to solve a problem such
as this by means of Unchecked_Conversion on addresses - I know that
there is no unnecessary copying; I'm keeping the data in the buffer
and simply looking at it through new spectacles, as it were.

Re: Data Overlays

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail]

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

Re: Data Overlays

[Charles H. Sampson]

In article <1993Aug18.085053.940@sei.cmu.edu> firth@sei.cmu.edu (Robert Firth) 
writes:
|>In article <1993Aug18.003940.2208@leeweyr.sccsi.com> bill@leeweyr.sccsi.com (
Bill Lee) writes:
|>
|>>function Extract_Message ( A_Message : in Byte_Arrays ) return Messages is
|>>  Temp_Message : Messages;
|>>  for Temp_Message use at A_Message'address;
|>>begin
|>>  return Temp_Message;
|>>end Extract_Message;
|>
|>As one who, when writing a compiler many years ago, took great pains to
|>ensure that this construct would work, I can sympathise with the above.
|>
|>It is formally incorrect, but as far as I can see should work in all
|>reasonable circumstances, regardless of whether the parameters are
|>passed by value or by reference.  Of course, some compilers will
|>screw up when handling the return value, but that's their problem.

     No it's not.  The program is erroneous and compiler writers are
not required to spend time making it "work right".

|>However, be warned that this approach might be a lot less efficient
|>than necessary - you could have upto two copies of the data in the
|>byte array.  That's the main reason I prefer to solve a problem such
|>as this by means of Unchecked_Conversion on addresses - I know that
|>there is no unnecessary copying; I'm keeping the data in the buffer
|>and simply looking at it through new spectacles, as it were.

     Certainly the technique I prefer.

				Charlie

Re: Data Overlays

[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

Re: Data Overlays

[cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmail]

Bill Lee (bill@leeweyr.sccsi.com) wrote:
: In article <1993Aug13.124835.18422@iplmail.orl.mmc.com>
: rgilbert@orl.mmc.com writes:
: >
: >Many times I have wanted to create two different types to look at the
: >same object.
:
: O.k., Here's my problem:

: I have a system which receives "messages" from a number of other
: systems. The messages come via POSIX queues. On any one queue, I
: can receive a number of different messages, mostly with record
: structures defined by the C code where the message originated.

: I do not know a priori what the next message will be. I have to
: "receive" the message into a Byte_Array. Once I have the message,
: I can access a standard header and extract a message identifier,
: which then tells me what kind of message I've just received.

What about a variant record?  Language Lawyer question (my LRM is at
home):  are rep. specs allowed on variant records?  If so (and if you
have a single tag at any level that determines what the message is at
that level), use an address clause to store the data on the Byte_Array,
then use the variant to figure out what you've got.

Jim Crigler
-----------------------------------------------------------------------
It has been rumored that the U. S. Government has secretly deveolped
near light-speed space travel and is even now sending emmissaries
through the near parts of the galaxy to teach (American) English.  It
is estimated that the mission will be complete by the mid-23rd century.

Re: Data Overlays

[portal!cup.portal.com!R_Tim_Coslet]

>     As for creating an overlay by using an address clause, here's the kind
>of problem you could get into.  Consider the following very simplified
>example:
>
>          X : Integer;
>          Y : Integer:
>          FOR X USE AT Y'Address;
>
>          X := 1;
>          ...
>          IF Y = 1 THEN ...
>
>It might be that your compiler, using standard code generation techniques,
>is using a delayed store on the value of X, which means basically that the
>1 is held in a register for a period of time rather than being immediately
>placed into the memory location of X.  As a result, Y does not have the
>expected value when the IF statement is executed.  Since the overlaying has

Or alternatively, the compiler could store the value of 1 into the overlayed
variable... but having previously worked with Y, it still resides in a
register and since Y wasn't manipulated when X was loaded with 1, the
compiler chooses to use the copy of Y "still in the register" for the
test. As a result, Y does not have the expected value when the IF 
statement is executed.

Same unexpected result, but different cause.


                                        R. Tim Coslet

Usenet: R_Tim_Coslet@cup.portal.com
        technology, n.  domesticated natural phenomena

Re: Data Overlays

[cs.utexas.edu!mars.tsd.arlut.utexas.edu!gardner]

jcrigler@theopolis.orl.mmc.com (Jim Crigler) writes:

>Bill Lee (bill@leeweyr.sccsi.com) wrote:
>: In article <1993Aug13.124835.18422@iplmail.orl.mmc.com>
>: rgilbert@orl.mmc.com writes:
>: >
>: >Many times I have wanted to create two different types to look at the
>: >same object.
>:
>: O.k., Here's my problem:

>: I have a system which receives "messages" from a number of other
>: systems. The messages come via POSIX queues. On any one queue, I
>: can receive a number of different messages, mostly with record
>: structures defined by the C code where the message originated.

>: I do not know a priori what the next message will be. I have to
>: "receive" the message into a Byte_Array. Once I have the message,
>: I can access a standard header and extract a message identifier,
>: which then tells me what kind of message I've just received.

>What about a variant record?  Language Lawyer question (my LRM is at
>home):  are rep. specs allowed on variant records?  If so (and if you
>have a single tag at any level that determines what the message is at
>that level), use an address clause to store the data on the Byte_Array,
>then use the variant to figure out what you've got.

I have had some difficulty using representation specifications
in code that is supposed to be portable.  In particular, in an
attempt to port a large amount of communication protocol code
from a 68030 platform to a SPARC, we found that a representation
clause caused a "bus error" during elaboration because 16-bit
integers were mapped to odd addresses in records defining
messages.  Unfortunately, the types that have this problem are
widely used throughout the code and are controlled by someone
else.  When they modify the code we have to port the
modification.

IMHO, the problem boils down to the fact that my preference is
to structure my code into 3 steps which are as completely
separated as possible.  These steps are:

    1.  Convert the input from some external representation to a
        native/natural representation for the problem.
    2.  Process the data.
    3.  Convert the output from its native/natural representation
        to some external representation.

Representation clauses violate this separation because they
cause assignment statements throughout the processing step to
also become conversions.

The realization that these steps are being followed also helps
one structure the code and types such that when data are
processed in several phases, the representation used in each
phase is the natural representation for that phase and can be
changed without affecting the other phases.  Only the conversion
code needs to be modified.

Re: Data Overlays

[Alex Blakemore]

In article <1993Aug19.185126.27655@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr
ites:
>   Method 3 : Use Unchecked_Conversion to pass (by reference) a parameter to a
 procedure
>                 procedure Overlay(Y : in out TYPE_2) is
>                 function To_Type_2 is new Unchecked_Conversion(TYPE_1, TYPE_2
);
>                   Overlay(To_Type_2(X));  -- Now reference to object as other
 type
>               The advantages are: ....

The disadvantages are ... it doesnt compile, its not legal Ada
you cant use a function result as an actual parameter of mode in out.
ut I believe it should work.
no comment :-)

in my opinion, its ok to use an overlay if it works to solve your problem
and there is no other way without copying a large buffer.
just isolate it, document it, and dont expect it to port.

the one case where I found it necessary was trying to read into a large
string buffer using Posix IO (which defines its own string type)
the only portable solution was to read into a posix string, and then
use the posix conversion function to convert between the two (really identical)
string types.

so in that case, there were only two choices
a. copy each IO buffer an additional time just to change its type, (but not its
 representation)
   + portable
   - wasteful
b. use an overlay to allow reading with posix string type and access with Ada s
tring type
   + efficient
   - perhaps not portable

since the buffers were large, and IO performance was a major concern and changi
ng
the posix interface (or the rest of the application) were out of the question,
I think using an overlay was the right choice.

of course, it would be a lot easier if the posix interface used standard.string
,
but I suppose there are still a few EBCDIC machines somewhere
-- 
Alex Blakemore       alex@cs.umd.edu        NeXT mail accepted
--------------------------------------------------------------
"Without an engaged and motivated human being at the keyboard,
the computer is just another dumb box."      William Raspberry

Re: Data Overlays

[Bob Crispen]

>From: cis.ohio-state.edu!magnus.acs.ohio-state.edu!csn!news.den.mmc.com!iplmai
l!jcrigler@ucbvax.Berkeley.EDU  (Jim Crigler) asks:

[and when are we going to get the AJPO host not to put the verbose Bitnet
string on here?]

>What about a variant record?  Language Lawyer question (my LRM is at
>home):  are rep. specs allowed on variant records?  If so (and if you
>have a single tag at any level that determines what the message is at
>that level), use an address clause to store the data on the Byte_Array,
>then use the variant to figure out what you've got.

Alas, this works only when the initial field is the discriminant for the
record (though one could have a fill-in-the-blanks discriminant field,
but my dim recollection is that coping with this is way uglier than
Unchecked_Conversion).  Yes, you absolutely can have rep specs on
record types with discriminants.  The only exception is that if you
have an unconstrained array in the record, you probably can't do what
you want.  For example:

package Bar is
 
   type An_Index is range 0..5;
   type An_Array is array (An_Index range <>) of Integer;
   type A_Big_Array is array (An_Index) of Integer;
   type A_Small_Array is array (An_Index range 0..1) of Integer;
   type Long_Boolean is (False, True);
   for Long_Boolean'size use 32;
 
   type Bad_Record (Size : An_Index) is
    record
      The_Array : An_Array (0..Size);
   end record;
 
   type Good_Record (Big : Long_Boolean) is
    record
      case Big is
         when True =>
            The_Array   : A_Big_Array;
         when False =>
            The_Overlay : A_Small_Array;
      end case;
   end record;
 
   for Bad_Record use
    record
      Size      at 0 range 0..31;
      The_Array at 4 range 0..(6 * 32)-1;
------^A                                                                     ##
#
--### A:error: RM 13.4(7): component subtype must be static
   end record;
 
   for Bad_Record'size use (7 * 32) - 1;
-------^A                                                                    ##
#
--### A:error: RM 13.2(6): type and its subcomponents must have static constrai
nts
 
   for Good_Record use
    record
      Big         at 0 range 0..31;
      The_Array   at 4 range 0..(6 * 32)-1;
      The_Overlay at 4 range 0..(2 * 32)-1;
   end record;

   for Good_Record'size use (7 * 32) - 1;

end Bar;

With respect to messages, the least ugly way I've found is, just as
Bill Gilbert says, to use Unchecked_Conversion to do overlays into byte
arrays.
+-------------------------------+--------------------------------------+
| Bob Crispen                   |   Who will babysit the babysitters?  |
| crispen@foxy.boeing.com       +--------------------------------------+
| (205) 461-3296                |Opinions expressed here are mine alone|
+-------------------------------+--------------------------------------+

Re: Data Overlays

[Jim Lonjers]

In article <70605@mimsy.umd.edu> alex@cs.umd.edu (Alex Blakemore) writes:

>the one case where I found it necessary was trying to read into a large
>string buffer using Posix IO (which defines its own string type)
>the only portable solution was to read into a posix string, and then
>use the posix conversion function to convert between the two (really identical
)
>string types.

POSIX Ada also allows one to read and write arbitrary types (with
Generic_Read and _Write).  The non-generic write is provided for those
situations where one wishes to pretend they are writing in C (just a
joke, guys).

This is efficient, does not incur any addition data copies, and, while not
guaranteed to be portable, it probably does port.  The files generated this
way are not portable between compilers.

Jim

Re: Data Overlays

[dog.ee.lbl.gov!agate!howland.reston.ans.net!math.ohio-state.edu!magnus.ac]

In article 29091@software.org, smithd@software.org (Doug Smith) writes:
>In article <1993Aug18.125540.1393@iplmail.orl.mmc.com> rgilbert@orl.mmc.com wr
ites:
>>
>>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 overla
ys
>>of objects...  Any program using address clauses to achieve such effects is
>>erroneous.  What is the rationale for this?
>>
>> [stuff deleted]
>>
>>                             Bob
>
>
>And...if you use this technique, don't forget what happens when the
>variable is elaborated:
>
>   procedure P(X : Some_Type) is
>      Y : Some_Pointer_Type; -- or record with initialization
>      for Y use at X'Address;
>   begin
>      -- Y has likely been initialized to null, and X has probably
>      -- been changed.  But, since this program is erroneous,
>      -- it is fine for the compiler to do whatever it wants ;^)
>   end;
>   
>Doug
>smithd@software.org

Absolutely, and somewhat unrelated to data overlays...

   I have experienced this and it can be a problem when attempting to
   map to read-only (VME bus system) addresses.  Since most compilers
   will attempt to initialize objects using representation clauses,
   during program elaboration the resulting write to the address
   results in a VME bus error.  The solution is to use access types
   and assign the address to the access object using Unchecked_Conversion.
   This BTW, is similar to the other method I have used for implementing
   data overlays.

                     Bob

Re: Data Overlays

[Jim Lonjers]

In article <25um9l$rfk@seine.cs.umd.edu> alex@cs.umd.edu (Alex Blakemore) write
s:
>unfortunately, if the entire object cannot be read, "the number of
>POSIX characters actually transferred is unspecified and there is no
>way for the POSIX application to know this number".  this is fine if
>you wish to read and write Ada objects whose size is known in advance,
>but is a real impediment if you wish to read in a blocks of
>characters, and dont know the total size in advance (i.e. to
>repeatedly fill a buffer, and the last time the number read may be
>less than the size of the buffer).

Yes, you have really identified a failing here:  the generic operations
should have allowed for transfer of multiple objects of a type, with an
indicator of how many of those objects are actually transferred.  This
would bridge the gap between the "one-at-a-time" generic model and the
essentially untyped transfer provided by the "buffer" model.  Good idea for
future standards.

>I think the Ada POSIX binding is really fine and a big improvement
>over the C version in most respects.  for most applications, text_io
>would be fine.  I sure wish there was one 8 bit character that all the
>packages agreed upon.
>
>instead for those of using ASIS, we have
>  POSIX.POSIX_Character
>  Standard.Character
>  ASIS.ASIS_Character

Obviously, ASIS goofed, they could have picked POSIX.POSIX_Character :-)

>and all are very likely physically identical, sheesh.

Yea, when we invented POSIX.POSIX_Character, we felt the same way.  I
believe most of this problem goes away in 9X.

Re: Data Overlays

[David Emery]

Incidentally, part of the reason for the POSIX.POSIX_Character
abstraction in 1003.5 was to support 16-bit (or 7 bit) character sets.
So don't assume that POSIX.POSIX_Character'size = 8 (even though that
is the most common value...)

				dave