Re: Q: memory management

[stt@henning.camb.inmet.com (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