ssnop for mips

ssnop for mips

[mike stump]

Can I check this into the release branch as well as mainline?

2001-07-18  Mike Stump  <mrs@wrs.com>

	* mips-opc.c (ssnop): While the documentation makes it seem
	like this instruction is new for MIPS32, it is not, it is needed
	on all ISA levels.

Doing diffs in mips-opc.c.~1~:
*** mips-opc.c.~1~	Fri Jun 22 07:03:52 2001
--- mips-opc.c	Wed Jul 18 15:57:01 2001
*************** const struct mips_opcode mips_builtin_op
*** 116,122 ****
  /* name,    args,	match,	    mask,	pinfo,          	membership */
  {"pref",    "k,o(b)",   0xcc000000, 0xfc000000, RD_b,           	I32|G3	},
  {"nop",     "",         0x00000000, 0xffffffff, 0,              	I1      },
! {"ssnop",   "",         0x00000040, 0xffffffff, 0,              	I32	},
  {"li",      "t,j",      0x24000000, 0xffe00000, WR_t,			I1	}, /* addiu */
  {"li",	    "t,i",	0x34000000, 0xffe00000, WR_t,			I1	}, /* ori */
  {"li",      "t,I",	0,    (int) M_LI,	INSN_MACRO,		I1	},
--- 116,122 ----
  /* name,    args,	match,	    mask,	pinfo,          	membership */
  {"pref",    "k,o(b)",   0xcc000000, 0xfc000000, RD_b,           	I32|G3	},
  {"nop",     "",         0x00000000, 0xffffffff, 0,              	I1      },
! {"ssnop",   "",         0x00000040, 0xffffffff, 0,              	I1	},
  {"li",      "t,j",      0x24000000, 0xffe00000, WR_t,			I1	}, /* addiu */
  {"li",	    "t,i",	0x34000000, 0xffe00000, WR_t,			I1	}, /* ori */
  {"li",      "t,I",	0,    (int) M_LI,	INSN_MACRO,		I1	},
--------------

Re: ssnop for mips

[Eric Christopher]

On 18 Jul 2001 16:02:18 -0700, mike stump wrote:
> Can I check this into the release branch as well as mainline?
> 

Sure.  I hadn't seen it in any MIPS 1 doc, but I'll take your word on
it.  :)

-eric

-- 
I will not grease the monkey bars

Re: ssnop for mips

[cgd]

mrs@windriver.com ("mike stump") writes:
> 2001-07-18  Mike Stump  <mrs@wrs.com>
> 
> 	* mips-opc.c (ssnop): While the documentation makes it seem
> 	like this instruction is new for MIPS32, it is not, it is needed
> 	on all ISA levels.

for some value of 'needed'.  it may have some absolutely different
'no-op' meaning on non-MIPS32/MIPS64 processors.

if i recall correctly, that instruction doesn't inhibit multi-issue.


Personally, I don't think it should be enabled if not MIPS32/MIPS64:

* the behaviour may not be what's expected, and

* if you need to use it, you can quite easily do:

	.set push
	.set mips32
	... whatever ...
	ssnop
	... whatever ...
	.set pop


"not my decision," though, and it sounds like you've already got your
approval.


cgd

Re: ssnop for mips

[cgd]

cgd@sibyte.com (Chris G. Demetriou) writes:
> for some value of 'needed'.  it may have some absolutely different
> 'no-op' meaning on non-MIPS32/MIPS64 processors.
> 
> if i recall correctly, that instruction doesn't inhibit multi-issue.

i edited a couple of words out accidentally.

"on the RM7000."  From the looks of it, it has two pipes both of which
can handle "sll $0, $0, 1" at the same time.


so, to reiterate: 'ssnop' (sll $0, $0, 1) does not (as far as I know)
generally inhibit multi-issue, and, specifically (as far as I can
tell) does not inhibit it on the rm7000.

The behavior, and that name, are unique to MIPS32 and MIPS64 (and
chips which implement that specific instruction), but definitely _do
not_ go back to MIPS I or even MIPS IV AFAIK.

It makes no more sense to include it in MIPS I - MIPS IV (and possibly
V -- i dunno) than it does to include, oh, pref or something in MIPS
I.


I also said:

> * if you need to use it, you can quite easily do:
> 
> 	.set push
> 	.set mips32
> 	... whatever ...
> 	ssnop
> 	... whatever ...
> 	.set pop

That covers the assembly case.


