This is the mail archive of the binutils@sources.redhat.com mailing list for the binutils project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: ssnop for mips


> From: "Kevin D. Kissell" <kevink@mips.com>
> To: <cgd@sibyte.com>, "Ralf Baechle" <ralf@uni-koblenz.de>
> Cc: <mrs@windriver.com>, <binutils@sources.redhat.com>
> Date: Fri, 20 Jul 2001 18:24:00 +0200

> But while it may be true that SSNOP is not guaranteed to force
> single issue across all MIPS implementations, it is still the best
> known method of forcing single issue, and should be used in
> preference to a simple "nop" for negotiating pipeline hazards, even
> on pre-MIPS32 CPU's, in my opinion.  If the RM7000 needs more SSNOPS
> than it should because it can issue them two at a time, that's
> philosophically indistinguishable from it respecting SSNOP, but
> having longer pipeline hazards.

I think this sums up why our people would like it.  It is the best
known form to ask for nops.  It will work on all parts, universally,
and the only gotcha is that the exact number needed will be chip
specific, but since it started out chip specific, this is exactly no
worse that when we started.

The reason why someone would use it, is because they want to get
around CP0 hazards.  The only code that does this type of thing, is
kernel code, we aren't talking dumb people here.  They know what they
are doing, and since they can read an errata sheet and bring a kernel
up, they won't be tripped up by the number of nops needed.

I think we have heard from all sides concerned.  I'm not a gas person,
nor a mips person, nor a CP0 hazard person, so I'd like to request
that the `alpha' mips gas person (who are you?) step forward and
decide this issue.  I think it is complex enough and the shades of
gray certainly have me confused over the best possible decision.

When exactly should ssnop be valid?


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]