From mboxrd@z Thu Jan  1 00:00:00 1970
X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me
X-Spam-Level: 
X-Spam-Status: No, score=0.2 required=5.0 tests=BAYES_00,INVALID_MSGID,
	REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4
X-Google-Language: ENGLISH,ASCII-7-bit
X-Google-Thread: 103376,610e53a911ec64b3
X-Google-Attributes: gid103376,public
From: kevq@banana.demon.co.uk (Kevin F. Quinn)
Subject: Re: Importing C Structures
Date: 1995/03/27
Message-ID: <19950327.180750.74@banana.demon.co.uk>#1/1
X-Deja-AN: 100721934
sender: news@demon.co.uk (Usenet Administration)
x-nntp-posting-host: banana.demon.co.uk
references: <3kr4q3$jd9@newsflash.concordia.ca>  <D5zqB9.5F8@thomsoft.com>
 <1995Mar26.081652.9489@eisner>
organization: The Banana Arc
reply-to: kevq@banana.demon.co.uk
newsgroups: comp.lang.ada
Date: 1995-03-27T00:00:00+00:00
List-Id: <comp.lang.ada>

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...