The disassembly case is obvious: if you want to dissassemble MIPS32 /
MIPS64 instructions in a binary that's not marked MIPS32 or MIPS64,
then you should do so with a -m flag or similar.

you don't disassemble random non-conflicting instructions for MIPS I,
just because they're non-conflicting, eh?



cgd

Re: ssnop for mips

[Eric Christopher]

> 
> "not my decision," though, and it sounds like you've already got your
> approval.
> 

You can argue it though :)

So, Mike, if it isn't an explicit part of the instruction set we
probably shouldn't include it.  I know of some non-mips32 chips that
include the instruction, but no MIPS I.

-eric

-- 
I will not grease the monkey bars

Re: ssnop for mips

[Andrew Cagney]

> It makes no more sense to include it in MIPS I - MIPS IV (and possibly
> V -- i dunno) than it does to include, oh, pref or something in MIPS
> I.


For what its worth, I agree with this.  If you disssassemble MIPS 1 
instructions and you see ``ssnop'' you're going to wonder the what the 
.... is this?

	Andrew

Re: ssnop for mips

[Eric Christopher]

On 19 Jul 2001 10:41:30 -0400, Andrew Cagney wrote:
> > It makes no more sense to include it in MIPS I - MIPS IV (and possibly
> > V -- i dunno) than it does to include, oh, pref or something in MIPS
> > I.
> 
> 
> For what its worth, I agree with this.  If you disssassemble MIPS 1 
> instructions and you see ``ssnop'' you're going to wonder the what the 
> .... is this?
> 

Worth quite a bit actually.  I thought (esp since I don't have a manual
with me) that ssnop was in there and just omitted at one point.  I know
that it exists on some MIPSIV processors.  We could add it in there...

-eric

-- 
I will not grease the monkey bars

Re: ssnop for mips

[Thiemo Seufer]

Eric Christopher wrote:
[snip]
> > For what its worth, I agree with this.  If you disssassemble MIPS 1 
> > instructions and you see ``ssnop'' you're going to wonder the what the 
> > .... is this?
> > 
> 
> Worth quite a bit actually.  I thought (esp since I don't have a manual
> with me) that ssnop was in there and just omitted at one point.  I know
> that it exists on some MIPSIV processors.

