MIPS o32 ABI spec, $fp1 valid?

MIPS o32 ABI spec, $fp1 valid?

[Andrew Cagney]

Hello,

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

Re: MIPS o32 ABI spec, $fp1 valid?

[Daniel Jacobowitz]

On Mon, Jun 16, 2003 at 02:36:29PM -0400, Andrew Cagney wrote:
> Hello,
> 
> 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).

Hum, here's what the SysV ABI Supplement for MIPS (1996?) has to say:

Co-processor 1 adds 32 32-bit floating-point general registers and a
32-bit control/status register. Each even/odd pair of the 32
floating-point general registers can be used as either a 32-bit
single-precision floating-point register or as a 64-bit
double-precision floating-point register. For single-precision values,
the even-numbered floating-point register holds the value. For
double-precision values, the even-numbered floating-point register
holds the least significant 32 bits of the value and the odd-numbered
floating-point register holds the most significant 32 bits of the
value. This is always true, regardless of the byte ordering conventions
in use ( big endian or little endian).


Which is actually pretty ambiguous, but GCC goes out of its way not to
put floats in odd-numbered FP registers (unless -msingle-float), so I'm
guessing that the ABI spec says they may _not_ be used.

-- 
Daniel Jacobowitz
MontaVista Software                         Debian GNU/Linux Developer

Re: MIPS o32 ABI spec, $fp1 valid?

[cgd]

At Mon, 16 Jun 2003 18:52:04 +0000 (UTC), "Daniel Jacobowitz" wrote:
> Co-processor 1 adds 32 32-bit floating-point general registers and a
> 32-bit control/status register. Each even/odd pair of the 32
> floating-point general registers can be used as either a 32-bit
> single-precision floating-point register or as a 64-bit
> double-precision floating-point register. For single-precision values,
> the even-numbered floating-point register holds the value. For
> double-precision values, the even-numbered floating-point register
> holds the least significant 32 bits of the value and the odd-numbered
> floating-point register holds the most significant 32 bits of the
> value. This is always true, regardless of the byte ordering conventions
> in use ( big endian or little endian).

FYI, the above agrees with my reading of Kane (see
http://sources.redhat.com/ml/gdb-patches/2003-06/msg00555.html ).

The ISBN is 0135847494.  it can be found used in lots of places for
approx $10.  I paid more for mine 10+ years ago.  8-)


> Which is actually pretty ambiguous,

not really at all: "Each even/odd pair... as either _a_ 32-bit ..."
etc.

Kane makes clear:

        In the following pages, the notation <i>FGR</i> refers to the
        FPA's general register 0 through 31, and <i>FPR</i> refers ot
        the FPA's floating-point registers (FPR 0 through 30) which
        are formed by concatenation of FGR's[sic] (as described in
        <b>Chapter 6</b>).

Chapter 6 really makes quite clear that there are 16 FGRs.



cgd

Re: MIPS o32 ABI spec, $fp1 valid?

[Andrew Cagney]

Now we're getting somewhere :-)  Next question.

Does the o32 ABI specify how to spill a loating point register (a spill 
is different to a double store of a parameter as a spilt register is 
recovered by the unwind code.  mdebug might, for instance, specify 
something.

Andrew


>> Co-processor 1 adds 32 32-bit floating-point general registers and a
>> 32-bit control/status register. Each even/odd pair of the 32
>> floating-point general registers can be used as either a 32-bit
>> single-precision floating-point register or as a 64-bit
>> double-precision floating-point register. For single-precision values,
>> the even-numbered floating-point register holds the value. For
>> double-precision values, the even-numbered floating-point register
>> holds the least significant 32 bits of the value and the odd-numbered
>> floating-point register holds the most significant 32 bits of the
>> value. This is always true, regardless of the byte ordering conventions
>> in use ( big endian or little endian).
> 
> 
> FYI, the above agrees with my reading of Kane (see
> http://sources.redhat.com/ml/gdb-patches/2003-06/msg00555.html ).
> 
> The ISBN is 0135847494.  it can be found used in lots of places for
> approx $10.  I paid more for mine 10+ years ago.  8-)
> 
> 
> 
>> Which is actually pretty ambiguous,
> 
> 
> not really at all: "Each even/odd pair... as either _a_ 32-bit ..."
> etc.
> 
> Kane makes clear:
> 
>         In the following pages, the notation <i>FGR</i> refers to the
>         FPA's general register 0 through 31, and <i>FPR</i> refers ot
>         the FPA's floating-point registers (FPR 0 through 30) which
>         are formed by concatenation of FGR's[sic] (as described in
>         <b>Chapter 6</b>).
> 
> Chapter 6 really makes quite clear that there are 16 FGRs.
> 
> 
> 
> cgd
> 
> 

