Q: memory management

Q: memory management

[Hannes Haug]

Hi,

I'm new to Ada and have a question on memory management. Is
there a function like malloc in Ada ? I want just a pointer
to a certain amount of raw storage.

I think "new Storage_Array (n)" will give me a little bit too
much storage. The array bounds need some space.

Does "Allocate (some_storage_pool, addr, n, Word_Size / Storage_Unit)"
work ? Which storage pool do I have to choose ?

Thanks

 - hannes

Re: Q: memory management

[Robert Dewar]

Hannes asks

"I'm new to Ada and have a question on memory management. Is
there a function like malloc in Ada ? I want just a pointer
to a certain amount of raw storage.

I think "new Storage_Array (n)" will give me a little bit too
much storage. The array bounds need some space."

It really would be better to say what problem you are trying to solve,
than to ask for help for what seems a somewhat dubious solution (it
sounds as though you are thinking at too low a level). Anyway you
can probably do what you want by defininig an access type whose
designated type is a constrained array of the size you want and
allocating one of those (bounds probably are not needed in this
case).

But why not tell us what you are really trying to do?

Re: Q: memory management

[Jon S Anthony]

In article <uvv4tod9j9e.fsf@chaq.informatik.uni-tuebingen.de> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:

> I'm new to Ada and have a question on memory management. Is
> there a function like malloc in Ada ? I want just a pointer
> to a certain amount of raw storage.

the reserved word _new_ in an allocator context.  For example,

procedure Junk is

    type string_ref is access string;

    -- Dynamically allocate a string...
    --
    msg : string_ref := new string'(Hello Marion, is that you?);
....
end Junk;


> I think "new Storage_Array (n)" will give me a little bit too
> much storage. The array bounds need some space.

I don't know what "storage_array" is, but don't worry about the
space for bounds.  It's all taken care of for you.


> Does "Allocate (some_storage_pool, addr, n, Word_Size / Storage_Unit)"
> work ? Which storage pool do I have to choose ?

At this point don't worry about user defined storage pools and
allocation/deallocation.  Just use the standard predefined ones.
Have a look at access types in the rationale or in the Lovelace
tutorial:

http://lglwww.epfl.ch/Ada/

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Q: memory management

[Robert Dewar]

Jon Anthony said:

"I don't know what "storage_array" is, but don't worry about the
space for bounds.  It's all taken care of for you."

Once again, consulting another secret source of information, this time
the Ada reference manual :-) we find

13.7.1 The Package System.Storage_Elements

                              Static Semantics

1   The following language-defined library package exists:

2   package System.Storage_Elements is
       pragma Preelaborate(System.Storage_Elements);

3      type Storage_Offset is range implementation-defined;


4      subtype Storage_Count is Storage_Offset range 0..Storage_Offset'Last;

5      type Storage_Element is mod implementation-defined;
       for Storage_Element'Size use Storage_Unit;
       type Storage_Array is array
         (Storage_Offset range <>) of aliased Storage_Element;
       for Storage_Array'Component_Size use Storage_Unit;


and indeed the original questioner was quite right to think in terms of
using Storage_Array for allocating raw storage, that is EXACTLY what
it is intended for.

P.S. I find it very useful to have a straight ASCII version of the RM around
that can instantly and easily be searched for the occurrence of a string
like this. It's useful for finding something you don't know, or, as in this
case, quickly tracking down a reference to something you do know.

Re: Q: memory management

[Kent Mitchell]

Jon S Anthony (jsa@organon.com) wrote:
: In article <uvv4tod9j9e.fsf@chaq.informatik.uni-tuebingen.de> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:


: > I think "new Storage_Array (n)" will give me a little bit too
: > much storage. The array bounds need some space.

: I don't know what "storage_array" is, but don't worry about the
: space for bounds.  It's all taken care of for you.

