This is the mail archive of the
binutils@sources.redhat.com
mailing list for the binutils project.
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