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

["ME" <abcdefg@nonodock.net>]

If GNAT placed "IMAGE_FILE_LARGE_ADDRESS_AWARE" in the process headers for 
GNAT executables then you could use up to 3Gb of memory. Seems like a simple 
thing to implement.


"anon" <anon@anon.org> wrote in message 
news:okVVi.38106$kj1.30067@bgtnsc04-news.ops.worldnet.att.net...
> --
> -- 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:
> --
Thanks for answering my original question. Isn't there a "2^" somewhere in 
your equation?
> --     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?
>>
>>
>