The R10000 has not (at least it's not documented), and ssnop is not
part of MIPS IV, so the special guarantees of ssnop are not valid
here.

> We could add it in there...

I think it should be restricted to MIPS32/MIPS64/the processor which
defines ssnop explicitly.


Thiemo

Re: ssnop for mips

[Eric Christopher]

> 
> I think it should be restricted to MIPS32/MIPS64/the processor which
> defines ssnop explicitly.
> 

Yes.  I agree.  I thought that Mike had an explicit definition on the
ISA that I hadn't seen.

-eric


-- 
I will not grease the monkey bars

Re: ssnop for mips

[Ralf Baechle]

On Wed, Jul 18, 2001 at 04:02:18PM -0700, mike stump wrote:

> Can I check this into the release branch as well as mainline?
> 
> 2001-07-18  Mike Stump  <mrs@wrs.com>
> 
> 	* mips-opc.c (ssnop): While the documentation makes it seem
> 	like this instruction is new for MIPS32, it is not, it is needed
> 	on all ISA levels.

While not explicitly documented in the manuals ssnop was available in R8000
and beyond, so preceeds MIPS32 by almost half a decade.  I have no idea
why but ssnop is definately part of MIPS IV though not documented.  As
such adding ssnop as a MIPS32 instruction is somewhat incorrect.

  Ralf

Re: ssnop for mips

[Ralf Baechle]

On Wed, Jul 18, 2001 at 08:16:00PM -0700, cgd@sibyte.com wrote:

> mrs@windriver.com ("mike stump") writes:
> > 2001-07-18  Mike Stump  <mrs@wrs.com>
> > 
> > 	* mips-opc.c (ssnop): While the documentation makes it seem
> > 	like this instruction is new for MIPS32, it is not, it is needed
> > 	on all ISA levels.
> 
> for some value of 'needed'.  it may have some absolutely different
> 'no-op' meaning on non-MIPS32/MIPS64 processors.
> 
> if i recall correctly, that instruction doesn't inhibit multi-issue.

Ssnop is documented as ``breaks superscalar dispatch''.  See also the
comments in IRIX <sys/asm.h> which I can't paste here for (C) reasons.

> Personally, I don't think it should be enabled if not MIPS32/MIPS64:
> 
> * the behaviour may not be what's expected, and

All CPUs that don't implement ssnop's special semantics will decode it as
sll $zero, $zero, 1 which is obviously harmless.

  Ralf

Re: ssnop for mips

[Ralf Baechle]

On Wed, Jul 18, 2001 at 10:42:06PM -0700, cgd@sibyte.com wrote:

> The behavior, and that name, are unique to MIPS32 and MIPS64 (and
> chips which implement that specific instruction), but definitely _do
> not_ go back to MIPS I or even MIPS IV AFAIK.

Correct for MIPS I, II and III but wrong as for MIPS IV - R8000 has ssnop.

> The disassembly case is obvious: if you want to dissassemble MIPS32 /
> MIPS64 instructions in a binary that's not marked MIPS32 or MIPS64,
> then you should do so with a -m flag or similar.
> 
> you don't disassemble random non-conflicting instructions for MIPS I,
> just because they're non-conflicting, eh?

I would like to see -m disassemble-the-damn-thing as the default.  Much of
the code I produce is supposed to work beyond the barriers of a certain ISA
and at times there is no single -m options that makes objdump disassemble
everything.  Similarly objdump's behaviour of only disassembling stuff
that has explicitly been marked as code using .type; I did very much
prefer the old behaviour of disassembling everything in sections that are
marked to contain code.

  Ralf

Re: ssnop for mips

[Eric Christopher]

> While not explicitly documented in the manuals ssnop was available in R8000
> and beyond, so preceeds MIPS32 by almost half a decade.  I have no idea
> why but ssnop is definately part of MIPS IV though not documented.  As
> such adding ssnop as a MIPS32 instruction is somewhat incorrect.
> 

No, it just needs to be added to the MIPS IV isa as well.  I just need a
set of docs that shows it in MIPS IV.  As I said, I know it is in a few
possible MIPS IV variants, but to put it in as a straight MIPS IV I'll
need to see it.

I'd also like to throw some architecture ISAs in a documentation
repository much like the one in gcc.  Or we can throw the applicable
ones in the gcc documentation repository.

-eric

-- 
I will not grease the monkey bars

Re: ssnop for mips

[cgd]

"Ralf Baechle" <ralf@uni-koblenz.de> writes:
> > > 	* mips-opc.c (ssnop): While the documentation makes it seem
> > > 	like this instruction is new for MIPS32, it is not, it is needed
> > > 	on all ISA levels.
> > 
> > for some value of 'needed'.  it may have some absolutely different
> > 'no-op' meaning on non-MIPS32/MIPS64 processors.
> > 
> > if i recall correctly, that instruction doesn't inhibit multi-issue.
> 
> Ssnop is documented as ``breaks superscalar dispatch''.  See also the
> comments in IRIX <sys/asm.h> which I can't paste here for (C) reasons.

As noted, i forgot some words there.  specifically, "on the rm7k"
though there may well be certain other processors on which it doesn't
force single-issue as well.

(looks like on some of the IDT parts you can still co-issue FP
instructions.)


> > Personally, I don't think it should be enabled if not MIPS32/MIPS64:
> > 
> > * the behaviour may not be what's expected, and
> 
> All CPUs that don't implement ssnop's special semantics will decode it as
> sll $zero, $zero, 1 which is obviously harmless.

Right, but looked at the other way, it's not.

you see ssnop in the assembly code, and you think "ahh, one per
cycle."

but in fact that's not the case for a bunch of parts.



chris

Re: ssnop for mips

[Kevin D. Kissell]

> > Ssnop is documented as ``breaks superscalar dispatch''.  See also the
> > comments in IRIX <sys/asm.h> which I can't paste here for (C) reasons.
>
> As noted, i forgot some words there.  specifically, "on the rm7k"
> though there may well be certain other processors on which it doesn't
> force single-issue as well.

Bummer.  They should have known better.  I'm quite surprised.

> (looks like on some of the IDT parts you can still co-issue FP
> instructions.)

That's unfortunate, but probably not too dangerous.  The
main reason to want to assure single-issue is when one
is navigating CP0 hazards, and FP instructions are
generally not an issue (pun not intended).

> > > Personally, I don't think it should be enabled if not MIPS32/MIPS64:
> > >
> > > * the behaviour may not be what's expected, and
> >
> > All CPUs that don't implement ssnop's special semantics will decode it
as
> > sll $zero, $zero, 1 which is obviously harmless.
>
> Right, but looked at the other way, it's not.
>
> you see ssnop in the assembly code, and you think "ahh, one per
> cycle."
>
> but in fact that's not the case for a bunch of parts.

Historically, SSNOP was invented for the old R8000 BiCMOS
monster, which was the first superscalar MIPS CPU.  The R10K
preserved the convention, as I believe does the R54xx (though
I also believed it true of the RM7000), but until the MIPS32 and
MIPS64 specs were published, that's all it was, a convention.
It was not part of the MIPS-I/II/III/IV ISA compliance tests.

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.

            Regards,

            Kevin K.

Re: ssnop for mips

[cgd]

"Ralf Baechle" <ralf@uni-koblenz.de> writes:
> On Wed, Jul 18, 2001 at 10:42:06PM -0700, cgd@sibyte.com wrote:
> > The behavior, and that name, are unique to MIPS32 and MIPS64 (and
> > chips which implement that specific instruction), but definitely _do
> > not_ go back to MIPS I or even MIPS IV AFAIK.
> 
> Correct for MIPS I, II and III but wrong as for MIPS IV - R8000 has ssnop.

Interesting.  (Are there any on-line docs for r8k?  I took a quick
look around, and saw nothing.  I like collecting docs.)

Since r8k is the 'canonical' cpu for MIPS IV in binutils, maybe it's
appropriate to make MIPS IV disassemble ssnop as ssnop...  But there
are a bunch of chips which claim to implement MIPS IV which, as far as
I can tell, don't do SSNOP.  (An example is, from what I can tell from
the documentation, the rm7k.)

