Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: Doug Evans <dje@google.com>
To: Tiemen Schut <T.Schut@sron.nl>
Cc: gdb-patches@sourceware.org, joel.sherrill@oarcorp.com
Subject: Re: [patch] sim/erc32/ max simulation time extended by using 64bit  	ints
Date: Fri, 23 Apr 2010 20:28:00 -0000	[thread overview]
Message-ID: <m2ze394668d1004231328h55952dfpdea88e2fd17b4c2d@mail.gmail.com> (raw)
In-Reply-To: <4BD1BBE3020000520000FC62@pluto.sron.nl>

On Fri, Apr 23, 2010 at 6:25 AM, Tiemen Schut <T.Schut@sron.nl> wrote:
> Hey all,
>
> This patch solves the problem that the sparc instruction simulator (SIS) would hang after a few minutes of simulation time (time depending on speed of host pc), because of the use of 32 bit counters internally.
>
> This patch doesn't change anything to simulator behaviour, except that it allows for longer simulation times.
>
> There may be a problem with the use of 64 bit integers, but that was also there before this patch.
>
> Thanks,
>
> Tiemen Schut

Hi.

The patch is ok with me, with a few changes.
I'd leave it a week to see if anyone else has something to say.

1)

-#define	VAL(x)	strtol(x,(char **)NULL,0)
+#define	VAL(x)	strtoull(x,(char **)NULL,0)

I realize VAL is only used once in interf.c but it's also defined in
other files as well.
While one could consolidate them, having the macro at all is probably
less preferable to just calling strtoul{,l} directly.
I would just remove it from interf.c and call strtoull directly.

2)

@@ -338,10 +338,10 @@

 int
 sim_fetch_register(sd, regno, buf, length)
-     SIM_DESC sd;
-    int             regno;
-    unsigned char  *buf;
-     int length;
+    SIM_DESC sd;
+    int regno;
+    unsigned char *buf;
+    int length;
 {
     get_regi(&sregs, regno, buf);
     return -1;
@@ -349,10 +349,10 @@

 int
 sim_write(sd, mem, buf, length)
-     SIM_DESC sd;
-    SIM_ADDR             mem;
+    SIM_DESC sd;
+    SIM_ADDR mem;
     const unsigned char  *buf;
-    int             length;
+    int length;
 {
     return (sis_memory_write(mem, buf, length));
 }

Generally, formatting changes/fixes should be separate.  I noticed a
few, can you remove them?

3)

+#include "stdint.h"

That should be <stdint.h>

4)

-    uint32          ildreg;	/* Destination of last load instruction */
+    uint64          ildreg;	/* Destination of last load instruction */

No point in making this uint64, leave it as uint32.

5)

+	* sis.c, func.c, sis.h, interf.c: Increase max simulation time
+	by using uint64 for relevant counters.

I realize sim/erc32/ChangeLog doesn't always follow the GNU
conventions for ChangeLog entries - it's software obtained from
elsewhere.  It's ok with me to leave as is, but I defer to someone
else with an opinion.

6) I'm assuming this change has been well tested.


  reply	other threads:[~2010-04-23 20:28 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2010-04-23 13:25 Tiemen Schut
2010-04-23 20:28 ` Doug Evans [this message]
2010-05-04 21:16   ` Joel Sherrill
2010-05-07 17:48     ` Doug Evans
2010-05-17  2:08     ` Joel Brobecker
2010-05-17  3:23       ` Joel Sherrill
2010-05-17 16:37       ` Doug Evans
2010-05-17 16:59         ` Joel Brobecker
2010-05-20 23:13       ` Joel Brobecker
2010-05-21 13:47         ` Joel Sherrill
2010-05-21 15:06           ` Joel Brobecker
2010-05-21 15:15             ` Joel Sherrill
2010-05-21 17:13               ` Doug Evans

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=m2ze394668d1004231328h55952dfpdea88e2fd17b4c2d@mail.gmail.com \
    --to=dje@google.com \
    --cc=T.Schut@sron.nl \
    --cc=gdb-patches@sourceware.org \
    --cc=joel.sherrill@oarcorp.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox