Re: ARM sim patch: increase default target memory

Re: ARM sim patch: increase default target memory

[Anthony Green]

Andrew wrote:
> Is there a command line option that you can specify?

xscale-elf-run has one (-m), but it doesn't appear to work from within GDB 
(like, "target sim -m 8000000").

AG

Re: ARM sim patch: increase default target memory

[Andrew Cagney]

> Andrew wrote:
> 
>> Is there a command line option that you can specify?
> 
> 
> xscale-elf-run has one (-m), but it doesn't appear to work from within GDB 
> (like, "target sim -m 8000000").
> 
> AG

It should :-(  Can I suggest a patch to sim_open() that parses -m and 
calls sim_size().  (It should use a generic parser though :-( ).

Andrew

ARM sim patch: increase default target memory

[Anthony Green]

This patch increases the default target memory for the ARM sim from 2
to 8MB.  2MB isn't quite enough for the gcj testsuite.  8MB appears
to be more than enough.  We can get through the xscale-elf-gcj testsuite
quite easily with this change.

Ok?



2002-03-17  Anthony Green  <green@redhat.com>

	* wrapper.c (mem_size): Increase the default target memory to 8MB.

Index: sim/arm/wrapper.c
===================================================================
RCS file: /cvs/src/src/sim/arm/wrapper.c,v
retrieving revision 1.17
diff -u -p -r1.17 wrapper.c
--- wrapper.c	2002/02/05 11:22:26	1.17
+++ wrapper.c	2002/03/17 16:40:34
@@ -47,7 +47,7 @@ static SIM_OPEN_KIND sim_kind;
 static char *myname;
 
 /* Memory size in bytes.  */
-static int mem_size = (1 << 21);
+static int mem_size = (1 << 23);
 
 /* Non-zero to display start up banner, and maybe other things.  */
 static int verbosity;

Re: ARM sim patch: increase default target memory

[Andrew Cagney]

> This patch increases the default target memory for the ARM sim from 2
> to 8MB.  2MB isn't quite enough for the gcj testsuite.  8MB appears
> to be more than enough.  We can get through the xscale-elf-gcj testsuite
> quite easily with this change.
> 
> Ok?
> 
> 
> 
> 2002-03-17  Anthony Green  <green@redhat.com>
> 
> * wrapper.c (mem_size): Increase the default target memory to 8MB.
> 

Is there a command line option that you can specify?

Andrew

Re: ARM sim patch: increase default target memory

[Anthony Green]

On Sun, 2002-03-17 at 09:55, Nick Clifton wrote:
> > 2002-03-17  Anthony Green  <green@redhat.com>
> > 
> > 	* wrapper.c (mem_size): Increase the default target memory to 8MB.
> 
> This is fine - Approved.

Thanks Nick.  I checked this in.

BTW - gdb people - I see there is a 5.2 branch.  I assume there may be
some affinity between GCC 3.1 and GDB 5.2.  Would it be OK to move my
patch to the 5.2 branch?

Thanks,

AG

Re: ARM sim patch: increase default target memory

[Andrew Cagney]

> On Sun, 2002-03-17 at 09:55, Nick Clifton wrote:
> 
>> > 2002-03-17  Anthony Green  <green@redhat.com>
>> > 
>> > * wrapper.c (mem_size): Increase the default target memory to 8MB.
> 
>> 
>> This is fine - Approved.

Er, wasn't this going to be properly - add -m to sim_open()?

Andrew


> Thanks Nick.  I checked this in.
> 
> BTW - gdb people - I see there is a 5.2 branch.  I assume there may be
> some affinity between GCC 3.1 and GDB 5.2.  Would it be OK to move my
> patch to the 5.2 branch?
> 
> Thanks,
> 
> AG
> 
> 
> 
> 

Re: ARM sim patch: increase default target memory

[Anthony Green]

On Mon, 2002-03-18 at 17:30, Andrew Cagney wrote:
> Er, wasn't this going to be properly - add -m to sim_open()?

You're implying that the default value must remain 2MB.  Isn't this a
somewhat arbitrary value?

I filed a case against the command line bug.  This seems like a
completely different issue.

AG

Re: ARM sim patch: increase default target memory

[Andrew Cagney]

> On Mon, 2002-03-18 at 17:30, Andrew Cagney wrote:
> 
>> Er, wasn't this going to be properly - add -m to sim_open()?
> 
> 
> You're implying that the default value must remain 2MB.  Isn't this a
> somewhat arbitrary value?

The number is a compromise between a fast simulator startup, sufficient 
memory for a typical simulation and unnecessary VM grab.  It was also 
found to be sufficient for the basic GDB and GCC tests.

 From memory, he Java tests run on the MIPS (and PPC?) simulators and 
yet there haven't been problems.  The MIPS defaults to 2mb, the PPC 1mb.

> I filed a case against the command line bug.  This seems like a
> completely different issue.

I don't think that re-compiling GDB is the correct way for a user to 
change the size of simulator memory.  Instead the user should be able to 
fix it at run time.  I think that is the real bug here.

enjoy,
Andrew

Re: ARM sim patch: increase default target memory

[Anthony Green]

On Tue, 2002-03-19 at 07:46, Andrew Cagney wrote:
> The number is a compromise between a fast simulator startup, sufficient 
> memory for a typical simulation and unnecessary VM grab.  It was also 
> found to be sufficient for the basic GDB and GCC tests.

Unfortunately this isn't true anymore.  gcj is part of GCC and 2MB is
not enough space.

>  From memory, he Java tests run on the MIPS (and PPC?) simulators and 
> yet there haven't been problems.  The MIPS defaults to 2mb, the PPC 1mb.

(just MIPS)  The default runtime requirements have grown since the early
days.  8MB appears to be a very comfortable amount of space, although
with some experimentation this could probably be brought down.

> I don't think that re-compiling GDB is the correct way for a user to 
> change the size of simulator memory.  Instead the user should be able to 
> fix it at run time.  I think that is the real bug here.

Yes, I agree that this is a bug, which is why I filed a case against it.

AG

Re: ARM sim patch: increase default target memory

[Andrew Cagney]

> On Tue, 2002-03-19 at 07:46, Andrew Cagney wrote:
> 
>> The number is a compromise between a fast simulator startup, sufficient 
>> memory for a typical simulation and unnecessary VM grab.  It was also 
>> found to be sufficient for the basic GDB and GCC tests.
> 
> 
> Unfortunately this isn't true anymore.  gcj is part of GCC and 2MB is
> not enough space.

As I said a compromise for the ``basic'' gcc tests.  I recall this value 
being put up once before and people complaining that the basic tests 
slowed down and GDB grabbed too much memory.

>> From memory, he Java tests run on the MIPS (and PPC?) simulators and 
>> yet there haven't been problems.  The MIPS defaults to 2mb, the PPC 1mb.
> 
> 
> (just MIPS)  The default runtime requirements have grown since the early
> days.  8MB appears to be a very comfortable amount of space, although
> with some experimentation this could probably be brought down.
> 
> 
>> I don't think that re-compiling GDB is the correct way for a user to 
>> change the size of simulator memory.  Instead the user should be able to 
>> fix it at run time.  I think that is the real bug here.
> 
> 
> Yes, I agree that this is a bug, which is why I filed a case against it.

We're going to degenerate into semantics :-)

Arm can't change its memory size at run time.  This is the bug that hurt 
you - you had to change a compile time constant to fix your problem and 
that simply shouldn't have been necessary.  Remember, the other 
simulators don't have this problem as -m<blah> can be used.

As a separate issue, it is probably time to review the default memory 
size for all the simulators.  Should they all be increased (to again be 
consistent)?  Should the GDB builder be allowed to 
--enable-sim-memory-size=BLAH this?

Andrew

Re: ARM sim patch: increase default target memory

[Andrew Cagney]

> On Tue, 2002-03-19 at 07:46, Andrew Cagney wrote:
> 
> The number is a compromise between a fast simulator startup, sufficient memory for a typical simulation and unnecessary VM grab.  It was also found to be sufficient for the basic GDB and GCC tests.
> 
> 
> Unfortunately this isn't true anymore.  gcj is part of GCC and 2MB is
> not enough space.
> 
> As I said a compromise for the ``basic'' gcc tests.  I recall this value being put up once before and people complaining that the basic tests slowed down and GDB grabbed too much memory.

Hmm, perhaphs a better way of looking at this is to ask where the line 
should be drawn.

C? Fortran? C++? Java? Ada?

I dread the thought of hardwireing this to 32 mb (:-^) just so that 
standalone C++ or Ada programs can be run without the -m flag.

I suspect C might be a good compromise :-)

enjoy,
Andrew