On the other hand, MIPS themeselves claim that it's "new" in MIPS32
(but that doesn't mean that there was no prior art -- only that it was
a newly standardized part of the ISA as of MIPS32), but even worse I
find no mention of special behaviour of "sll $0, $0, 1" in the MIPS IV
ISA documentation available from e.g.:

http://techpubs.sgi.com/library/manuals/2000/007-2597-001/pdf/007-2597-001.pdf

(On the other hand, it kept mentioning "NOP" and "actual NOP" without
explicitly defining that NOP _is_ "sll $0, $0, 0" so it seems fairly
obvious that that document is not complete.  8-)

I'll admit that I didn't search that manual as thoroughly as one
might.  If you have a pointer to some specific documentation that
indicates that in general "MIPS IV has ssnop" I'm quite willing to
look at it.


> I would like to see -m disassemble-the-damn-thing as the default.  Much of
> the code I produce is supposed to work beyond the barriers of a certain ISA
> and at times there is no single -m options that makes objdump disassemble
> everything.

So, personally I'd like to see some kind of use of debugging
information to mark code as being for a particular CPU or ISA (as
appropriate), where that debugging information is in a form that's
easily usable by e.g. objdump and which is 'somewhat standard.'

I also would like to see the MIPS ELF object format definition (if not
the rest of the MIPS SvsV ABI bits -- I don't care about that stuff)
updated to match present reality, at least in terms of stuff like
flags, ISAs, architectures, etc.

That's just my own little pipe dream, though.  8-) 


I think it probably does make sense to have an option which basically
says "try to decode all instructions into _something_, even though I
acknowledge that that 'something' may be wrong or irrelevant."

I don't think it should be the default though.  (Because, really, as
far as i'm concerned, unless asked to do otherwise, you have to do
your best to provide correct data.  And, as a starting point for
operation, you have to assume that the markings on the binaries are
both correct and relevant.)




cgd

Re: ssnop for mips

[cgd]

"Kevin D. Kissell" <kevink@mips.com> writes:
> > As noted, i forgot some words there.  specifically, "on the rm7k"
> > though there may well be certain other processors on which it doesn't
> > force single-issue as well.
> 
> Bummer.  They should have known better.  I'm quite surprised.

I could be incorrect.

I've never used an rm7k, and my knowledge is based only on perusal of
their manuals.  I didn't see documentation of that feature.



cgd

Re: ssnop for mips

[Maciej W. Rozycki]

On Fri, 20 Jul 2001, Ralf Baechle wrote:

> I would like to see -m disassemble-the-damn-thing as the default.  Much of
> the code I produce is supposed to work beyond the barriers of a certain ISA
> and at times there is no single -m options that makes objdump disassemble
> everything.  Similarly objdump's behaviour of only disassembling stuff

 Supposedly this can be fixed by adding something like "mips:generic" that
covers everything.  Selecting the default behaviour at the compile time
can be difficult, though.  We don't have model specifiers for the CPU like
other architectures do -- you can say "alphaev56-linux" or "i586-linux" to
"configure" to select a specific member of the architectures.  There is no
equivalent for MIPS.

 Hardcoding "mips:generic" as the default might be acceptable, though.

> that has explicitly been marked as code using .type; I did very much
> prefer the old behaviour of disassembling everything in sections that are
> marked to contain code.

 Well, the "-S" option is a workaround.  Otherwise bad sources should be
fixed -- everything gcc produces seems to be marked correctly, only
hand-coded assembler sources and inline asm appears marked wrong.  This is
boring, I know...

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +

Re: ssnop for mips

[Ralf Baechle]

On Fri, Jul 20, 2001 at 09:48:33AM -0700, cgd@sibyte.com wrote:

> > > The behavior, and that name, are unique to MIPS32 and MIPS64 (and
> > > chips which implement that specific instruction), but definitely _do
> > > not_ go back to MIPS I or even MIPS IV AFAIK.
> > 
> > Correct for MIPS I, II and III but wrong as for MIPS IV - R8000 has ssnop.
> 
> Interesting.  (Are there any on-line docs for r8k?  I took a quick
> look around, and saw nothing.  I like collecting docs.)

Docs for the R8k worth the name were never published.  I'm working on
getting permission to distribute code based on them (crucial for porting
Linux & Co) and hopefully also the docs themselfes.

I really hope those docs can be published soon.  The R8k is a interestingly
different CPU and knowing it seems to be somewhat important for writing
software that's portable throughout the whole line of MIPS processors.

> Since r8k is the 'canonical' cpu for MIPS IV in binutils, maybe it's
> appropriate to make MIPS IV disassemble ssnop as ssnop...  But there
> are a bunch of chips which claim to implement MIPS IV which, as far as
> I can tell, don't do SSNOP.  (An example is, from what I can tell from
> the documentation, the rm7k.)

R8k docs claim that ssnop is part of MIPS IV but most manuals don't document
it.

> On the other hand, MIPS themeselves claim that it's "new" in MIPS32
> (but that doesn't mean that there was no prior art -- only that it was
> a newly standardized part of the ISA as of MIPS32), but even worse I
> find no mention of special behaviour of "sll $0, $0, 1" in the MIPS IV
> ISA documentation available from e.g.:
> 
> http://techpubs.sgi.com/library/manuals/2000/007-2597-001/pdf/007-2597-001.pdf
> 
> (On the other hand, it kept mentioning "NOP" and "actual NOP" without
> explicitly defining that NOP _is_ "sll $0, $0, 0" so it seems fairly
> obvious that that document is not complete.  8-)

Typical RISCs have many instructions that are no-ops.  The ``official nop''
on MIPS is sll $zero, $zero, 0 but there are many more.

The only use of ssnop I know of is for dealing with cp0 hazards on R8k.
R10k, R12k and R14k solve that in hardware so treating ssnop as a ordinary
nop is just fine.  At least the R7k docs I have access to don't say anything
about ssnop; rm7k has two shifters so it indeed seems like it can even
multi-issue ssnops.

> I'll admit that I didn't search that manual as thoroughly as one
> might.  If you have a pointer to some specific documentation that
> indicates that in general "MIPS IV has ssnop" I'm quite willing to
> look at it.

R8k docs claim so.

> I also would like to see the MIPS ELF object format definition (if not
> the rest of the MIPS SvsV ABI bits -- I don't care about that stuff)
> updated to match present reality, at least in terms of stuff like
> flags, ISAs, architectures, etc.

I fear new members and extensions of the MIPS family grow faster than you
can extend the ABI ...

> I think it probably does make sense to have an option which basically
> says "try to decode all instructions into _something_, even though I
> acknowledge that that 'something' may be wrong or irrelevant."
> 
> I don't think it should be the default though.  (Because, really, as
> far as i'm concerned, unless asked to do otherwise, you have to do
> your best to provide correct data.  And, as a starting point for
> operation, you have to assume that the markings on the binaries are
> both correct and relevant.)

MIPS I - IV, MIPS32 and MIPS64 are well defined instruction sets.  So
disassembling those always by default should be fine.  ASEs and customer
specific extensions are a different issue.

  Ralf

Re: ssnop for mips

[cgd]

"Ralf Baechle" <ralf@uni-koblenz.de> writes:
> I fear new members and extensions of the MIPS family grow faster than you
> can extend the ABI ...

One would hope that that'll slow down a bit with MIPS32 and MIPS64
being "standard."


> MIPS I - IV, MIPS32 and MIPS64 are well defined instruction sets.  So
> disassembling those always by default should be fine.  ASEs and customer
> specific extensions are a different issue.

Problem is, what about when MIPS I - V, MIPS32, MIPS64 instructions
conflict with specific processors' extensions?

e.g. say a processor provides MIPS I + special-purpose extensions (not
really an odd situation 8-), and some of those extension instructions
conflict with instruction encodings which later become "well-defined."

you compile with -mips1 because that's basically what the processor
is, and that's how the binaries get marked.  but special-purpose
instructions (which conflict) that you've generated using inline
assembly will be incorrectly disassembled.

I still think you've gotta got with what the markings on the binary
say.


Anyway, "i'm done."  8-)


cgd

Re: ssnop for mips

[mike stump]

> From: Eric Christopher <echristo@redhat.com>
> To: mike stump <mrs@windriver.com>
> Cc: binutils@sources.redhat.com
> Date: 31 Jul 2001 09:45:02 +0100

> > When exactly should ssnop be valid?

> I think it should only be valid when it is explicitly described in
> the official documentation for the chip's ISA.  If it has a specific
> opcode etc.  Otherwise you'll just need to work around it like you
> have been.

Ok.  Since it wasn't in the ISAs before mips32, I'll take the above to
mean that status quo is what we want.  I won't install the patch in
question then.

Thanks for your time.

Re: ssnop for mips

[Eric Christopher]

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

Heh.  That'd be me (or some approximation of me).

> When exactly should ssnop be valid?

I think it should only be valid when it is explicitly described in the
official documentation for the chip's ISA.  If it has a specific opcode
etc.  Otherwise you'll just need to work around it like you have been.

-eric

--
Look out behind you!

Re: ssnop for mips

[mike stump]

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

Re: ssnop for mips

[Eric Christopher]

> 
> :-( Ok, scratch that idea for the second...  Can I have write after
> approval access for binutils (src?) (I have an assigment on file with
> the FSF, in case you wonder)?  Barring that, could someone check the
> change into the two branches for me, thanks.

I don't doubt you have an assignment on file :)

Nick will have to give you write after approval though.  Since it is 1am
here in the UK you'll need to wait until tomorrow for that :)

-eric

-- 
I will not grease the monkey bars

Re: ssnop for mips

[mike stump]

> From: Eric Christopher <echristo@redhat.com>
> To: mike stump <mrs@windriver.com>
> Cc: binutils@gcc.gnu.org
> Date: 19 Jul 2001 00:10:13 +0000

> On 18 Jul 2001 16:02:18 -0700, mike stump wrote:
> > Can I check this into the release branch as well as mainline?
> > 

> Sure.  I hadn't seen it in any MIPS 1 doc, but I'll take your word on
> it.  :)

kankakee bash[1794] scvs-binutils ci ChangeLog mips-opc.c 
Enter passphrase for RSA key 'mrs@kankakee': 
Sorry, you don't have read/write access to the history file /cvs/src/CVSROOT/history
Permission denied

:-( Ok, scratch that idea for the second...  Can I have write after
approval access for binutils (src?) (I have an assigment on file with
the FSF, in case you wonder)?  Barring that, could someone check the
change into the two branches for me, thanks.

Re: ssnop for mips

[Eric Christopher]

> 
> Check out SLL r0, r0, 1, if you are interested.  :-)
> 

Thanks.  Will do.

> Thanks for the fast ok.

:)  I'm still up.  Online and checking email ;)

-eric

-- 
I will not grease the monkey bars

Re: ssnop for mips

[mike stump]

> From: Eric Christopher <echristo@redhat.com>
> To: mike stump <mrs@windriver.com>
> Cc: binutils@gcc.gnu.org
> Date: 19 Jul 2001 00:10:13 +0000

> On 18 Jul 2001 16:02:18 -0700, mike stump wrote:
> > Can I check this into the release branch as well as mainline?
> > 

> Sure.  I hadn't seen it in any MIPS 1 doc, but I'll take your word on
> it.  :)

Check out SLL r0, r0, 1, if you are interested.  :-)

Thanks for the fast ok.