* Largest size array in Gnat 2005 for the PC? @ 2007-10-30 4:00 ME 2007-10-30 7:08 ` Martin Krischik ` (3 more replies) 0 siblings, 4 replies; 35+ messages in thread From: ME @ 2007-10-30 4:00 UTC (permalink / raw) 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? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 4:00 Largest size array in Gnat 2005 for the PC? ME @ 2007-10-30 7:08 ` Martin Krischik 2007-10-30 12:27 ` Florian Weimer ` (3 more replies) 2007-10-30 7:28 ` Pascal Obry ` (2 subsequent siblings) 3 siblings, 4 replies; 35+ messages in thread From: Martin Krischik @ 2007-10-30 7:08 UTC (permalink / raw) ME schrieb: > What is the largest array (in storage units) that you can declare in Gnat > 2005 for the PC? How much virtual memory does your computer have? > Does pragma Storage_ size affect this and if so where would you place it in > a procedure? No, the array index used affect the maximum size. I suggest you read: http://en.wikibooks.org/wiki/Ada_Programming/Types/array and consider what would happen if "Index_Range" is of type Long_Long_Integer and if you computer has enough memory to hold such a beast. Martin PS: There is no "GNAT 2005" - There is 1) "GNAT GPL 2005" which is 3 releases old - the current release is GNAT GPL 2007-2 2) Ada 2005: which is a standard and as such puts no restriction or arrays size whatsoever. -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 7:08 ` Martin Krischik @ 2007-10-30 12:27 ` Florian Weimer 2007-10-30 14:16 ` ME ` (2 subsequent siblings) 3 siblings, 0 replies; 35+ messages in thread From: Florian Weimer @ 2007-10-30 12:27 UTC (permalink / raw) * Martin Krischik: > No, the array index used affect the maximum size. I suggest you read: > > http://en.wikibooks.org/wiki/Ada_Programming/Types/array > > and consider what would happen if "Index_Range" is of type > Long_Long_Integer and if you computer has enough memory to hold such a > beast. The problem in past GNAT versions was that 'Size was not actually a univeral integer, but a 32-bit type. Since it's measured in bits, it limits object size to 256 MB on all architectures. Has this been fixed? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 7:08 ` Martin Krischik 2007-10-30 12:27 ` Florian Weimer @ 2007-10-30 14:16 ` ME 2007-10-30 14:47 ` Pascal Obry 2007-10-30 18:58 ` Martin Krischik 2007-10-30 16:07 ` virtual memory, was " tmoran 2007-10-31 5:53 ` ME 3 siblings, 2 replies; 35+ messages in thread From: ME @ 2007-10-30 14:16 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:4726d889$1@news.post.ch... > ME schrieb: > >> What is the largest array (in storage units) that you can declare in Gnat >> 2005 for the PC? > > How much virtual memory does your computer have? > >> Does pragma Storage_ size affect this and if so where would you place it >> in >> a procedure? > > No, the array index used affect the maximum size. I suggest you read: so then Type My_Array is array (1..Long_Long_Integer'last) of record... is fine? > > http://en.wikibooks.org/wiki/Ada_Programming/Types/array > > and consider what would happen if "Index_Range" is of type > Long_Long_Integer and if you computer has enough memory to hold such a > beast. > > Martin > > PS: There is no "GNAT 2005" - There is > > 1) "GNAT GPL 2005" which is 3 releases old - the current release is GNAT > GPL 2007-2 > 2) Ada 2005: which is a standard and as such puts no restriction or > arrays size whatsoever. > > -- > mailto://krischik@users.sourceforge.net > Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 14:16 ` ME @ 2007-10-30 14:47 ` Pascal Obry 2007-10-30 18:58 ` Martin Krischik 1 sibling, 0 replies; 35+ messages in thread From: Pascal Obry @ 2007-10-30 14:47 UTC (permalink / raw) To: ME ME a �crit : > so then > Type My_Array is array (1..Long_Long_Integer'last) of record... > is fine? No this can't possibly work it is far too big to fit on the stack and too big to fit on the heap too. There is not way to deal with such large object on memory with today computer. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 14:16 ` ME 2007-10-30 14:47 ` Pascal Obry @ 2007-10-30 18:58 ` Martin Krischik 2007-10-31 5:38 ` ME 1 sibling, 1 reply; 35+ messages in thread From: Martin Krischik @ 2007-10-30 18:58 UTC (permalink / raw) ME wrote: >> How much virtual memory does your computer have? >> >>> Does pragma Storage_ size affect this and if so where would you place it >>> in >>> a procedure? >> >> No, the array index used affect the maximum size. I suggest you read: > so then > Type My_Array is array (1..Long_Long_Integer'last) of ï¿œrecord... > is fine? >> No, it means that your computer is running out of memory before GNAT does. Tell me what computer/os you got and I tell you how large your array can be. On most 32 bit OS it will be 2**31 byte. A few selected 32 bit OS it will be 2*32 byte. On a (propper) 64 bit OS your swap file will fill your hardrive first. Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 18:58 ` Martin Krischik @ 2007-10-31 5:38 ` ME 0 siblings, 0 replies; 35+ messages in thread From: ME @ 2007-10-31 5:38 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:1948519.DJ9jiXYulm@linux1.krischik.com... > ME wrote: > >>> How much virtual memory does your computer have? >>> >>>> Does pragma Storage_ size affect this and if so where would you place >>>> it >>>> in >>>> a procedure? >>> >>> No, the array index used affect the maximum size. I suggest you read: >> so then >> Type My_Array is array (1..Long_Long_Integer'last) of record... >> is fine? >>> > > No, it means that your computer is running out of memory before GNAT does. > Tell me what computer/os you got and I tell you how large your array can > be. Win XP SP2 > > On most 32 bit OS it will be 2**31 byte. > A few selected 32 bit OS it will be 2*32 byte. > On a (propper) 64 bit OS your swap file will fill your hardrive first. > > Martin > > -- > mailto://krischik@users.sourceforge.net > Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* virtual memory, was Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 7:08 ` Martin Krischik 2007-10-30 12:27 ` Florian Weimer 2007-10-30 14:16 ` ME @ 2007-10-30 16:07 ` tmoran 2007-10-30 19:17 ` Martin Krischik 2007-10-30 20:35 ` Ludovic Brenta 2007-10-31 5:53 ` ME 3 siblings, 2 replies; 35+ messages in thread From: tmoran @ 2007-10-30 16:07 UTC (permalink / raw) >How much virtual memory does your computer have? I wonder how many programmers today have any experience with the judicious use of virtual memory. PC users almost always buy enough physical memory to satisfy all their apps, and with 32 bit machines that was cheap and easy. There will probably also be a learning curve as todays' programmers find out what "judicious use" means w.r.t. multiple CPUs. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: virtual memory, was Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 16:07 ` virtual memory, was " tmoran @ 2007-10-30 19:17 ` Martin Krischik 2007-10-30 20:35 ` Ludovic Brenta 1 sibling, 0 replies; 35+ messages in thread From: Martin Krischik @ 2007-10-30 19:17 UTC (permalink / raw) tmoran@acm.org wrote: >>How much virtual memory does your computer have? > I wonder how many programmers today have any experience with the > judicious use of virtual memory. PC users almost always buy enough > physical memory to satisfy all their apps, and with 32 bit machines > that was cheap and easy. > There will probably also be a learning curve as todays' programmers > find out what "judicious use" means w.r.t. multiple CPUs. Yes indeed. Actually my comment was meant with a little sarcastic twist. ;-) Martin -- mailto://krischik@users.sourceforge.net Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: virtual memory, was Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 16:07 ` virtual memory, was " tmoran 2007-10-30 19:17 ` Martin Krischik @ 2007-10-30 20:35 ` Ludovic Brenta 1 sibling, 0 replies; 35+ messages in thread From: Ludovic Brenta @ 2007-10-30 20:35 UTC (permalink / raw) tmoran@acm.org writes: >>How much virtual memory does your computer have? > I wonder how many programmers today have any experience with the > judicious use of virtual memory. PC users almost always buy enough > physical memory to satisfy all their apps, and with 32 bit machines > that was cheap and easy. > There will probably also be a learning curve as todays' programmers > find out what "judicious use" means w.r.t. multiple CPUs. My laptop has two cores and two gigs of memory. I routinely build GCC 4.2 in a 1280-MiB tmpfs in memory. This is large enough for all temporary files; at the end of the build, just under 990 MiB are still in use. The build uses 3 threads (i.e. one more than the number of cores) and the system uses approximately 400 Mb of physical swap, but that's because I keep X, emacs and galeon running all the time :) No thrashing takes place and the system is very responsive even during a build. In my experience, building in a tmpfs is approximately 3 times as fast as on a regulsr (XFS) filesystem, even though the kernel has lots of physical memory to use as a disk cache. I suggested this solution to Xavier Grave, who builds GCC 4.2 on a dual-core, dual-thread POWER5 machine with 8 GiB of physical RAM. He also reported a three-fold improvement (roughly) even though each of the cores has a 36 MiB level 3 cache that can probably hold all of GCC :) Note that we didn't even bother to measure the improvement precisely, so it is very unscientific. -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 7:08 ` Martin Krischik ` (2 preceding siblings ...) 2007-10-30 16:07 ` virtual memory, was " tmoran @ 2007-10-31 5:53 ` ME 3 siblings, 0 replies; 35+ messages in thread From: ME @ 2007-10-31 5:53 UTC (permalink / raw) "Martin Krischik" <krischik@users.sourceforge.net> wrote in message news:4726d889$1@news.post.ch... > ME schrieb: > >> What is the largest array (in storage units) that you can declare in Gnat >> 2005 for the PC? > > How much virtual memory does your computer have? I have ~1500Mb > >> Does pragma Storage_ size affect this and if so where would you place it >> in >> a procedure? > > No, the array index used affect the maximum size. I suggest you read: > > http://en.wikibooks.org/wiki/Ada_Programming/Types/array > > and consider what would happen if "Index_Range" is of type > Long_Long_Integer and if you computer has enough memory to hold such a > beast. > > Martin > > PS: There is no "GNAT 2005" - There is > > 1) "GNAT GPL 2005" which is 3 releases old - the current release is GNAT > GPL 2007-2 > 2) Ada 2005: which is a standard and as such puts no restriction or > arrays size whatsoever. > > -- > mailto://krischik@users.sourceforge.net > Ada programming at: http://ada.krischik.com ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 4:00 Largest size array in Gnat 2005 for the PC? ME 2007-10-30 7:08 ` Martin Krischik @ 2007-10-30 7:28 ` Pascal Obry 2007-10-30 9:47 ` Ludovic Brenta 2007-10-30 13:50 ` ME 2007-10-30 17:27 ` anon 2007-10-31 6:32 ` anon 3 siblings, 2 replies; 35+ messages in thread From: Pascal Obry @ 2007-10-30 7:28 UTC (permalink / raw) To: ME ME a �crit : > 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? It depends if you want to allocate it on the stack or on the heap. The stack is often smaller but the size can be changed at link time. The heap can use all the memory (physical + virtual) that you have on your computer. There is a limit in the size allocated by a single object imposed by the OS depending on the architecture (32bits / 64bits). Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 7:28 ` Pascal Obry @ 2007-10-30 9:47 ` Ludovic Brenta 2007-10-30 19:26 ` Georg Bauhaus 2007-10-30 13:50 ` ME 1 sibling, 1 reply; 35+ messages in thread From: Ludovic Brenta @ 2007-10-30 9:47 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain; charset="us-ascii", Size: 1505 bytes --] Pascal Obry wrote: > ME a écrit : > > > 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? > > It depends if you want to allocate it on the stack or on the heap. The > stack is often smaller but the size can be changed at link time. The > heap can use all the memory (physical + virtual) that you have on your > computer. There is a limit in the size allocated by a single object > imposed by the OS depending on the architecture (32bits / 64bits). In fact, if you use the heap with any recent operating system, you cannot use physical memory but only virtual memory; the operating system will then map some of that to physical memory, some to paging space, and the memory you don't actually read or write may remain uncommitted (not mapped to any physical storage). Of course, the amount of available virtual memory also depends on the other processes present in the system when you allocate your big array. The operating system may impose further restrictions on the amount of virtual memory you can use. Two examples: - it reserves part of the virtual address space for its own use; - there may be quotas that restrict any one user or process from using more than X megabytes of virtual memory. - on *nix systems, there may be a "ulimit -v" in effect. In short, the answer is: "it depends" :) -- Ludovic Brenta. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 9:47 ` Ludovic Brenta @ 2007-10-30 19:26 ` Georg Bauhaus 2007-10-30 20:17 ` Adam Beneschan 2007-10-30 20:24 ` Adam Beneschan 0 siblings, 2 replies; 35+ messages in thread From: Georg Bauhaus @ 2007-10-30 19:26 UTC (permalink / raw) On Tue, 2007-10-30 at 02:47 -0700, Ludovic Brenta wrote: > Pascal Obry wrote: > > ME a crit : > > > > > What is the largest array (in storage units) that you can declare in Gnat > > > 2005 for the PC? > In short, the answer is: "it depends" :) Indeed, it depends;-) I thought that declaring an array *type* of enormous size is not a problem, since there is no object yet. It isn't a problem. So maybe using portions of the array might work (when the program is not actually using physical memory.) I get unexpected results,though, but they are consistently produced by two unrelated compilers targeting two (seemingly unrelated) machines! This is the only hint I have found in the assembly listing; '?' is $63, '!' is $33, this is for the lines assigning Fst and Lst in the second declare block below. Notice the -1 for the stack offset movl $0, %eax movb $33, -1(%ebp,%eax) -- ( Fst := '!' ) movl $0, %eax movb $63, -1(%ebp,%eax) -- ( Lst := '?' ) Is there a bug in the following program or maybe I'm just dense? with Ada.Text_IO; procedure stk is use Ada; type Big_Index is range 0 .. 2**50; type A is array (Big_Index range <>) of Character; begin -- output is "!?" declare X: A (Big_Index range 2**40 .. 2**40 + 10_000); Fst: Character renames X(X'First); Lst: Character renames X(X'Last); begin Fst := '!'; Lst := '?'; Text_IO.Put(Fst); Text_IO.Put(Lst); Text_IO.New_Line; end; -- output is "??" declare X: A (Big_Index range 2**40 .. 2**48); Fst: Character renames X(X'First); Lst: Character renames X(X'Last); begin Fst := '!'; Lst := '?'; pragma assert(Fst = '!'); Text_IO.Put(Fst); Text_IO.Put(Lst); Text_IO.New_Line; end; end stk; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 19:26 ` Georg Bauhaus @ 2007-10-30 20:17 ` Adam Beneschan 2007-10-30 22:53 ` tmoran 2007-10-30 20:24 ` Adam Beneschan 1 sibling, 1 reply; 35+ messages in thread From: Adam Beneschan @ 2007-10-30 20:17 UTC (permalink / raw) On Oct 30, 12:26 pm, Georg Bauhaus <rm.tsoh +bauh...@maps.futureapps.de> wrote: > On Tue, 2007-10-30 at 02:47 -0700, Ludovic Brenta wrote: > > Pascal Obry wrote: > > > ME a crit : > > > > > What is the largest array (in storage units) that you can declare in Gnat > > > > 2005 for the PC? > > In short, the answer is: "it depends" :) > > Indeed, it depends;-) I thought that declaring an array *type* > of enormous size is not a problem, since there is no object > yet. It isn't a problem. So maybe using portions of the array might > work (when the program is not actually using physical memory.) > I get unexpected results,though, but they are consistently produced > by two unrelated compilers targeting two (seemingly unrelated) > machines! > > This is the only hint I have found in the assembly > listing; '?' is $63, '!' is $33, this is for the lines > assigning Fst and Lst in the second declare block below. > Notice the -1 for the stack offset > > movl $0, %eax > movb $33, -1(%ebp,%eax) -- ( Fst := '!' ) > movl $0, %eax > movb $63, -1(%ebp,%eax) -- ( Lst := '?' ) > > Is there a bug in the following program or maybe I'm just dense? EAX is a 32-bit register, right? (We weren't told what processor Georg is running on---but the above looks like Pentium/80x86 to me.) So to assign into the first element of Fst, the offset from the beginning of the array is 0; to assign into the last element, the offset will be (2**48 - 2**40) which is 255 * 2**40, which is way too big to fit into a 32-bit register, so apparently the compiler is truncating to 0 before setting EAX. The same would happen when it reads from the array to print the result, so that's why you're seeing ?? as output. But you're declaring an array object X of size 255*(2**40), which can't be handled on a machine with a 32-bit address space; so I'm confused about why you'd expect the program to work, unless one of the two machines you're referring to has a 64-bit address space and the compiler is generating incorrect code anyway. Or unless I'm totally confused as to what you're asking. Anyway, however, this looks like a compiler bug---if it is unable to generate correct code because of the array size, it should reject the program. -- Adam > > with Ada.Text_IO; > > procedure stk is > > use Ada; > > type Big_Index is range 0 .. 2**50; > > type A is array (Big_Index range <>) of Character; > > begin > > -- output is "!?" > declare > X: A (Big_Index range 2**40 .. 2**40 + 10_000); > Fst: Character renames X(X'First); > Lst: Character renames X(X'Last); > begin > Fst := '!'; > Lst := '?'; > > Text_IO.Put(Fst); > Text_IO.Put(Lst); > Text_IO.New_Line; > end; > > -- output is "??" > declare > X: A (Big_Index range 2**40 .. 2**48); > Fst: Character renames X(X'First); > Lst: Character renames X(X'Last); > begin > Fst := '!'; > Lst := '?'; > pragma assert(Fst = '!'); > > Text_IO.Put(Fst); > Text_IO.Put(Lst); > Text_IO.New_Line; > end; > end stk; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 20:17 ` Adam Beneschan @ 2007-10-30 22:53 ` tmoran 2007-10-30 23:39 ` Georg Bauhaus 0 siblings, 1 reply; 35+ messages in thread From: tmoran @ 2007-10-30 22:53 UTC (permalink / raw) > too big to fit into a 32-bit register, so apparently the compiler is > truncating to 0 before setting EAX. Do you get the same result when you compile in Ada mode, ie, with the -gnato option? ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 22:53 ` tmoran @ 2007-10-30 23:39 ` Georg Bauhaus 0 siblings, 0 replies; 35+ messages in thread From: Georg Bauhaus @ 2007-10-30 23:39 UTC (permalink / raw) On Tue, 2007-10-30 at 17:53 -0500, tmoran@acm.org wrote: > > too big to fit into a 32-bit register, so apparently the compiler is > > truncating to 0 before setting EAX. > Do you get the same result when you compile in Ada mode, ie, with > the -gnato option? Yes, same results. Using -fstack-check adds a warning that the frame size is too large, the debugging switch -gnatdF yields a compilation error saying that the subtype of a is too large... (Which it is, obviously). ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 19:26 ` Georg Bauhaus 2007-10-30 20:17 ` Adam Beneschan @ 2007-10-30 20:24 ` Adam Beneschan 2007-10-30 21:40 ` Georg Bauhaus 1 sibling, 1 reply; 35+ messages in thread From: Adam Beneschan @ 2007-10-30 20:24 UTC (permalink / raw) On Oct 30, 12:26 pm, Georg Bauhaus <rm.tsoh +bauh...@maps.futureapps.de> wrote: > On Tue, 2007-10-30 at 02:47 -0700, Ludovic Brenta wrote: > > Pascal Obry wrote: > > > ME a crit : > > > > > What is the largest array (in storage units) that you can declare in Gnat > > > > 2005 for the PC? > > In short, the answer is: "it depends" :) > > Indeed, it depends;-) I thought that declaring an array *type* > of enormous size is not a problem, since there is no object > yet. It isn't a problem. So maybe using portions of the array might > work (when the program is not actually using physical memory.) > I get unexpected results,though, but they are consistently produced > by two unrelated compilers targeting two (seemingly unrelated) > machines! > > This is the only hint I have found in the assembly > listing; '?' is $63, '!' is $33, this is for the lines > assigning Fst and Lst in the second declare block below. > Notice the -1 for the stack offset > > movl $0, %eax > movb $33, -1(%ebp,%eax) -- ( Fst := '!' ) > movl $0, %eax > movb $63, -1(%ebp,%eax) -- ( Lst := '?' ) > > Is there a bug in the following program or maybe I'm just dense? EAX is a 32-bit register, right? (We weren't told what processor Georg is running on---but the above looks like Pentium/80x86 to me.) So to assign into the first element of Fst, the offset from the beginning of the array is 0; to assign into the last element, the offset will be (2**48 - 2**40) which is 255 * 2**40, which is way too big to fit into a 32-bit register, so apparently the compiler is truncating to 0 before setting EAX. The same would happen when it reads from the array to print the result, so that's why you're seeing ?? as output. But you're declaring an array object X of size 255*(2**40), which can't be handled on a machine with a 32-bit address space; so I'm confused about why you'd expect the program to work, unless one of the two machines you're referring to has a 64-bit address space and the compiler is generating incorrect code anyway. Or unless I'm totally confused as to what you're asking. Anyway, however, this looks like a compiler bug---if it is unable to generate correct code because of the array size, it should reject the program. -- Adam > > with Ada.Text_IO; > > procedure stk is > > use Ada; > > type Big_Index is range 0 .. 2**50; > > type A is array (Big_Index range <>) of Character; > > begin > > -- output is "!?" > declare > X: A (Big_Index range 2**40 .. 2**40 + 10_000); > Fst: Character renames X(X'First); > Lst: Character renames X(X'Last); > begin > Fst := '!'; > Lst := '?'; > > Text_IO.Put(Fst); > Text_IO.Put(Lst); > Text_IO.New_Line; > end; > > -- output is "??" > declare > X: A (Big_Index range 2**40 .. 2**48); > Fst: Character renames X(X'First); > Lst: Character renames X(X'Last); > begin > Fst := '!'; > Lst := '?'; > pragma assert(Fst = '!'); > > Text_IO.Put(Fst); > Text_IO.Put(Lst); > Text_IO.New_Line; > end; > end stk; ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 20:24 ` Adam Beneschan @ 2007-10-30 21:40 ` Georg Bauhaus 2007-10-30 21:48 ` Adam Beneschan 2007-10-30 21:50 ` Georg Bauhaus 0 siblings, 2 replies; 35+ messages in thread From: Georg Bauhaus @ 2007-10-30 21:40 UTC (permalink / raw) On Tue, 2007-10-30 at 13:24 -0700, Adam Beneschan wrote: > On Oct 30, 12:26 pm, Georg Bauhaus <rm.tsoh > > Is there a bug in the following program or maybe I'm just dense? > > EAX is a 32-bit register, right? Yes, i686 Linux in this case. When I ask the compiler for 64bit code, then I see occurrences of $280375465082880, which is 2**48 - 2**40. > So to assign into the first element of Fst, the offset from the > beginning of the array is 0; to assign into the last element, the > offset will be (2**48 - 2**40) which is 255 * 2**40, which is way too > big to fit into a 32-bit register, so apparently the compiler is > truncating to 0 before setting EAX. Ah, yes. Could exceeding size have produced the -1 in -1(%ebp,%eax), %eax too? It is -10002(%ebp,%eax), %eax for the "normal size" array of 10_000 elements? > But you're declaring an array object X of size 255*(2**40), which > can't be handled on a machine with a 32-bit address space; so I'm > confused about why you'd expect the program to work, I didn't expect this program to work, really, other than through advanced OS magic or due to my limited knowledge of Ada details. Another compiler, though, targeting a 64bit platform, produces the exact same output. So I hesitated to say that they both are producing incorrect code for this case. But: > Anyway, however, this looks like a > compiler bug---if it is unable to generate correct code because of the > array size, it should reject the program. Thanks for explaining this. Oh, there is more evidence as I write this. I don't have a recent GCC right now to see whether this is still a bug; I'll try to build one, but if one of you has a recent GCC and can reproduce the behavior, you'd be saving me a few minutes this weekend :-) -Os was the crucial addition to the command line. kartoffel% gnatmake -W -gnatp -S -s -march=x86-64 -m64 -Os stk.adb gcc-4.1 -c -W -gnatp -S -march=x86-64 -m64 -Os stk.adb +===========================GNAT BUG DETECTED==============================+ | 4.1.2 (Ubuntu 4.1.2-0ubuntu4) (i486-pc-linux-gnu) GCC error: | | in pro_epilogue_adjust_stack, at config/i386/i386.c:5094 | | Error detected at stk.adb:41:5 | | Please submit a bug report; see http://gcc.gnu.org/bugs.html. | | Use a subject line meaningful to you and us to track the bug. | | Include the entire contents of this bug box in the report. | | Include the exact gcc-4.1 or gnatmake command that you entered. | | Also include sources listed below in gnatchop format | | (concatenated together with no headers between files). | +==========================================================================+ Please include these source files with error report Note that list may not be accurate in some cases, so please double check that the problem can still be reproduced with the set of files listed. stk.adb raised TYPES.UNRECOVERABLE_ERROR : comperr.adb:380 gnatmake: "stk.adb" compilation error ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 21:40 ` Georg Bauhaus @ 2007-10-30 21:48 ` Adam Beneschan 2007-10-30 21:50 ` Georg Bauhaus 1 sibling, 0 replies; 35+ messages in thread From: Adam Beneschan @ 2007-10-30 21:48 UTC (permalink / raw) On Oct 30, 2:40 pm, Georg Bauhaus <rm.tsoh+bauh...@maps.futureapps.de> wrote: > On Tue, 2007-10-30 at 13:24 -0700, Adam Beneschan wrote: > > On Oct 30, 12:26 pm, Georg Bauhaus <rm.tsoh > > > Is there a bug in the following program or maybe I'm just dense? > > > EAX is a 32-bit register, right? > > Yes, i686 Linux in this case. When I ask the compiler for > 64bit code, then I see occurrences of $280375465082880, > which is 2**48 - 2**40. > > > So to assign into the first element of Fst, the offset from the > > beginning of the array is 0; to assign into the last element, the > > offset will be (2**48 - 2**40) which is 255 * 2**40, which is way too > > big to fit into a 32-bit register, so apparently the compiler is > > truncating to 0 before setting EAX. > > Ah, yes. Could exceeding size have produced the -1 in > -1(%ebp,%eax), %eax > too? It is > -10002(%ebp,%eax), %eax > for the "normal size" array of 10_000 elements? Your array is 10_001 elements, actually. I haven't studied code produced by GNAT very much, but -1 just looks like the starting point for where things are allocated (downward) from the current stack frame pointer (EBP); exceeding size would have produced -1 in that if the compiler truncates the array size and thinks the size is 0, then the resulting offset would have been -1. I'll bet that if you declared an array of one byte, you would have seen -2(%ebp,%eax); if it were two bytes, -3(%ebp,%eax), and so on. I'm just speculating, though... I haven't tried this myself. -- Adam ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 21:40 ` Georg Bauhaus 2007-10-30 21:48 ` Adam Beneschan @ 2007-10-30 21:50 ` Georg Bauhaus 1 sibling, 0 replies; 35+ messages in thread From: Georg Bauhaus @ 2007-10-30 21:50 UTC (permalink / raw) On Tue, 2007-10-30 at 22:40 +0100, Georg Bauhaus wrote: > Ah, yes. Could exceeding size have produced the -1 in > -1(%ebp,%eax), %eax > too? It is > -10002(%ebp,%eax), %eax > for the "normal size" array of 10_000 elements? s. ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 7:28 ` Pascal Obry 2007-10-30 9:47 ` Ludovic Brenta @ 2007-10-30 13:50 ` ME 2007-10-30 14:44 ` Pascal Obry 1 sibling, 1 reply; 35+ messages in thread From: ME @ 2007-10-30 13:50 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 1263 bytes --] "Pascal Obry" <pascal@obry.net> wrote in message news:4726DD25.7080205@obry.net... > ME a �crit : >> 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? > > It depends if you want to allocate it on the stack or on the heap. I am using the stack. how do I change this at link time using GPL? The > stack is often smaller but the size can be changed at link time. The > heap can use all the memory (physical + virtual) that you have on your > computer. There is a limit in the size allocated by a single object > imposed by the OS depending on the architecture (32bits / 64bits). I am using Windows XP SP2 so my OS is 32 bits. You don't happen to know what the limit is for Windows XP SP2 ? > > Pascal. > > -- > > --|------------------------------------------------------ > --| Pascal Obry Team-Ada Member > --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE > --|------------------------------------------------------ > --| http://www.obry.net > --| "The best way to travel is by means of imagination" > --| > --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 13:50 ` ME @ 2007-10-30 14:44 ` Pascal Obry 2007-10-30 15:00 ` Stefan Bellon 0 siblings, 1 reply; 35+ messages in thread From: Pascal Obry @ 2007-10-30 14:44 UTC (permalink / raw) To: ME ME a �crit : > I am using the stack. how do I change this at link time using GPL? There is no option for that use "new" to allocate the array instead of declaring it on the stack. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 14:44 ` Pascal Obry @ 2007-10-30 15:00 ` Stefan Bellon 2007-10-30 15:16 ` Pascal Obry 2007-10-31 5:52 ` ME 0 siblings, 2 replies; 35+ messages in thread From: Stefan Bellon @ 2007-10-30 15:00 UTC (permalink / raw) On Tue, 30 Oct, Pascal Obry wrote: > ME a écrit : > > I am using the stack. how do I change this at link time using GPL? > > There is no option for that use "new" to allocate the array instead of > declaring it on the stack. While I agree with the given suggestion to allocate large objects on the heap instead of the stack, there is a way to increase the stack size on Windows. We use something like the following in our projects where we need a larger stack on Windows: package Linker is case OS is when "UNIX" => null; when "Windows_NT" => for Default_Switches ("ada") use ("--stack=0x2000000,0x10000"); end case; end Linker; -- Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 15:00 ` Stefan Bellon @ 2007-10-30 15:16 ` Pascal Obry 2007-10-30 15:22 ` Stefan Bellon 2007-10-31 5:52 ` ME 1 sibling, 1 reply; 35+ messages in thread From: Pascal Obry @ 2007-10-30 15:16 UTC (permalink / raw) To: Stefan Bellon Stefan Bellon a �crit : > While I agree with the given suggestion to allocate large objects on > the heap instead of the stack, there is a way to increase the stack > size on Windows. We use something like the following in our projects Yes, but this was not the OP question. Pascal. -- --|------------------------------------------------------ --| Pascal Obry Team-Ada Member --| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE --|------------------------------------------------------ --| http://www.obry.net --| "The best way to travel is by means of imagination" --| --| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595 ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 15:16 ` Pascal Obry @ 2007-10-30 15:22 ` Stefan Bellon 0 siblings, 0 replies; 35+ messages in thread From: Stefan Bellon @ 2007-10-30 15:22 UTC (permalink / raw) On Tue, 30 Oct, Pascal Obry wrote: > Stefan Bellon a écrit : > > While I agree with the given suggestion to allocate large objects on > > the heap instead of the stack, there is a way to increase the stack > > size on Windows. We use something like the following in our projects > > Yes, but this was not the OP question. Sorry, then I misunderstood. -- Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 15:00 ` Stefan Bellon 2007-10-30 15:16 ` Pascal Obry @ 2007-10-31 5:52 ` ME 2007-10-31 9:22 ` Stefan Bellon 1 sibling, 1 reply; 35+ messages in thread From: ME @ 2007-10-31 5:52 UTC (permalink / raw) [-- Warning: decoded text below may be mangled, UTF-8 assumed --] [-- Attachment #1: Type: text/plain, Size: 933 bytes --] "Stefan Bellon" <sbellon@sbellon.de> wrote in message news:20071030160021.19047e4e@cube.tz.axivion.com... On Tue, 30 Oct, Pascal Obry wrote: > ME a �crit : > > I am using the stack. how do I change this at link time using GPL? > > There is no option for that use "new" to allocate the array instead of > declaring it on the stack. While I agree with the given suggestion to allocate large objects on the heap instead of the stack, there is a way to increase the stack size on Windows. We use something like the following in our projects where we need a larger stack on Windows: package Linker is case OS is when "UNIX" => null; when "Windows_NT" => for Default_Switches ("ada") use ("--stack=0x2000000,0x10000"); end case; end Linker; -- Yes, I tried the linker switch -Wl,--stack=0x10000000 in GPL but what is the second number "0x10000" for? Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-31 5:52 ` ME @ 2007-10-31 9:22 ` Stefan Bellon 2007-10-31 13:33 ` ME 0 siblings, 1 reply; 35+ messages in thread From: Stefan Bellon @ 2007-10-31 9:22 UTC (permalink / raw) On Di, 30 Okt, ME wrote: > "Stefan Bellon" <sbellon@sbellon.de> wrote in message > news:20071030160021.19047e4e@cube.tz.axivion.com... > > for Default_Switches ("ada") use > > ("--stack=0x2000000,0x10000"); > Yes, > > I tried the linker switch -Wl,--stack=0x10000000 in GPL > but what is the second number "0x10000" for? The first is the stack reserve and the second is the stack commit size. Specifying the commit size is optional. Default are 2 MB/4 KB respectively, the above values are factor 16 to the default. -- Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-31 9:22 ` Stefan Bellon @ 2007-10-31 13:33 ` ME 2007-10-31 14:36 ` Stefan Bellon 0 siblings, 1 reply; 35+ messages in thread From: ME @ 2007-10-31 13:33 UTC (permalink / raw) I was under the impression ,that GPL would not let you set both stack and commit using the Wl switch? "Stefan Bellon" <sbellon@sbellon.de> wrote in message news:20071031102213.50fe23fc@cube.tz.axivion.com... > On Di, 30 Okt, ME wrote: > >> "Stefan Bellon" <sbellon@sbellon.de> wrote in message >> news:20071030160021.19047e4e@cube.tz.axivion.com... > >> > for Default_Switches ("ada") use >> > ("--stack=0x2000000,0x10000"); > >> Yes, >> >> I tried the linker switch -Wl,--stack=0x10000000 in GPL >> but what is the second number "0x10000" for? > > The first is the stack reserve and the second is the stack commit size. > Specifying the commit size is optional. Default are 2 MB/4 KB > respectively, the above values are factor 16 to the default. > > -- > Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-31 13:33 ` ME @ 2007-10-31 14:36 ` Stefan Bellon 0 siblings, 0 replies; 35+ messages in thread From: Stefan Bellon @ 2007-10-31 14:36 UTC (permalink / raw) On Mi, 31 Okt, ME wrote: > I was under the impression ,that GPL would not let you set both stack > and commit using the Wl switch? That's nothing to do with GNAT GPL vs. GNAT Pro etc. You cannot set the commit size using the -Wl syntax, because of the comma. You either need to use the -Xlinker syntax or a project file if you want to set the commit size as well. This is documented in GNAT User Guide (search for --stack). -- Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 4:00 Largest size array in Gnat 2005 for the PC? ME 2007-10-30 7:08 ` Martin Krischik 2007-10-30 7:28 ` Pascal Obry @ 2007-10-30 17:27 ` anon 2007-10-30 19:06 ` Adam Beneschan 2007-10-31 6:32 ` anon 3 siblings, 1 reply; 35+ messages in thread From: anon @ 2007-10-30 17:27 UTC (permalink / raw) Since your using 32-bit version of XP. then it is linmited to 32 bits. GNAT is ported to over 30 operating systems and CPUs. Here is a subset of a few type and sizes if your CPU and operating system is limited to 32 bits then GNAT defines: System.Memory_Size : constant := ( 2 ** 32 ) ; else using the ia64/Alpha/s390x/86-64 processors and a 64-bits OS then GNAT set the size to: System.Memory_Size : constant := ( 2 ** 64 ) ; 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? > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 17:27 ` anon @ 2007-10-30 19:06 ` Adam Beneschan 0 siblings, 0 replies; 35+ messages in thread From: Adam Beneschan @ 2007-10-30 19:06 UTC (permalink / raw) On Oct 30, 10:27 am, a...@anon.org (anon) wrote: > Since your using 32-bit version of XP. then it is linmited to 32 bits. > > GNAT is ported to over 30 operating systems and CPUs. Here is a > subset of a few type and sizes > > if your CPU and operating system is limited to 32 bits then GNAT > defines: > > System.Memory_Size : constant := ( 2 ** 32 ) ; > > else using the ia64/Alpha/s390x/86-64 processors and a 64-bits > OS then GNAT set the size to: > > System.Memory_Size : constant := ( 2 ** 64 ) ; I should point out that you should *not* use System.Memory_Size for this purpose unless you're using GNAT and are absolutely certain your code will not be compiled with another compiler. The original definition of Memory_Size had to do with the amount of available memory, not the amount of memory that could be accessed with an address (whether the memory existed or not); starting with Ada 95, the AARM has said: It is unspecified whether this refers to the size of the address space, the amount of physical memory on the machine, or perhaps some other interpretation of "memory size." In any case, the value has to be given by a static expression, even though the amount of memory on many modern machines is a dynamic quantity in several ways. Thus, Memory_Size is not very useful. [13.7(33.a)] -- Adam ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-30 4:00 Largest size array in Gnat 2005 for the PC? ME ` (2 preceding siblings ...) 2007-10-30 17:27 ` anon @ 2007-10-31 6:32 ` anon 2007-11-01 4:13 ` ME 3 siblings, 1 reply; 35+ messages in thread From: anon @ 2007-10-31 6:32 UTC (permalink / raw) -- -- 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? > > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-10-31 6:32 ` anon @ 2007-11-01 4:13 ` ME 2007-11-01 8:44 ` Stefan Bellon 0 siblings, 1 reply; 35+ messages in thread From: ME @ 2007-11-01 4:13 UTC (permalink / raw) 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? >> >> > ^ permalink raw reply [flat|nested] 35+ messages in thread
* Re: Largest size array in Gnat 2005 for the PC? 2007-11-01 4:13 ` ME @ 2007-11-01 8:44 ` Stefan Bellon 0 siblings, 0 replies; 35+ messages in thread From: Stefan Bellon @ 2007-11-01 8:44 UTC (permalink / raw) On Mi, 31 Okt, ME wrote: > 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. package Linker is case OS is when "UNIX" => null; when "Windows_NT" => for Linker_Options use ("-Wl,--large-address-aware"); end case; end Linker; -- Stefan Bellon ^ permalink raw reply [flat|nested] 35+ messages in thread
end of thread, other threads:[~2007-11-01 8:44 UTC | newest] Thread overview: 35+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2007-10-30 4:00 Largest size array in Gnat 2005 for the PC? ME 2007-10-30 7:08 ` Martin Krischik 2007-10-30 12:27 ` Florian Weimer 2007-10-30 14:16 ` ME 2007-10-30 14:47 ` Pascal Obry 2007-10-30 18:58 ` Martin Krischik 2007-10-31 5:38 ` ME 2007-10-30 16:07 ` virtual memory, was " tmoran 2007-10-30 19:17 ` Martin Krischik 2007-10-30 20:35 ` Ludovic Brenta 2007-10-31 5:53 ` ME 2007-10-30 7:28 ` Pascal Obry 2007-10-30 9:47 ` Ludovic Brenta 2007-10-30 19:26 ` Georg Bauhaus 2007-10-30 20:17 ` Adam Beneschan 2007-10-30 22:53 ` tmoran 2007-10-30 23:39 ` Georg Bauhaus 2007-10-30 20:24 ` Adam Beneschan 2007-10-30 21:40 ` Georg Bauhaus 2007-10-30 21:48 ` Adam Beneschan 2007-10-30 21:50 ` Georg Bauhaus 2007-10-30 13:50 ` ME 2007-10-30 14:44 ` Pascal Obry 2007-10-30 15:00 ` Stefan Bellon 2007-10-30 15:16 ` Pascal Obry 2007-10-30 15:22 ` Stefan Bellon 2007-10-31 5:52 ` ME 2007-10-31 9:22 ` Stefan Bellon 2007-10-31 13:33 ` ME 2007-10-31 14:36 ` Stefan Bellon 2007-10-30 17:27 ` anon 2007-10-30 19:06 ` Adam Beneschan 2007-10-31 6:32 ` anon 2007-11-01 4:13 ` ME 2007-11-01 8:44 ` Stefan Bellon
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox