Re: ssnop for mips

[cgd at sibyte dot com]

"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