Largest size array in Gnat 2005 for the PC?

Largest size array in Gnat 2005 for the PC?

[ME]

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? 

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

[Martin Krischik]

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

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

[Florian Weimer]

* 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?

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

[ME]

"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 

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

[Pascal Obry]

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

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

[Martin Krischik]

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

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

[ME]

"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 

virtual memory, was Re: Largest size array in Gnat 2005 for the PC?

[tmoran]

>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.

Re: virtual memory, was Re: Largest size array in Gnat 2005 for the PC?

[Martin Krischik]

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

Re: virtual memory, was Re: Largest size array in Gnat 2005 for the PC?

[Ludovic Brenta]

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.

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

[ME]

"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 

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

[Pascal Obry]

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

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

[Ludovic Brenta]

[-- 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.

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

[Georg Bauhaus]

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;

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

[Adam Beneschan]

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;

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

[tmoran]

> 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?

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

[Georg Bauhaus]

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).

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

[Adam Beneschan]

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;

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

[Georg Bauhaus]

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

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

[Adam Beneschan]

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

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

[Georg Bauhaus]

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.

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

[ME]

[-- 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 

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

[Pascal Obry]

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

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

[Stefan Bellon]

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

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

[Pascal Obry]

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

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

[Stefan Bellon]

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

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

[ME]

[-- 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 

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

[Stefan Bellon]

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

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

[ME]

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 

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

[Stefan Bellon]

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

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

[anon]

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? 
>
>

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

[Adam Beneschan]

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

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

[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? 
>
>

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

[ME]

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?
>>
>>
> 

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

[Stefan Bellon]

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