Re: Aha!

[Jun Sun <jsun@mvista.com>]

"Christopher C. Chimelis" wrote:
> 
> On Tue, 5 Sep 2000, Florian Lohoff wrote:
> 
> > Relativ jumps on mips are limited to 32K each direction. Otherwise
> > you need to use a register.
> 
> Yeah, I got further explanation on this before.  Seems that there is a bug
> in binutils currently and it's known by the SGI folk.
> 
> To quote Ulf:
> 
>   This is a known bug in binutils.  The branch instruction should be
>   replaced with a relocation and a jump instruction in this case.  The
>   code is however not there.
> 
> > Current gcc and binutils ( i tried 20000822 work )
> 
> I'll try again, but my last attempt didn't work.  I'll double-check my
> versions, though.
> 
> C
> 

Christopher,

One time I posted a question about MIPS architecture, and Kevin Kissel
from SGI gave an excellent reply.  I attached the reply in this email,
and hopefully you find it useful.

As for binutil/gcc tools, the most needed version is for MIPS II, which
is a subset of MIPS32.  You will see MIPS 32 used a lot in the embedded
world.  And personally, I don't think MIPS will have bright future in
the destop world.

Jun

MIPS I, II, III, IV, and V are ISAs, instruction-set architectures.
R3000, R4000, R5000, R6000, R7000, R8000 et. al.
are microprocessor designs that conform (more-or-less)
to one of those ISAs.   The ISAs were defined in such a
way as to be strict supersets of one another.  Any MIPS
processor can run MIPS I code.  Any MIPS IV processor
can run MIPS I, II, III, and IV code, etc.  To oversimplify
slightly:

MIPS I - basic 32-bit RISC ISA
MIPS II - add branch-likely and Test instructions
MIPS III - add 64-bit address and 64-bit data support
MIPS IV - add FP MAC, Prefetch
MIPS V - add "paired single" SIMD FP instructions

As defined by MIPS in the beginning, the ISA - i.e. MIPS I, 
MIPS II, etc. - described the machine as seen from the 
standpoint of a user-mode application program.  The 
CP0 instructions and registers weren't considered a part 
of it.  This gave chip designers a lot of freedom and OS
writers a lot of headaches.  The R8000, for example, was
the first MIPS IV CPU, and is 100% (well, maybe 99.99%)
compatible with the MIPS IV R10000 at the user binary level.
But while the R10000 has a CP0 organization that is
a straightforward extrapolation of the R4000 - they
wanted it to run NT, after all - the R8000 is just bizzare.

Another problem with the way things had been done
in the MIPS I/II/III days was that, due to the strict supersetting
rules, any new feature had to ride on the back of all the
other cool new features that came before it.  As a specific
example, PREFetch is a MIPS IV instruction. But MIPS IV 
implies MIPS III, and MIPS III implies a 64-bit CPU.  So a 
32-bit CPU supporting prefetch, which is a fairly obviously 
useful thing, does not fit neatly into the model.  So...

When MIPS Technologies spun back out of SGI, one of
the first things that was done was to set about defining
standard architectures for 32 and 64-bit CPUs that
solved these problems.  These new standard architectures
are "MIPS32" and "MIPS64".   These architectures include
both the ISA and the privileged resource architecture, or
PRA, so that CP0 is finally standardised - with some amount
of permitted subsetting and implementation-specific details
allowed, just the same.  The MIPS32 ISA includes features
from MIPS I, II, III, IV, and V, as well as some stuff like
integer MADD, MSUB, CLZ, and CLO that had never
made it into the standard user mode ISA.  But MIPS32
has no 64-bit operations.  MIPS64 is the full-blown 64-bit 
MIPS I-V+ ISA plus a PRA that is a strict superset of the 
MIPS32 PRA.

So, to get back to Linux, a MIPS32 part can *almost*
run the standard MIPS R4K kernel.  Almost.  What had
to be fixed was essentially:

    - ensuring that TLB initialization and invalidation never
       write identical (even though invalid) entries to the TLB.
       MIPS32 parts are allowed to complain about that, and
       some of them do.
    - ensuring that no 64-bit instructions are ever used.  This
       necessitated my rewriting the semaphore support code.
    - eliminating certain assumptions about the relationship
       between cache size, line size, and associativity.

Note that none of this stuff is incompatible with an R4xxx
or an R5xxx, its just a matter of being a little more generic.
And of course the flip side is that we don't use prefetch,
MADD, or CLZ in the kernel either, because the MIPS III-IV
parts can't handle them (well, OK, some of them can).

            Hope this helps,

            Keivn K.