Re: Importing C Structures

[kevq@banana.demon.co.uk (Kevin F. Quinn)]

In article <1995Mar26.081652.9489@eisner>,
          kilgallen@eisner.decus.org (Larry Kilgallen, LJK Software) wrote:

> In article <D5zqB9.5F8@thomsoft.com>, kst@thomsoft.com (Keith Thompson) writes:
> 
> > Here's an example of an erroneous use of address clauses in Ada 83:
> > 
> >     X : Integer;
> >     ...
> >     Y : Integer;
> >     for Y use at X'Address;
> > 
> > The reason this is erroneous is that the compiler may not be aware that
> > X and Y are really the same object (X may be declared in a different
> > compilation unit, or the overlaid object might be something more
> > complex than a simple object, say a dynamically indexed array element).
> > The compiler is free to keep the value of X in a register, optimize out
> > dead assignments, etc., so the apparent values of X and Y won't track

You're correct (of course :) ) but I would expect the situation
with more complex objects, especially ones involving dynamically
chosen elements to be very rare indeed.  Especially justifiable
situations...

> 
> For an address representation clause, which might be used to access hardware,
> optimizing out dead assignments seems quite inappropriate.  Is there no
> Ada83 method of avoiding such an optimization for such objects?

The problem occurs with 'X', which the compiler is free to handle
purely in a register for a while if that is appropriate; it doesn't
know that an interrupt handler which uses Y can come in expecting
Y to be the same as X at all times, for example.  Possibly a bit of
a contrived situation, but if it can be done, it probably will be
done by someone somewhere :)

Dead assignments for Y should never be optimised away, for the
reasons you mention, Larry.  Not that I'd trust a compiler in this;
I'd always take a glance at the assembly listing to be sure...

Most compilers I've used have a "pragma Volatile" or similar, which
marks a variable so that the optimiser leaves it in memory.  If your
compiler doesn't have a suitable pragma (and it doesn't have to), you
can try:

   private_XY : Integer;
   
   X : Integer;
   for X use at private_Z'address;
   Y : Integer;
   for Y use at private_Z'address;

Then you can use X and Y with impunity - if the compiler is worth
anything then both X and Y will always be accessed over the bus.
Leave it to coding standards to ensure that private_XY is never
used.  This can be done in all situations, including ones where
data is declared in a new block (hence is declared dynamically,
probably on a stack or heap).

I'm not sure if you can put private_XY in a package body, vis:

  package MyData is
    X : Integer;
    Y : Integer;
  end MyData;
  
  package body MyData is
    private_XY : Integer;
    for X use at private_XY'address;
    for Y use at private_XY'address;
  end Mydata;

It might work though (don't have a compiler here to check...),
in which case you will have enforced the non-use of private_XY
by packaging.

If you're relying on this kind of thing, it is always best to
check your object code just to be sure, anyway.  I may be
stating the obvious, but then again...

Especially since you'll need to give VERY good reasons why
you're doing it in the first place :)

-- 
Kevin F. Quinn           * "No-one ever made any money out of good
kevq@banana.demon.co.uk  *  looks and charm."
kevq@cix.compulink.co.uk * "You obviously haven't met Lady Hamilton..."
Compu$erve: 100025,1525  *                               Blackadder III
... I'll have what the guy on the floor is having...