MIPS o32 ABI spec, $fp1 valid?

[David Anderson <davea@quasar.engr.sgi.com>]

>
>
>KevinB and I were discussing MIPS cleanups for better handling things 
>like o32 ABI.  One question was can the o32 ABI use odd floating point 
>registers?  The MIPS certainly has them, and instructions can certainly 
>access them.  However, according to the o32 ABI, can they be used?
>
>(alternativly, does anyone have a MIPS o32 ABI spec, and even the 
>original ABI spec that went with the MIPS 1).
>
>Andrew


The o32 ABI was published by Prentice Hall and was more
recently on line at SCO, now at Caldera.  See
http://www.caldera.com/developers/devspecs/ Called the "MIPS
Processor Supplement" This document implies (Chap 3, Floating
Point Registers) strongly that only the even register numbers
are usable (see below here).

The actual detailed ABI (called the Black Book, titled "ABI
Conformance Guide") was never available generally (I have a
copy of several versions).

According to Sweetman ("See MIPS Run")  the odd fp registers
are usable only as part of the load-store/move.  Not in
operations like add/sum/mul

I also looked at Heinrich, "MIPS R4000 Uses Guide" and  "MIPS
IV Instruction Set" (SGI/MTI, prerelease version from July
1994).

All of these are consistent, if differently worded and with
some lack of precision in places.

This means, effectively, that there are just 16 double fp regs
or (viewed as single precision) 16 single precision fp regs and
only the even numbers are used.  Assembler code does not even
use the odd regs, as assembler 'macros' take care of that
detail. (not truly macros in the sense of C, but nonetheless
the necessity to mfc1/mtc1 of the odd regs is not coded in
assembly, but created by the assembler)

The confusing side effect is that if you look at a
*disassembly* of o32 code you will see the odd regs named in
mfc1/mtc1 ops but that's an 'implementation detail'.  You can't
do arithmetic on them o32 (ie FR bit in CPU status reg == 0)


Regards,
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea
[any mistakes here are my own, not those of the respective
authors, most likely...]