Re: Overlay allowability

[mark_biggar@my-deja.com]

In article <390DCBB2.CE2C1609@averstar.com>,
  Tucker Taft <stt@averstar.com> wrote:
> "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;
>
> I presume you meant:  for SN'Address use N'Address.
>
> Also, N'Size/System.Storage_Unit is not what you want, probably.
> More likely is:
>     (N'Size + System.Storage_Unit - 1)/System.Storage_Unit
>
> I.e., round the division up.
>
> N'Size is probably going to be 31 on your typical 32-bit computer.
>
> >
> > 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?
>
> This is well-defined in Ada 95, though as mentioned elsewhere, using
unchecked
> conversion is more explicit and probably less likely to run into
> problems.  As far as the Ada 95 RM, using 'Address for overlaying is
> safer than in Ada 83, because of RM95 13.3(19):
>
>    If the Address of an object is specified ... then the
implementation
>    should not perform optimizations based on assumptions of no
aliases.
>
> Note that this is implementation advice, not an implementation
requirement.
> The probable reason it is advice rather than requirement is because of
> the difficulty of formulating this recommendation exactly and
testably.

Another thing to watch out for is Initializations.  if both variables
are of a type that has either explisit or implisit imitialization then
both initializations will be performed.  The following example is from
a froends code that took both of us hours to figure out what was
happening:

type A_foo is access Foo;
type A_bar is access Bar;

F: A_foo := new Foo(...);
B: A_Bar;

for B'ADDRESS use F'ADDRESS;

The intent is to view the same chunk of memory in differnet ways.
(This is obviously a case where Unchecked_Conversion makes MUCH
more sense but unformunately the code was a re-implementation of
a C program that used pointer casting for just this and the
writer [a third party] was an ex-C programmer.)

The problem is that the implisit initialazation of B to Null was
clobbering the pointer to the memory chunk.  This fix for this
(other than to rewrite using Unchecked_Conversion) was to add
a pragma EXPORT(B, Ada); to suppress the initialization.

--
Mark Biggar
mark@biggar.org


Sent via Deja.com http://www.deja.com/
Before you buy.