Re: Largest size array in Gnat 2005 for the PC?

[anon@anon.org (anon)]

--
-- With the following info from GNAT Users Guide, it seams that GNAT 
-- limits an arrays to default to 32-bit size on a 32-bit machine. 
-- Since you can not access more than 32-bits for an access type
-- aka for arrays ( Array'ADDRESS + Array_index ) then your array is 
-- limited to:
--
--     2GB >= ( 32-bits / Array_Element_Type'SIZE )
-- 
-- The documentation also states GNAT limits memory access to 2G 
-- for a 32-bit systems
-- 


-- From the "Compatibility and Porting Guide" aka Appendix E of 
-- the GNAT User Guide. GCC-GNAT-4.3.0

-- QUOTE

        A common assumption in Ada 83 code is that an access type is 
in fact a pointer, and that therefore it will be the same size as a 
System.Address value.  This assumption is true for GNAT in most cases 
with one exception.  For the case of a pointer to an unconstrained 
array type (where the bounds may vary from one value of the access 
type to another), the default is to use a "fat pointer", which is 
represented as two separate pointers, one to the bounds, and one to 
the array.  This representation has a number of advantages, including 
improved efficiency.  However, it may cause some difficulties in 
porting existing Ada 83 code which makes the assumption that, for 
example, pointers fit in 32 bits on a machine with 32-bit addressing.

        To get around this problem, GNAT also permits the use of 
"thin pointers" for access types in this case (where the designated 
type is an unconstrained array type).  These thin pointers are indeed 
the same size as a System.Address value. 

To specify a thin pointer, use a size clause for the type, for example:

        type X is access all String;
        for X'Size use Standard'Address_Size;

which will cause the type X to be represented using a single pointer.
When using this representation, the bounds are right behind the array.
This representation is slightly less efficient, and does not allow quite
such flexibility in the use of foreign pointers or in using the
Unrestricted_Access attribute to create pointers to non-aliased objects.
But for any standard portable use of the access type it will work in
a functionally correct manner and allow porting of existing code.
Note that another way of forcing a thin pointer representation
is to use a component size clause for the element size in an array,
or a record representation clause for an access field in a record.

-- QUOTE

-- Transitioning to 64-Bit GNAT for OpenVMS

-- QUOTE

Migration of 32 bit code, will focus on porting applications
that do not require more than 2 GB of addressable memory. This 
code will be referred to as 32-bit code.

-- QUOTE

-- QUOTE

By default, objects designated by access values are always
allocated in the 32-bit address space. Thus legacy code will 
never contain any objects that are not addressable with 32-bit 
addresses, and the compiler will never raise exceptions as 
result of mixing 32-bit and 64-bit addresses.

-- QUOTE


In <13idb3jbm28kfbe@corp.supernews.com>, "ME" <abcdefg@nonodock.net> writes:
>What is the largest array (in storage units) that you can declare in Gnat 
>2005 for the PC?
>Does pragma Storage_ size affect this and if so where would you place it in 
>a procedure? 
>
>