Mirror of the gdb-patches mailing list
 help / color / mirror / Atom feed
From: cgd@broadcom.com
To: rsandifo@redhat.com
Cc: gdb-patches@sources.redhat.com
Subject: Re: [rfa/mips] Second go at vr5500 hilo hazard fix
Date: Thu, 18 Mar 2004 17:57:00 -0000	[thread overview]
Message-ID: <yov5wu5ivy1n.fsf@ldt-sj3-010.sj.broadcom.com> (raw)
Message-ID: <20040318175700.pMoBQ3Laa53hurq_gzkdK07PVJswqLSwV4a18IXMWwg@z> (raw)
In-Reply-To: <mailpost.1079622402.27828@news-sj1-1>

[-- Attachment #1: Type: text/plain, Size: 2265 bytes --]

At Thu, 18 Mar 2004 15:06:42 +0000 (UTC), "Richard Sandiford" wrote:
> Various suggestions were made about how this could be handled, but I
> think Andrew's position remained the same: we shouldn't try to treat the
> vr5500 ISA as "MIPS IV plus a bit and minus a bit" (my words, not his).
> He reckoned every vr5500 instruction should be marked as such.

My reading is, unfortunately, is that it is a *correct* implementation
of the MIPS ISA.

At least according to the "Historical information" in the MIPS64 AFP
Volume II (Basic Instruction Set) -- I'm looking at revisions around
1.0 here -- the 3-cycle hi/lo hazards should only have been a problem
for MIPS I-III.

I.e., MIPS IV processors which *have* these hi/lo hazards are the
things broken... but as you note at least according to the 5400 docs,
it is MIPS IV and does have the hazard.


(I thought Andrew's biggest objection was stuffing bfd_* values into
mips.igen, but I may be wrong on that.  It's been a while.)


> The patch below does this.  Tested on mips64vrel-elf.  OK to install?

Doing this doesn't seem satisfactory to me.  It would open the door to
a very similar modification, for another handful of processors, which
would be really quite out of hand IMO.


Now that the mips sim 'multi' bits are in place (including good
default), and we have MIPS_MACH(SD) (thanks! 8-), it should be
possible to code a simple macro which checks for the appropriate bfd
machine, and decides whether interlocks are present.

I'd rather see an implementation that acts somewhat like the (rough,
uncompiled, not sanity-checked) patch below.  Additional advice: make
sure the comment describing the new macros mentions the fact that they
should have cases only for certain ISAs' processors (mipsIV, mipsV).

The names were just a suggestion.  there are probably better, shorter
ones, and I didn't try to reconcile them with any other code (e.g. the
code in headers where they might be defined 8-).


This type of change has the "right" properties, IMO:

        * boils down to a no-op if not multi.

        * doesn't impact ISAs with no hazard ambiguity if multi.

        * shouldn't cause maint pain long term if everybody decides to
          make the code right for their fave MIPS IV arch.  8-)



cgd


