Re: Largest size array in Gnat 2005 for the PC?
- From: anon@xxxxxxxx (anon)
- Date: Wed, 31 Oct 2007 06:32:52 GMT
--
-- 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@xxxxxxxxxxxxxxxxxx>, "ME" <abcdefg@xxxxxxxxxxxx> 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?
.
- References:
- Prev by Date: Re: Largest size array in Gnat 2005 for the PC?
- Next by Date: Re: Largest size array in Gnat 2005 for the PC?
- Previous by thread: Re: Largest size array in Gnat 2005 for the PC?
- Next by thread: Problem with GNAT GPL 2007.1 win32Ada bindings
- Index(es):
Relevant Pages
|
