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


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


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