[-- Attachment #2: rough_haz.diff --]
[-- Type: text/x-patch, Size: 2977 bytes --]

Index: mips.igen
===================================================================
RCS file: /cvs/src/src/sim/mips/mips.igen,v
retrieving revision 1.55
diff -u -p -r1.55 mips.igen
--- mips.igen	20 Jan 2004 07:06:14 -0000	1.55
+++ mips.igen	18 Mar 2004 17:54:49 -0000
@@ -242,10 +242,15 @@
 // enforced restrictions (2) and (3) for more ISAs and CPU types than
 // necessary.  Unfortunately, at least some MIPS IV and later parts'
 // documentation describes them as having these hazards (e.g. vr5000),
-// so they can't be removed for at leats MIPS IV.  MIPS V hasn't been
-// checked (since there are no known hardware implementations).
-// 
+// so they can't be removed for at leats MIPS IV.  (As of MIPS32 and MIPS64,
+// the hazards are definitely architected to not be required.)
+//
+// To accomodate implementations of particular ISAs which don't have the
+// hazards, for some ISAs we have a version of these helper functions which
+// calls a function to determine if the particular architecture has
+// a hazard.
 
+// 
 // check_mf_cycles:
 //
 // Helper used by check_mt_hilo, check_mult_hilo, and check_div_hilo
@@ -274,8 +279,6 @@
 *mipsI:
 *mipsII:
 *mipsIII:
-*mipsIV:
-*mipsV:
 *vr4100:
 *vr5000:
 {
@@ -287,6 +290,18 @@
 }
 
 :function:::int:check_mt_hilo:hilo_history *history
+*mipsIV:
+*mipsV:
+{
+  signed64 time = sim_events_time (SD);
+  int ok = (MIPS_ARCH_HAS_MT_HILO_HAZARD (SD_)
+	    || check_mf_cycles (SD_, history, time, "MT"));
+  history->mt.timestamp = time;
+  history->mt.cia = CIA;
+  return ok;
+}
+
+:function:::int:check_mt_hilo:hilo_history *history
 *mips32:
 *mips64:
 *r3900:
@@ -350,8 +365,6 @@
 *mipsI:
 *mipsII:
 *mipsIII:
-*mipsIV:
-*mipsV:
 *vr4100:
 *vr5000:
 {
@@ -366,6 +379,21 @@
 }
 
 :function:::int:check_mult_hilo:hilo_history *hi, hilo_history *lo
+*mipsIV:
+*mipsV:
+{
+  signed64 time = sim_events_time (SD);
+  int ok = (! MIPS_ARCH_HAS_MULT_HILO_HAZARD (SD_)
+	    || (check_mf_cycles (SD_, hi, time, "OP")
+	        && check_mf_cycles (SD_, lo, time, "OP")));
+  hi->op.timestamp = time;
+  lo->op.timestamp = time;
+  hi->op.cia = CIA;
+  lo->op.cia = CIA;
+  return ok;
+}
+
+:function:::int:check_mult_hilo:hilo_history *hi, hilo_history *lo
 *mips32:
 *mips64:
 *r3900:
@@ -389,8 +417,6 @@
 *mipsI:
 *mipsII:
 *mipsIII:
-*mipsIV:
-*mipsV:
 *vr4100:
 *vr5000:
 *r3900:
@@ -398,6 +424,21 @@
   signed64 time = sim_events_time (SD);
   int ok = (check_mf_cycles (SD_, hi, time, "OP")
 	    && check_mf_cycles (SD_, lo, time, "OP"));
+  hi->op.timestamp = time;
+  lo->op.timestamp = time;
+  hi->op.cia = CIA;
+  lo->op.cia = CIA;
+  return ok;
+}
+
+:function:::int:check_div_hilo:hilo_history *hi, hilo_history *lo
+*mipsIV:
+*mipsV:
+{
+  signed64 time = sim_events_time (SD);
+  int ok = (! MIPS_ARCH_HAS_DIV_HILO_HAZARD (SD_)
+	    || (check_mf_cycles (SD_, hi, time, "OP")
+	        && check_mf_cycles (SD_, lo, time, "OP")));
   hi->op.timestamp = time;
   lo->op.timestamp = time;
   hi->op.cia = CIA;

  parent reply	other threads:[~2004-03-18 17:57 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2004-03-18 15:05 Richard Sandiford
     [not found] ` <mailpost.1079622402.27828@news-sj1-1>
2004-03-19  0:09   ` cgd [this message]
2004-03-18 17:57     ` cgd
2004-03-18 20:55     ` Richard Sandiford
2004-03-19  0:09       ` Richard Sandiford
2004-03-19 15:19       ` Andrew Cagney
2004-03-24  7:59         ` Richard Sandiford
2004-03-24 15:59           ` cgd
2004-03-25  7:15       ` cgd
2004-03-25  7:45         ` Richard Sandiford
     [not found]           ` <mailpost.1080200738.13330@news-sj1-1>
2004-03-25 18:53             ` cgd
2004-03-25 22:14         ` Andrew Cagney
2004-03-26  0:01           ` cgd
2004-03-26  0:28             ` Andrew Cagney
     [not found]               ` <mailpost.1080260907.10999@news-sj1-1>
2004-03-26  2:19                 ` cgd
2004-03-28 10:16     ` Richard Sandiford
     [not found]       ` <mailpost.1080469040.8967@news-sj1-1>
2004-03-29 19:38         ` cgd
2004-04-10  6:59         ` cgd
2004-03-19  0:09 ` Richard Sandiford

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=yov5wu5ivy1n.fsf@ldt-sj3-010.sj.broadcom.com \
    --to=cgd@broadcom.com \
    --cc=gdb-patches@sources.redhat.com \
    --cc=rsandifo@redhat.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