Re: Overlay allowability

["Robert I. Eachus" <rieachus@earthlink.net>]

"Marc A. Criley" wrote:

   This one should be in the FAQ...
 
> 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.