Re: [WIP/RFC] MIPS registers overhaul

[cgd at broadcom dot com]

At Mon, 16 Jun 2003 20:43:06 +0000 (UTC), "Andrew Cagney" wrote:
> > And then to follow on from that:
> > * if 32-bit FPU (32-bit MIPS or 64-bit MIPS with FR == 0), assume you
> >   have 16 of them, or
> 
> Careful.  If the ABI is o32, and FR == 0/..., then there should be
> only 16 floating point registers in use.  The original MIPS 1, and
> r5900 ABIs would both allow use of all 32 32 bit floating point
> registers.

I don't know that that is correct, at least about the "original MIPS
1" behaviour.

I have here a copy of Kane's "MIPS RISC Architecture" which describes
the r2k/r3k (and FPA).  (Mmm, books > 10 yrs old.  8-)

For all of the FP operate instructions:

        ADD.fmt SUB.fmt MUL.fmt DIV.fmt ABS.fmt MOV.fmt NEG.fmt
        CVT.S.fmt CVT.D.fmt C.cond.fmt

(i.e., all of the operate instructions except CVT.W.fmt), there are
words like the following in the instruction description:

        On the FPA, this operation is valid only for double- or
        single-precision floating-point formats.  This operation is
        not defined if bit 0 of any register specification is set, as
        the register numbers specify and even-odd pair of adjacent
        coprocessor general registers (FGR).

There are slightly variations in wording in the first sentence (extra
words for the CVT.[SD].fmt ops), and for the CVT.[SD].fmt ops single
fixed-point format is allowed and the type of the op isn't allowed
(i.e., no double for CVT.D.fmt).

Note that CVT.W.fmt uses the wording for the second sentence:

        For double-precision format, this operation is not defined
        [rest of sentence as above].


Note that the Kane/Heinrich version that includes the r6k and r4k
makes a complete mess of the issue, using different wording that *does
not* AFAIK agree with the above.  Of course, it omits a bunch of
things and gets a bunch of things wrong, so more lossage isn't
surprising to me.  8-)


cgd
--
Chris Demetriou                                            Broadcom Corporation
Principal Design Engineer                     Broadband Processor Business Unit
  Any opinions expressed in this message are mine, not necessarily Broadcom's.