Actually a more interesting question to consider is why you would want to
allocate a generic pool of space within Ada.  C has this because C *only*
has generic pointers.  Ada has a more controlled concept of allocation with
pointers to specific types which are not generally interchangable.  This
allows the language to manage pools of different objects and still provide
reasonable type safety, etc.  Generally, if you need to allocate a buffer, it
is a buffer of some specific things (characters, bytes, records, etc.).
So ... you might want to look at doing things in a more Ada-like way instead
of a C-like general buffer.

--
Kent Mitchell                   | One possible reason that things aren't
Technical Consultant            | going according to plan is .....
Rational Software Corporation   | that there never *was* a plan!

Re: Q: memory management

[Hannes Haug]

>>>>> "Jon" == Jon S Anthony <jsa@organon.com> writes:

    Jon> In article <uvv4tod9j9e.fsf@chaq.informatik.uni-tuebingen.de>
    Jon> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:
    >> I'm new to Ada and have a question on memory management. Is
    >> there a function like malloc in Ada ? I want just a pointer to
    >> a certain amount of raw storage.

    Jon> the reserved word _new_ in an allocator context. [...]

I know about new.


    >> I think "new Storage_Array (n)" will give me a little bit too
    >> much storage. The array bounds need some space.

    Jon> I don't know what "storage_array" is, but don't worry about
    Jon> the space for bounds.  It's all taken care of for you.

But I really just want a pointer to some amount of storage. I have to
pass it to som assembly routines. This routines cannot benefit from the
bounds in the array representatio. They would even overwrite them. And
I have to worry about space. The here useless bounds would cost me at
least 1MB.

    >> Does "Allocate (some_storage_pool, addr, n, Word_Size /
    >> Storage_Unit)" work ? Which storage pool do I have to choose ?

    Jon> At this point don't worry about user defined storage pools
    Jon> and allocation/deallocation.  Just use the standard
    Jon> predefined ones.

Not possible. Perhaps I have to use malloc.

 - hannes

Re: Q: memory management

[Tucker Taft]

Hannes Haug (Hannes.Haug@Student.Uni-Tuebingen.de) wrote:

: But I really just want a pointer to some amount of storage. I have to
: pass it to som assembly routines. This routines cannot benefit from the
: bounds in the array representatio. They would even overwrite them. And
: I have to worry about space. The here useless bounds would cost me at
: least 1MB.

Does the size vary from one allocation to the next, or 
are they all the same size?  If they are all the same size,
you may declare the access type with a constrained designated
subtype, such as:

     subtype Alloc_Buffer is String(1..Num_Chars);
     type Space_Ptr is access all Alloc_Buffer;
   ...

     X : Space_Ptr := new Alloc_Buffer;
   ...
     Pass_To_Assembler(X.all'Address);

In most compilers, no bounds would be stored in the heap for such
an allocation, since the bounds do not vary from allocation to allocation.

:     >> Does "Allocate (some_storage_pool, addr, n, Word_Size /
:     >> Storage_Unit)" work ? Which storage pool do I have to choose ?

This should work.  The storage pool would be specified via
Some_Access_Type'Storage_Pool where Some_Access_Type is any
access type declared at the library level.  It would be safest if
the access type had an unconstrained designated subtype, such as:

     type Some_Access_Type is access all String;

to avoid the implementation-chosen storage pool from being one that
only works on access collections of uniformly-sized objects.

: Not possible. Perhaps I have to use malloc.

If you are interfacing with C, then using "malloc" via a pragma Import
makes sense.  If you are interfacing with assembler, it seems silly
to drag in the C run-time support, unless you know it will already
be there for other reasons.

:  - hannes

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Q: memory management

[Hannes Haug]

Hi,

>>>>> "TT" == Tucker Taft <stt@henning.camb.inmet.com> writes:

    TT> Does the size vary from one allocation to the next, or are
    TT> they all the same size?

