[comp.lang.ada] INFO-ADA Digest V88 #135

karl@grebyn.COM (Karl A. Nyberg) (06/03/88)

[Ed, - Forwarded]

-- Karl --

Date: Thu, 2 Jun 88 11:59:10 EDT
From: Jim Moody (DCA C342) <umd5!dca-ems.arpa!jmoody>
Subject: Re: INFO-ADA Digest V88 #135
To: INFO-ADA-REQUEST@ajpo.sei.cmu.edu

All,

Mike Linnig posed a question about Dynamic Address Clauses.  What follows is
his question with my annotations.

.......................................

The following package was compiled with two compilers (DEC Ada and
Tartan 1750a Ada).  Both allowed the declaration of X.  DEC ada
complained about the type conversion used for the rep clause
in ANOTHER.

Assuming one or both is legal, what do they mean???

Mike Linnig,
Texase Instruments



------------------------------------------------------------
with SYSTEM;
use SYSTEM;
package DYNAMIC ADDR is
  subtype STUPID is SYSTEM.ADDRESS;

  function DYNAMIC return STUPID;  -- just some function


  X: INTEGER;
  for X use at DYNAMIC;  -- just what does this mean??

                        --  First of all, it's an incorrect order
                        --  dependency and will raise PROGRAM ERROR
                        --  if executed, since the body of DYNAMIC
                        --  hasn't been elaborated yet.  Leaving that
                        --  aside (since it could be fixed by taking
                        --  DYNAMIC outside the package spec and using
                        --  PRAGMA ELABORATE to make sure that its
                        --  body has been elaborated already), what it
                        --  does is what it looks like it does.

                        --  It looks like it places X at the address returned by
                        --  evaluation (at elaboration time) of DYNAMIC.  One
                        --  might do such a thing to e.g. put data to be shared 
                        --  with another process at a place agreed to by the
                        --  other process (negotiation performed via DYNAMIC).
                        --  One might have a slow interprocess communication
                        --  method which is OK for setting things up, but too
                        --  slow to use for passing data back and forth.  In
                        --  such a case, the use of shared memory might be
                        --  mandatory.  Where the shared memory is might not
                        --  be determinable until run-time.  


  ANOTHER: INTEGER;
  for ANOTHER USE AT stupid(x);
                -- I guess we can use x as a pointer
                -- but is it only evaluated at package elaboration?

                            --  I would prefer to use:

  for ANOTHER use at INSTANTIATION OF UNCHECKED CONVERSION INT TO STUPID(X);

                            --  rather than the explicit type conversion.  The
                            --  compiler probably wouldn't complain about that.
                            --  It makes it clear that you're assuming that an
                            --  address is an integer;  there are machines for
                            --  which that isn't true:  Honeywell DPS8000, for
                            --  example, where addresses are left-justified in 
                            --  a word.
                            --  Yes, it is evaluated at package elaboration.
                            --  Use would be similar to the placement of X.

end DYNAMIC ADDR;