comp.lang.ada
 help / color / mirror / Atom feed
From: bobduff@world.std.com (Robert A Duff)
Subject: Re: Q: Memory management
Date: 1996/06/27
Date: 1996-06-27T00:00:00+00:00	[thread overview]
Message-ID: <DtnotE.Boo@world.std.com> (raw)
In-Reply-To: uvvybl91xtl.fsf@chaq.informatik.uni-tuebingen.de

In article <uvvybl91xtl.fsf@chaq.informatik.uni-tuebingen.de>,
Hannes Haug  <Hannes.Haug@Student.Uni-Tuebingen.de> wrote:
>I think I didn't understand the concept uf unconstrained arrays. There
>are no constrained arrays. All arrays are constrained.

All array *objects* are constrained.

>... So there is no
>need to store bounds somewhere in the array's storage. But there are
>pointers that can point to arbitrary constrained arrays. But Pointer.all
>is still constrained. That the bounds are not known at compile time is not
>the fault of Pointer.all but of Pointer. So the storage for the bounds
>belongs to Pointer and not to Pointer.all. So Pointer.all'Address should
>be the address of the elements of the array. Is this view (at least logically)
>correct ?

Well, sort of, but not really.  You're mixing implementation issues and
semantic issues.

Either implementation model is correct -- store the bounds with the
pointer, or store the bounds with every aliased object.  Aliased objects
are the ones you can point at, including heap objects.

Either way, 'Address should point to the first element of the array --
this is because the RM says so, not because of your arguments above
about how it should naturally be implemented.

Storing the bounds with the array could be done in (at least) two ways
-- the access value could point at the bounds, or at the data (with the
bounds being accessed at a negative offset).  If the former, then
Ptr.all'Address would be implemented as an ADD instruction, adding some
constant number (the size of the dope) to the value of Ptr.

Note that storing the bounds with the pointer is probably easiest to
implement if you actual store the *address* of the bounds with the
pointer.  That is, an access type consists of a pair of addresses, one
of which points to the bounds, and the other of which points at the
data.  (Only if the designated subtype is an unconstrained array, of
course.)  I don't like this implementation much, myself, for various
reasons.

Lots of other variations are possible.  Ada does not require that access
values be implemented as machine addresses.

- Bob




  reply	other threads:[~1996-06-27  0:00 UTC|newest]

Thread overview: 30+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <JSA.96Jun26142033@organon.com>
1996-06-27  0:00 ` Q: Memory management Hannes Haug
1996-06-27  0:00 ` Hannes Haug
1996-06-27  0:00   ` Robert A Duff [this message]
1996-06-24  0:00 W. Wesley Groleau (Wes)
1996-06-25  0:00 ` Hannes Haug
1996-06-25  0:00   ` Tucker Taft
     [not found]     ` <Dtzv4J.9FL@thomsoft.com>
1996-07-17  0:00       ` Robert Dewar
1996-06-25  0:00   ` Robert A Duff
1996-06-25  0:00 ` Jon S Anthony
1996-06-26  0:00   ` Robert Dewar
1996-06-27  0:00 ` Hannes Haug
  -- strict thread matches above, loose matches on Subject: below --
1996-06-19  0:00 Q: memory management W. Wesley Groleau (Wes)
1996-06-20  0:00 ` Hannes Haug
1996-06-20  0:00 ` Hannes Haug
1996-06-20  0:00   ` Robert Dewar
1996-06-21  0:00 ` Hannes Haug
1996-06-21  0:00   ` Robert Dewar
1996-06-25  0:00 ` Hannes Haug
1996-06-15  0:00 Hannes Haug
1996-06-15  0:00 ` Jon S Anthony
1996-06-16  0:00   ` Robert Dewar
1996-06-18  0:00   ` Kent Mitchell
1996-06-15  0:00 ` Robert Dewar
1996-06-16  0:00 ` Hannes Haug
1996-06-17  0:00   ` Tucker Taft
1996-06-17  0:00   ` Hannes Haug
1996-06-18  0:00   ` Hannes Haug
1996-06-18  0:00     ` Tucker Taft
1996-06-19  0:00     ` Hannes Haug
1996-06-18  0:00 ` Jon S Anthony
replies disabled

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox