From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-0.3 required=5.0 tests=BAYES_00, REPLYTO_WITHOUT_TO_CC autolearn=no autolearn_force=no version=3.4.4 X-Google-Thread: 103376,6b3ebf057333800c X-Google-Attributes: gid103376,public,usenet X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news2.google.com!news1.google.com!news.glorb.com!wn11feed!worldnet.att.net!bgtnsc04-news.ops.worldnet.att.net.POSTED!53ab2750!not-for-mail Newsgroups: comp.lang.ada From: anon@anon.org (anon) Subject: Re: Largest size array in Gnat 2005 for the PC? Reply-To: anon@anon.org (anon) References: <13idb3jbm28kfbe@corp.supernews.com> X-Newsreader: IBM NewsReader/2 2.0 Message-ID: Date: Wed, 31 Oct 2007 06:32:52 GMT NNTP-Posting-Host: 12.64.216.187 X-Complaints-To: abuse@worldnet.att.net X-Trace: bgtnsc04-news.ops.worldnet.att.net 1193812372 12.64.216.187 (Wed, 31 Oct 2007 06:32:52 GMT) NNTP-Posting-Date: Wed, 31 Oct 2007 06:32:52 GMT Organization: AT&T Worldnet Xref: g2news2.google.com comp.lang.ada:2670 Date: 2007-10-31T06:32:52+00:00 List-Id: -- -- 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" 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? > >