Re: Overlay allowability

["Marc A. Criley" <marc.a.criley@lmco.com>]

Bob,

Thanks for doing the analysis of this little example, I agree that the
FAQ would be well-served by including your writeup within it (with, of
course, the inadvertent omission of the 'Address on "for SN'Address use
N;" corrected :-)

In the real code where this would be used, "N" is actually the parameter
that is received into the procedure that does the overlaying, and is an
instance of a generic formal type, of which nothing concerning its
content and constituents are known.  (BTW, no references to this
variable other than remapping it into a Stream_Element_Array occur.) 
This of course bolsters your analysis that the developer then needs to
specify exactly what is expected of such instances in a context, rather
than requiring developers to re-perform the analysis to understand the
conditions under which this executes.

Thanks again,

Marc


"Robert I. Eachus" wrote:
> 
>    This one should be in the FAQ...
>
> "Marc A. Criley" wrote:
>  
> > A few times in my career I've encountered situations where two different
> > representations of the same set of bits are desired in a high
> > performance application, and this has been effected with the aid of the
> > 'Address representation attribute.  In Ada 95, an example of this would
> > be:
> >
> >   N : Natural;
> >
> >   SN : Stream_Element_Array(1..N'Size / System.Storage_Unit);
> >   for SN'Address use N;
> >
> > This has always struck me as somewhat iffy, but I confess I've used
> > it as well on a couple occasions with Ada 83.  I've always found that
> > it works as one intuitively expects, so long as all alignment, layout
> > and sizing aspects are fully thought through and accommodated.
> >
> > So, is this within the definition of Ada 95?  Or is it well-defined
> > only for certain constructs, say scalars and non-tagged types, and
> > dicey for others?  Are there type constructs for which relying on it
> > is clearly a reliance on undefined behavior, is the whole construct a
> > reliance on undefined behavior?  Is there a de facto, in place of a
> > formal, expectation that this should work as expected?
> 
>     Hmmm.   The RM is very clear about this:
> 
>     "If an Address is specified, it is the programmer's responsibility
> to ensure that the address is valid; otherwise, program execution is
> erroneous."  RM 13.3(13).
> 
>      So first off, your example has a bug in it, and will almost
> certainly result in erroneous execution.  I'm sure you intended to
> write:
> 
>        for SN'Address use N'Address;
> 
>        correct?  Your code fragment as written would be erroneous or not
> depending on whether or not the value in N corresponded to a legitimate
> address when the representation clause was elaborated.
> 
>        Now let's go to the much more interesting case of what you
> intended to write.  First, N'Address is likely to be a valid address, so
> the program execution will not be erroneous (or at least, not due to the
> elaboration of this construct).  Note, that just being the result of an
> 'Address clause is not sufficient to make an address valid, you could,
> for example, say "use Main_Program'Address;" "use Bit_Array(7)'Address;"
> or even "Some_Constant'Address;"  but the clause above should be safe,
> unless an unfriendly compiler sticks N in a register.  Most Ada
> compilers are very friendly in this case, but why not warn maintainers
> by making N explicitly aliased.
> 
>        You mentioned, alignment, layout, and sizing aspects, and
> (surprise!) these are discussed in great detail in RM 13.3.  There are
> some things you can count on, some you can--and often should--specify,
> and some which will be implementation defined.  But there are some other
> details that you should be aware of.  You usually don't want any default
> initializations that are associated with the subtype of SN to be
> performed.  The fact that you don't provide a default value, doesn't
> prevent the compiler from initializing something behind your back.
> (Everyone knows that access values are initialized to null in the
> absence of other initializations, but compilers may choose to initialize
> records with gaps to make comparisions easier, and you certainly don't
> want your code to fail if someone compiles it with pragma
> Normalize_Scalars, or adds a default initialization to some subtype.)
> 
>   Also, if you are using both representations of the data in the same
> code, you need to think seriously about which declarations will require
> pragma Volatile, Atomic, Volatile_Components or Atomic_Components.  Note
> that these are in Annex C, and that the use of one of these pragmas may
> result in the program being rejected.  A "nice" compiler will note the
> aliasing, and not put N in a register.  But the real issues you have to
> worry about are much more subtle.  Assuming that you used the right
> pragma for your code, and that the compiler doesn't have a serious bug,
> the compiler will--instead of producing what you will consider to be
> buggy code--tell you that, on this hardware, your code cannot be
> correctly implemented.     In your example, assuming that the
> Stream_Element_Array comes from Ada.Streams, it is likely that you can
> safely apply pragma Atomic to N and pragma Volatile_Components to SN.
> All this may not be necessary, and in fact Ada compilers do try to be
> friendly, but you should require the behavior that you actually require,
> if only for documentation.  So the general template for the idiom is:
> 
>   N : aliased Natural;
>   pragma Atomic(N);
> 
>   SN : Stream_Element_Array(1..N'Size / System.Storage_Unit);
>   for SN'Address use N'Address;
>   pragma Volatile_Components(SN);
>   pragma Import(SN);
> 
>   I made N atomic, since you probably do want to insist that you don't
> see "half" of an update.  If N was for example a double word scalar, the
> pragma might be necessary.  (And compilers can often do double loads and
> stores on hardware which only supports single word integers--think long
> float.)  I used Volatile_Components on SN because it is much more likely
> to be accepted, and you would probably only need to use
> Atomic_Components if you had multiple tasks involved.  This is the type
> of thinking which the programmer/software engineer needs to do as part
> of the design.  Not putting the pragmas in--or a comment as to why they
> are not there--requires that every reader or maintainer do that analysis
> all over again.