MIPS o32 ABI spec, $fp1 valid?

[David Anderson]

>
>
>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...]

Re: MIPS o32 ABI spec, $fp1 valid?

[David Anderson]

Andrew Cagney <ac131313@redhat.com> writes:
>Does the o32 ABI specify how to spill a loating point register (a spill 
>is different to a double store of a parameter as a spilt register is 
>recovered by the unwind code.  mdebug might, for instance, specify 
>something.

No, mdebug says nothing about how spills are done (it says nothing
about how exactly float/double are stored, AFAICT).

The hardware requires mentioning the odd regs to get the entire
64 bits stored.  In MIPS1.

Here is some mips1 o32 disassembly output, IRIX, so big-endian:
Given 
...stuff
double x1(double d)
{
        double d2 = d + 3.0;
        d2 += x2(5.0);
        return d2/4.5;
}
...stuff

x1:
[  11] 0x  48:  3c 1c 00 00    lui $gp,0
[  11] 0x  4c:  27 9c 00 00    addiu $gp,$gp,0
[  11] 0x  50:  03 99 e0 21    addu $gp,$gp,$25
[  11] 0x  54:  27 bd ff c8    addiu $sp,$sp,-56
[  11] 0x  58:  e7 ad 00 38    swc1 $f13,56($sp)
[  11] 0x  5c:  e7 ac 00 3c    swc1 $f12,60($sp)
[  12] 0x  60:  3c 01 40 08    lui $1,16392
[  12] 0x  64:  44 81 38 00    mtc1 $1,$f7
[  12] 0x  68:  c7 a4 00 3c    lwc1 $f4,60($sp)
[  12] 0x  6c:  c7 a5 00 38    lwc1 $f5,56($sp)
[  12] 0x  70:  44 80 30 00    mtc1 $0,$f6
[  13] 0x  74:  8f 99 00 00    lw $25,0($gp)
[  12] 0x  78:  46 26 22 00    add.d $f8,$f4,$f6
[  13] 0x  7c:  3c 01 40 14    lui $1,16404
[  11] 0x  80:  af bf 00 24    sw $31,36($sp)
[  13] 0x  84:  44 81 68 00    mtc1 $1,$f13
[  13] 0x  88:  44 80 60 00    mtc1 $0,$f12
[  11] 0x  8c:  af bc 00 20    sw $gp,32($sp)
[  11] 0x  90:  e7 b5 00 18    swc1 $f21,24($sp)
[  11] 0x  94:  e7 b4 00 1c    swc1 $f20,28($sp)
[  12] 0x  98:  e7 a8 00 34    swc1 $f8,52($sp)
[  13] 0x  9c:  03 20 f8 09    jalr $25
[  12] 0x  a0:  e7 a9 00 30    swc1 $f9,48($sp)
[  13] 0x  a4:  c7 ab 00 30    lwc1 $f11,48($sp)
[  13] 0x  a8:  c7 aa 00 34    lwc1 $f10,52($sp)
[  13] 0x  ac:  46 20 05 06    mov.d $f20,$f0
[  13] 0x  b0:  46 34 54 00    add.d $f16,$f10,$f20
[  14] 0x  b4:  3c 01 40 12    lui $1,16402
[  14] 0x  b8:  44 81 98 00    mtc1 $1,$f19
[  14] 0x  bc:  44 80 90 00    mtc1 $0,$f18
[  14] 0x  c0:  8f bf 00 24    lw $31,36($sp)
[  13] 0x  c4:  e7 b0 00 34    swc1 $f16,52($sp)
[  13] 0x  c8:  e7 b1 00 30    swc1 $f17,48($sp)
[  13] 0x  cc:  8f bc 00 20    lw $gp,32($sp)
[  14] 0x  d0:  c7 b4 00 1c    lwc1 $f20,28($sp)
[  14] 0x  d4:  c7 b5 00 18    lwc1 $f21,24($sp)
[  14] 0x  d8:  27 bd 00 38    addiu $sp,$sp,56
[  14] 0x  dc:  03 e0 00 08    jr $31
[  14] 0x  e0:  46 32 80 03    div.d $f0,$f16,$f18


Looking at cc -S output we see the fp regs are not invidually
mentioned:

 #   9  }
 #  10  double x1(double d)
 #  11  {
        .ent    x1 2
x1:
        .option O1
        .set     noreorder
        .cpload $25
        .set     reorder
        subu    $sp, 56
        sw      $31, 36($sp)
        .cprestore      32
        s.d     $f12, 56($sp)
        s.d     $f20, 24($sp)
        .mask   0x90000000, -20
        .fmask  0x00300000, -32
        .frame  $sp, 56, $31
        .loc    2 11
...

Now I must admit I am using a modern compiler, not an original
old mips1 compiler. So while the spill would be the same, 
(and same as reg saves) I don't recall precisely how it would
really look in IRIX mips1 assembler.




Regards,
David B. Anderson davea@sgi.com http://reality.sgiweb.org/davea

Re: MIPS o32 ABI spec, $fp1 valid?

[Andrew Cagney]

> Andrew Cagney <ac131313@redhat.com> writes:
> 
>>Does the o32 ABI specify how to spill a loating point register (a spill 
>>is different to a double store of a parameter as a spilt register is 
>>recovered by the unwind code.  mdebug might, for instance, specify 
>>something.
> 
> 
> No, mdebug says nothing about how spills are done (it says nothing
> about how exactly float/double are stored, AFAICT).

Sigh.  However, this code is finally starting to make [partial] sense.

> The hardware requires mentioning the odd regs to get the entire
> 64 bits stored.  In MIPS1.
> 
> Here is some mips1 o32 disassembly output, IRIX, so big-endian:
> Given 

> double x1(double d)
> {
>         double d2 = d + 3.0;
>         d2 += x2(5.0);
>         return d2/4.5;
> }

The param

> [  11] 0x  58:  e7 ad 00 38    swc1 $f13,56($sp)
> [  11] 0x  5c:  e7 ac 00 3c    swc1 $f12,60($sp)

The spill

> [  11] 0x  90:  e7 b5 00 18    swc1 $f21,24($sp)
> [  11] 0x  94:  e7 b4 00 1c    swc1 $f20,28($sp)
> [  12] 0x  98:  e7 a8 00 34    swc1 $f8,52($sp)
> [  13] 0x  9c:  03 20 f8 09    jalr $25
> [  12] 0x  a0:  e7 a9 00 30    swc1 $f9,48($sp)


>  #   9  }
>  #  10  double x1(double d)
>  #  11  {
>         .ent    x1 2
> x1:
>         .option O1
>         .set     noreorder
>         .cpload $25
>         .set     reorder
>         subu    $sp, 56
>         sw      $31, 36($sp)
>         .cprestore      32
>         s.d     $f12, 56($sp)
>         s.d     $f20, 24($sp)
>         .mask   0x90000000, -20
>         .fmask  0x00300000, -32
>         .frame  $sp, 56, $31
>         .loc    2 11
> ...
> 
> Now I must admit I am using a modern compiler, not an original
> old mips1 compiler. So while the spill would be the same, 
> (and same as reg saves) I don't recall precisely how it would
> really look in IRIX mips1 assembler.

Ref: mips_find_saved_regs /float_mask/ at the end of the function.
I believe that the debug info indicates that $f20/$f21 were both saved. 
  The code comes with the comment:

     /* Apparently, the freg_offset gives the offset to the first 64
        bit saved.

        When the ABI specifies 64 bit saved registers, the FREG_OFFSET
        designates the first saved 64 bit register.

        When the ABI specifies 32 bit saved registers, the ``64 bit
        saved DOUBLE'' consists of two adjacent 32 bit registers, Hence
        FREG_OFFSET, designates the address of the lower register of
        the register pair.  Adjust the offset so that it designates the
        upper register of the pair -- i.e., the address of the first
        saved 32 bit register.  */

Now, from the thread so far, it is clear that the comment is only 
partially correct.  It should indicate that:

On a big endian 32 bit ABI, the compiler spills floating-point registers 
as a pair and as a floating-point double.  Because the target is 
big-endian, this leads to the register pair being stored in reverse 
order vis: $fN ||| $fN+1 are stored as $fN+1 and then $fN.

The code doesn't do that, it gets the address of $fN correct, but $fN+1 
is 8 bytes out.  Outch!

Given o32, GDB needs to track the location of the individual 32 bit 
floating point registers and not 64 bit FP pairs.  By doing that, the 
code (mips_register_to_value):

   frame_read_register (frame, regnum + 0, (char *) to + 4);
   frame_read_register (frame, regnum + 1, (char *) to + 0);

is able to correctly construct a double value for any frame.

Andrew

(dave, one last favour, can you check -o32 -mips>1 to see if the fmask 
remains the same.  I'd expect it to).