the sizes vary.

    [...]

    TT> This should work.  The storage pool would be specified via
    TT> Some_Access_Type'Storage_Pool where Some_Access_Type is any
    TT> access type declared at the library level.  It would be safest
    TT> if the access type had an unconstrained designated subtype,
    TT> such as:

    TT>      type Some_Access_Type is access all String;

    TT> to avoid the implementation-chosen storage pool from being one
    TT> that only works on access collections of uniformly-sized
    TT> objects.

Thanks. I'll try it.

    TT> If you are interfacing with C, then using "malloc" via a
    TT> pragma Import makes sense.  If you are interfacing with
    TT> assembler, it seems silly to drag in the C run-time support,
    TT> unless you know it will already be there for other reasons.

I have to interface to C and assembler. But even in the C case the
use of malloc looks silly to me.

 -hannes

Re: Q: memory management

[Hannes Haug]

>>>>> "TT" == Tucker Taft <stt@henning.camb.inmet.com> writes:

    TT> This should work.  The storage pool would be specified via
    TT> Some_Access_Type'Storage_Pool where Some_Access_Type is any
    TT> access type declared at the library level.  It would be safest
    TT> if the access type had an unconstrained designated subtype,
    TT> such as:

    TT>      type Some_Access_Type is access all String;

    TT> to avoid the implementation-chosen storage pool from being one
    TT> that only works on access collections of uniformly-sized
    TT> objects.

Let's be e little bit pedantic. The size of such an array is always > 0,
even if the length is 0. The bounds have to be stored somewhere. So what
happens if I want to allocate a piece of memory that is smaller than such
an array of length 0 ? Perhaps the storage pool doesn't handle such small
pieces. It's just a theoretical problem, of course.

 - hannes

Re: Q: memory management

[Tucker Taft]

Hannes Haug (Hannes.Haug@Student.Uni-Tuebingen.de) wrote:
: >>>>> "TT" == Tucker Taft <stt@henning.camb.inmet.com> writes:

:     TT> This should work.  The storage pool would be specified via
:     TT> Some_Access_Type'Storage_Pool where Some_Access_Type is any
:     TT> access type declared at the library level.  It would be safest
:     TT> if the access type had an unconstrained designated subtype,
:     TT> such as:

:     TT>      type Some_Access_Type is access all String;

:     TT> to avoid the implementation-chosen storage pool from being one
:     TT> that only works on access collections of uniformly-sized
:     TT> objects.

: Let's be e little bit pedantic. The size of such an array is always > 0,
: even if the length is 0. The bounds have to be stored somewhere. So what
: happens if I want to allocate a piece of memory that is smaller than such
: an array of length 0 ? Perhaps the storage pool doesn't handle such small
: pieces. It's just a theoretical problem, of course.

Solution: You implement your own storage pool.  Which probably ends 
up calling "malloc" or some even lower level operation.
That's what happens when you start getting too theoretical ;-).

:  - hannes

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Q: memory management

[Hannes Haug]

>>>>> "TT" == Tucker Taft <stt@henning.camb.inmet.com> writes:

    TT> Solution: You implement your own storage pool.  Which probably
    TT> ends up calling "malloc" or some even lower level operation.
    TT> That's what happens when you start getting too theoretical
    TT> ;-).

But some mallocs suck. Some are thread save others not. Perhaps there
even isn't a malloc available. A lot of problems if I'm too theoretical ;-)

 - hannes

Re: Q: memory management

[Jon S Anthony]

In article <uvvafy3ucoc.fsf@chaq.informatik.uni-tuebingen.de> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:

> 
>     Jon> the reserved word _new_ in an allocator context. [...]
> 
> I know about new.
> 
> 
>     >> I think "new Storage_Array (n)" will give me a little bit too
>     >> much storage. The array bounds need some space.
> 
>     Jon> I don't know what "storage_array" is, but don't worry about
>     Jon> the space for bounds.  It's all taken care of for you.
> 
> But I really just want a pointer to some amount of storage. I have to
> pass it to som assembly routines. This routines cannot benefit from the
> bounds in the array representatio. They would even overwrite them. And
> I have to worry about space. The here useless bounds would cost me at
> least 1MB.

I see that I have misunderstood again.  :-(  That's two strikes.  I wonder
if I've blown the last one...

If you use constrained arrays, you should there should not be any
array bounds involved in the memory allocation.  If you need to have
variable amounts you can try this:

Somewhere after you've figured out what n is:

    ...

    declare
        subtype The_Storage_Type is Storage_Array(n);
	type Storage_Ref is access The_Storage_Type;
        The_Storage : Storage_Ref := new The_Storage_Type;
    begin
        ... Stuff...
    end;

There's no reason in this context for allocating the bounds with the
actual storage for The_Storage.  Then again, I don't think there is
any guarantee either (I would be surprised if they were included, but...)

If this isn't good enough then you really will need to resort to
defining your own storage pools.  That would allow you to redefine
what happens when _new_ is used as an allocator for an access type
associated with the pool.

>     Jon> At this point don't worry about user defined storage pools
>     Jon> and allocation/deallocation.  Just use the standard
>     Jon> predefined ones.
> 
> Not possible. Perhaps I have to use malloc.

Well, this is just me bungling the answer.  In your case you may
well want to use your own storage pools.  Note that if you do, you
could use malloc as part of the implementation of them if you discovered
that there was a good reason for this.  Actually, in the case of GNAT
I think predefined _new_ turns into malloc anyway...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Q: memory management

[W. Wesley Groleau (Wes)]

:> : But I really just want a pointer to some amount of storage. I have to
:> : pass it to som assembly routines. This routines cannot benefit from the
:> : bounds in the array representatio. They would even overwrite them. And
:> : I have to worry about space. The here useless bounds would cost me at
:> : least 1MB.
:>
:> Does the size vary from one allocation to the next, or
:> are they all the same size?  If they are all the same size,
:> you may declare the access type with a constrained designated
:> subtype, such as:
:>
:>      subtype Alloc_Buffer is String(1..Num_Chars);
:>      type Space_Ptr is access all Alloc_Buffer;
:>    ...
:>
:>      X : Space_Ptr := new Alloc_Buffer;
:>    ...
:>      Pass_To_Assembler(X.all'Address);

Please note that whether you have bounds or not, you do not want to pass
the actual pointer to assembler or C or ...

An Ada access type is a bit pattern that can be used by code from the
same compiler to access the item.  It does not have to be an address,
though in most implementations it is.  It also does not have to be the
address of the actual item, and in most implementations an access to
an unconstrained type is NOT the address of the item.  Mr. Taft's example
above is the correct way to let code from another compiler or language
get the address of your object.  NOT unchecked conversion from the
access type to address.  For some reason, I keep seeing even experienced
Ada programmers use the latter (incorrect) method.

(Aside: How is it that the bounds cost one Meg?)

Also, be sure you know what you're doing if you try to mix malloc with
new.  Many Ada compilers do their own memory management.  Perhaps this
is because malloc is not task-safe.  whatever the reason, many do not catch
errors caused by the user assuming malloc and new are interchangeable.
If you create something with malloc and try to destroy it with unchecked_
deallocation you can corrupt both memory managers.  Likewise with new and
free.

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Q: memory management

[Hannes Haug]

>>>>> "Wes" == "W Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

    Wes> (Aside: How is it that the bounds cost one Meg?)

I have several 100000 memory regions of different, not at compile time
known quite small sizes.

 -hannes

Re: Q: memory management

[Robert Dewar]

Hannes said

"I have several 100000 memory regions of different, not at compile time
known quite small sizes."

I cannot conceive of any legitimate need in an Ada program for allocating
several hundred thousand small areas of raw memory. Possibly one could
imagine a C program doing this, but not an Ada program.

Re: Q: memory management

[Hannes Haug]

>>>>> "Wes" == "W Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

    Wes> :>      subtype Alloc_Buffer is String(1..Num_Chars);
    Wes> :>      type Space_Ptr is access all Alloc_Buffer;
    Wes> :>    ...
    Wes> :>
    Wes> :>      X : Space_Ptr := new Alloc_Buffer;
    Wes> :>    ...
    Wes> :>      Pass_To_Assembler(X.all'Address);

    Wes> Please note that whether you have bounds or not, you do not
    Wes> want to pass the actual pointer to assembler or C or ...

    Wes> An Ada access type is a bit pattern that can be used by code
    Wes> from the same compiler to access the item.  It does not have
    Wes> to be an address, though in most implementations it is.  It
    Wes> also does not have to be the address of the actual item, and
    Wes> in most implementations an access to an unconstrained type is
    Wes> NOT the address of the item.  Mr. Taft's example above is the
    Wes> correct way to let code from another compiler or language get
    Wes> the address of your object.  NOT unchecked conversion from
    Wes> the access type to address.  For some reason, I keep seeing
    Wes> even experienced Ada programmers use the latter (incorrect)
    Wes> method.

And if I use unconstrained arrays ? I think I'd have to pass the address
of the first element. Something like this:

  Pass_To_Assembler(X(X.all'First)'Address)


Well, I think it's time to write a Hello World. Thank you all for the help.

 - hannes

Re: Q: memory management

[Hannes Haug]

>>>>> "Robert" == Robert Dewar <dewar@cs.nyu.edu> writes:

    Robert> Hannes said "I have several 100000 memory regions of
    Robert> different, not at compile time known quite small sizes."

    Robert> I cannot conceive of any legitimate need in an Ada program
    Robert> for allocating several hundred thousand small areas of raw
    Robert> memory. Possibly one could imagine a C program doing this,
    Robert> but not an Ada program.

Imagine bignum arithmetic with garbage collection. If I'd have just
some bignums there would be too many garbage collections.

 - hannes

Re: Q: memory management

[Robert Dewar]

Hannes said

"Imagine bignum arithmetic with garbage collection. If I'd have just
some bignums there would be too many garbage collections."

No, that's not a good example, there still would be no need in Ada to be
doing low level untyped allocation.

The necessary data structures can be described in Ada, and allocated
in a safely typed manner without additional space overhead.

Re: Q: memory management

[Hannes Haug]

>>>>> "Robert" == Robert Dewar <dewar@cs.nyu.edu> writes:

    Robert> Hannes said "Imagine bignum arithmetic with garbage
    Robert> collection. If I'd have just some bignums there would be
    Robert> too many garbage collections."

    Robert> No, that's not a good example, there still would be no
    Robert> need in Ada to be doing low level untyped allocation.

    Robert> The necessary data structures can be described in Ada, and
    Robert> allocated in a safely typed manner without additional
    Robert> space overhead.

No space overhead if you deal with unconstrained arrays?

I use gmp-2 (the GNU bignum package). Perhaps I'll never look at the
contents of the memory regions form Ada. I need no safely typed Ada
structure.

Does GNAT's allocate call malloc? That would be an additional overhead
of one word (that depends on the malloc, of course) for malloc's header.

 -hannes

Re: Q: Memory management

[W. Wesley Groleau (Wes)]

Hannes suggests
>    Pass_To_Assembler ( X ( X.all'First )'Address );

X.all'First and X'First should be identical.

X'Address and X(X'First)'Address should be identical, too, unless ...

Is it legal for an implementation to store strings the way the VAX writes
arrays of bytes?  With VAX Ada 2.0 when I declared

 type X is array ( ... ) of Byte;  -- Byte is range 0 .. 255 / 'Size = 8

 package Block_IO is new Direct_IO ( X )

 then a Put ( Item => ( 1, 2, 3, 4, 5, 6, 7, 8, 9, ... ) resulted in the
 file containing 2, 1, 4, 3, 6, 5, 8, 7, ...

 I never checked whether strings did the some thing, nor did I check
 whether the addresses of the components were equally screwy.

--
---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Q: Memory management

[Hannes Haug]

>>>>> "Wes" == "W Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

    Wes> Hannes suggests
    >> Pass_To_Assembler ( X ( X.all'First )'Address );

    Wes> X.all'First and X'First should be identical.

    Wes> X'Address and X(X'First)'Address should be identical, too,
    Wes> unless ...

Is this true if you deal with unconstrained arrays ? The bounds have
to be stored at the beginning of the array. I think that X'Address
would give you the address of the location where the bounds are stored.

 -hannes

Re: Q: Memory management

[Tucker Taft]

Hannes Haug (Hannes.Haug@Student.Uni-Tuebingen.de) wrote:
: >>>>> "Wes" == "W Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:

:     Wes> Hannes suggests
:     >> Pass_To_Assembler ( X ( X.all'First )'Address );

:     Wes> X.all'First and X'First should be identical.

:     Wes> X'Address and X(X'First)'Address should be identical, too,
:     Wes> unless ...

: Is this true if you deal with unconstrained arrays ? The bounds have
: to be stored at the beginning of the array. I think that X'Address
: would give you the address of the location where the bounds are stored.

In Ada 95, the 'Address of an array is supposed to point at
the first component, independent of where the bounds are stored.
See RM95-13.3(14).

In Ada 83, it was not specified, and compilers differed
in their interpretation of 'Address on an array.
You are certainly safe using X(X'First)'Address.

On the other hand, if X is a pointer, X'Address and X.all'Address
are definitely *not* the same thing.  X'Address is the address
of the pointer, X.all'Address is the address of (the first component of)
the pointed-to object.

:  -hannes

-Tucker Taft   stt@inmet.com   http://www.inmet.com/~stt/
Intermetrics, Inc.  Cambridge, MA  USA

Re: Q: Memory management

[Robert Dewar]

"Be aware that this is only implementation advice.  I presume that all
compilers will follow it.  Why wasn't this made a hard requirement?"

(addresses pointing at first component of array)

The reason this was not made a hard requirement is that you really can't
make any formal statements about such matters. What does it mean for
an address to "point to" anything?

Also, there may be architectures in which this requirement would be a
burden.

Re: Q: Memory management

[Robert A Duff]

In article <uvvg27kjm35.fsf@chaq.informatik.uni-tuebingen.de>,
Hannes Haug  <Hannes.Haug@Student.Uni-Tuebingen.de> wrote:
>    Wes> X'Address and X(X'First)'Address should be identical, too,
>    Wes> unless ...
>
>Is this true if you deal with unconstrained arrays ?

13.3(14) says X'Address should point at the first component of the
array.  This is "merely" Implementation Advice.  But I don't see any
reason why a compiler would not obey -- and if it didn't, I would
consider it a bug.

>... The bounds have
>to be stored at the beginning of the array.

They don't *have* to be.  That's just the typical implementation of
access-to-unconstrained-arrays.  I believe GNAT doesn't do it that way,
though.  On the other hand, the typical implementation of an
unconstrained array formal parameter is to pass the bounds separately
from the data, and to pass the data by reference.

>... I think that X'Address
>would give you the address of the location where the bounds are stored.

Some Ada 83 compilers did this.  In Ada 95, however, it should not be
true.

On the other hand, if you have discriminants or a Tag field, then the RM
doesn't say anything.  See 13.3(14.a).

- Bob

Re: Q: Memory management

[Jon S Anthony]

In article <uvvg27kjm35.fsf@chaq.informatik.uni-tuebingen.de> Hannes Haug <Hannes.Haug@Student.Uni-Tuebingen.de> writes:

> >>>>> "Wes" == "W Wesley Groleau (Wes)" <wwgrol@PSESERV3.FW.HAC.COM> writes:
> 
>     Wes> Hannes suggests
>     >> Pass_To_Assembler ( X ( X.all'First )'Address );
> 
>     Wes> X.all'First and X'First should be identical.
> 
>     Wes> X'Address and X(X'First)'Address should be identical, too,
>     Wes> unless ...
> 
> Is this true if you deal with unconstrained arrays ?

Implementation defined, but probably not.

> The bounds have
> to be stored at the beginning of the array. I think that X'Address
> would give you the address of the location where the bounds are stored.

Or maybe a dope vector or ...

/Jon
-- 
Jon Anthony
Organon Motives, Inc.
1 Williston Road, Suite 4
Belmont, MA 02178

617.484.3383
jsa@organon.com

Re: Q: Memory management

[Robert Dewar]

Jon replies to Hannes saying

"> The bounds have
> to be stored at the beginning of the array. I think that X'Address
> would give you the address of the location where the bounds are stored.

Or maybe a dope vector or ..."

In GNAT, you will always get the address of the first element of the
array. This behavior is required for the type Interfaces.C.char_array,
and it seems reasonable to extend it to all unconstrained array types.

Re: Q: Memory management

[Hannes Haug]

I'm posting this for W. Wesley Groleau. His link is broken.

---------- Forwarded message ----------
Date: Wed, 26 Jun 96 16:42:13 EST
From: W. Wesley Groleau <wwgrol@pseserv3.fw.hac.com>
To: hannes.haug@student.uni-tuebingen.de
Cc: wwgrol@pseserv3.fw.hac.com
Subject: Re: Q: memory management (fwd)

My link to comp.lang.ada is broken.  Would you mind (re)posting this?

    Wes> X'Address and X(X'First)'Address should be identical, too,

Is this true if you deal with unconstrained arrays ? The bounds have
to be stored at the beginning of the array. I think that X'Address
would give you the address of the location where the bounds are stored.

LRM 13.3 (14)  ADVISES that 'Address point to the array, not to the
bounds.  But (OUCH!) it does not require it.  In LRM-83, 13.7.2 is
not clear.

Ouch!  So, Hannes, to be safe, I guess you must assume that
X'Address and X(X'First)'Address are NOT identical!

But on the other point:  The LRM requires that the bounds checks happen,
which implies that the bounds exist, but it doesn't specify how.
Some possibilities:

   the pointer points to the bounds and the actual array is immediately
   afterward. (Verdix)

   the pointer points to the actual array and the bounds are immediately
   before (Alsys compiler)

   the pointer points to an invisible record containing the bounds and
   the address of the actual array

   the pointer IS such a record in the current stack frame

   the pointer contains the address of the bounds AND of the array

   the pointer is an index to one or more arrays containing
   whatever is needed.

   the pointer is a long or short address (according to what?) that
   somehow enables access (gnat on Solaris)

   The CPU has so many registers that the compiler is able to keep
   the array bounds in registers in some subprograms.

   the compiler symbol table is embedded in the executable, updated at
   run time, and used to check the bounds.

   a custom hardware ESP chip is used to pluck the bounds directly
   from the Akashic Records where they were automatically recorded
   as a side-effect of the programmer's mental activity.

(I didn't say they were all practical.)

Also, I could be wrong, but I think that there are compilers that handle
the bounds of constrained arrays the same way as unconstrained.

---------------------------------------------------------------------------
W. Wesley Groleau (Wes)                                Office: 219-429-4923
Magnavox - Mail Stop 10-40                               Home: 219-471-7206
Fort Wayne,  IN   46808              elm (Unix): wwgrol@pseserv3.fw.hac.com
---------------------------------------------------------------------------

Re: Q: Memory management

[Hannes Haug]

I think I didn't understand the concept uf unconstrained arrays. There
are no constrained arrays. All arrays 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 ?

 -hannes

Re: Q: Memory management

[Robert A Duff]

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

Re: Q: Memory management

[Hannes Haug]

>>>>> "Robert" == Robert A Duff <bobduff@world.std.com> writes:

    Robert> In article
    Robert> <uvvybl91xtl.fsf@chaq.informatik.uni-tuebingen.de>, Hannes
    Robert> 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.

    Robert> All array *objects* are constrained.

That's what I meant.

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

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

That's what I meant by "at least logically" ;-)

    Robert> [...]

 -hannes