Re: [PATCH] Basic support for MIPS r5900
Hello Richard, Am 25.06.2013 um 23:24 schrieb Richard Sandiford rdsandif...@googlemail.com: Jürgen Urban juergenur...@gmx.de writes: Am 23.06.2013 um 22:21 schrieb Richard Sandiford rdsandif...@googlemail.com: In the native PS2SDK (i.e. no Linux) I detected that there are undefined references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3', __extenddftf2', `__lttf2' and `__gttf2'. These are the functions for handling long double. There is a fix needed for this in libgcc. I attached 2 patches to this e-mail. There should be only one of the patches used to fix this. The first one fixes the problem for all mips systems. The second one fixes this only for r5900. I think it is a general problem. I assume the undefined references could appear on all mips64 systems which are not Linux. So the first patch should be applied. The second patch is right. Not all targets have 128-bit long doubles, so t-tpbit is intentionally an opt-in rather than opt-out thing. E.g. mips*-sde-elf and mips*-mti-elf both use: #undef LONG_DOUBLE_TYPE_SIZE #define LONG_DOUBLE_TYPE_SIZE 64 to get a form of n32 in which long doubles are the same as doubles. Do you want to stick with 128-bit long doubles for PS2, or would you prefer to do what SDE does? I prefer shorter long doubles because of the performance impact. For 32 bit hard float we may need it. Can you change it or do I need to submit a patch? OK, could you give this a go? I tested it and it is working as expected. Best regards Jürgen
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: Am 25.06.2013 um 23:24 schrieb Richard Sandiford rdsandif...@googlemail.com: Jürgen Urban juergenur...@gmx.de writes: Am 23.06.2013 um 22:21 schrieb Richard Sandiford Do you want to stick with 128-bit long doubles for PS2, or would you prefer to do what SDE does? I prefer shorter long doubles because of the performance impact. For 32 bit hard float we may need it. Can you change it or do I need to submit a patch? OK, could you give this a go? I tested it and it is working as expected. Now applied, thanks. Richard
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes:
Am 23.06.2013 um 22:21 schrieb Richard Sandiford rdsandif...@googlemail.com:
In the native PS2SDK (i.e. no Linux) I detected that there are undefined
references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
__extenddftf2', `__lttf2' and `__gttf2'. These are the functions for
handling long double.
There is a fix needed for this in libgcc. I attached 2 patches to this
e-mail. There should be only one of the patches used to fix this.
The first one fixes the problem for all mips systems. The second one
fixes this only for r5900. I think it is a general problem. I assume the
undefined references could appear on all mips64 systems which are not
Linux. So the first patch should be applied.
The second patch is right. Not all targets have 128-bit long doubles,
so t-tpbit is intentionally an opt-in rather than opt-out thing.
E.g. mips*-sde-elf and mips*-mti-elf both use:
#undef LONG_DOUBLE_TYPE_SIZE
#define LONG_DOUBLE_TYPE_SIZE 64
to get a form of n32 in which long doubles are the same as doubles.
Do you want to stick with 128-bit long doubles for PS2, or would you
prefer to do what SDE does?
I prefer shorter long doubles because of the performance impact. For 32
bit hard float we may need it. Can you change it or do I need to submit
a patch?
OK, could you give this a go?
Thanks,
Richard
gcc/
* config.gcc (mips*-mti-elf*, mips*-sde-elf*, mips64r5900-*-elf*)
(mips64r5900el-*-elf*): Include mips/n32-elf.h.
* config/mips/sde.h (LOCAL_LABEL_PREFIX, NO_DOLLAR_IN_LABEL)
(LONG_DOUBLE_TYPE_SIZE, LIBGCC2_LONG_DOUBLE_TYPE_SIZE): Move to...
* config/mips/n32-elf.h: ...this new file.
Index: gcc/config.gcc
===
--- gcc/config.gcc 2013-06-25 22:15:25.414731542 +0100
+++ gcc/config.gcc 2013-06-25 22:15:29.076761150 +0100
@@ -1850,12 +1850,12 @@ mips*-*-linux*) # Linux MIPS,
either
esac
;;
mips*-mti-elf*)
- tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/sde.h
mips/mti-elf.h
+ tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/n32-elf.h
mips/sde.h mips/mti-elf.h
tmake_file=mips/t-mti-elf
tm_defines=${tm_defines} MIPS_ISA_DEFAULT=33 MIPS_ABI_DEFAULT=ABI_32
;;
mips*-sde-elf*)
- tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/sde.h
+ tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/n32-elf.h
mips/sde.h
tmake_file=mips/t-sde
extra_options=${extra_options} mips/sde.opt
case ${with_newlib} in
@@ -1937,7 +1937,7 @@ mips-*-elf* | mipsel-*-elf* | mipsr5900-
tmake_file=mips/t-elf
;;
mips64r5900-*-elf* | mips64r5900el-*-elf*)
- tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h
+ tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h mips/n32-elf.h
tmake_file=mips/t-elf
tm_defines=${tm_defines} MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_N32
;;
Index: gcc/config/mips/sde.h
===
--- gcc/config/mips/sde.h 2013-06-25 22:15:27.563748916 +0100
+++ gcc/config/mips/sde.h 2013-06-25 22:15:33.443796467 +0100
@@ -89,23 +89,6 @@ #define SIZE_TYPE long unsigned int
#undef PTRDIFF_TYPE
#define PTRDIFF_TYPE long int
-/* Use standard ELF-style local labels (not '$' as on early Irix). */
-#undef LOCAL_LABEL_PREFIX
-#define LOCAL_LABEL_PREFIX .
-
-/* Use periods rather than dollar signs in special g++ assembler names. */
-#define NO_DOLLAR_IN_LABEL
-
-/* Currently we don't support 128bit long doubles, so for now we force
- n32 to be 64bit. */
-#undef LONG_DOUBLE_TYPE_SIZE
-#define LONG_DOUBLE_TYPE_SIZE 64
-
-#ifdef IN_LIBGCC2
-#undef LIBGCC2_LONG_DOUBLE_TYPE_SIZE
-#define LIBGCC2_LONG_DOUBLE_TYPE_SIZE 64
-#endif
-
/* Force all .init and .fini entries to be 32-bit, not mips16, so that
in a mixed environment they are all the same mode. The crti.asm and
crtn.asm files will also be compiled as 32-bit due to the
Index: gcc/config/mips/n32-elf.h
===
--- /dev/null 2013-06-17 18:11:16.259026486 +0100
+++ gcc/config/mips/n32-elf.h 2013-06-25 22:15:29.076761150 +0100
@@ -0,0 +1,35 @@
+/* Definitions of target machine for GNU compiler.
+ n32 for embedded systems.
+ Copyright (C) 2003-2013 Free Software Foundation, Inc.
+
+This file is part of GCC.
+
+GCC is free software; you can redistribute it and/or modify
+it under the terms of the GNU General Public License as published by
+the Free Software Foundation; either version 3, or (at your option)
+any later version.
+
+GCC is distributed in the hope that it will be useful,
+but WITHOUT ANY WARRANTY; without even the implied warranty of
+MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the
+GNU General Public License for more details.
+
+You
Re: [PATCH] Basic support for MIPS r5900
Hello Richard, Am 23.06.2013 um 22:21 schrieb Richard Sandiford rdsandif...@googlemail.com: Jürgen Urban juergenur...@gmx.de writes: In the native PS2SDK (i.e. no Linux) I detected that there are undefined references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3', __extenddftf2', `__lttf2' and `__gttf2'. These are the functions for handling long double. There is a fix needed for this in libgcc. I attached 2 patches to this e-mail. There should be only one of the patches used to fix this. The first one fixes the problem for all mips systems. The second one fixes this only for r5900. I think it is a general problem. I assume the undefined references could appear on all mips64 systems which are not Linux. So the first patch should be applied. The second patch is right. Not all targets have 128-bit long doubles, so t-tpbit is intentionally an opt-in rather than opt-out thing. E.g. mips*-sde-elf and mips*-mti-elf both use: #undef LONG_DOUBLE_TYPE_SIZE #define LONG_DOUBLE_TYPE_SIZE 64 to get a form of n32 in which long doubles are the same as doubles. Do you want to stick with 128-bit long doubles for PS2, or would you prefer to do what SDE does? I prefer shorter long doubles because of the performance impact. For 32 bit hard float we may need it. Can you change it or do I need to submit a patch? Best regards Jürgen
Re: [PATCH] Basic support for MIPS r5900
Hello Richard,
Does it still work with those changes, as below? If so, I'll check it in.
I tested it. It is still working. So the patch is OK, please check it in.
OK, I've applied this and the config.gcc patch.
Thanks.
In the native PS2SDK (i.e. no Linux) I detected that there are undefined
references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3',
`__extenddftf2', `__lttf2' and `__gttf2'. These are the functions for handling
long double.
There is a fix needed for this in libgcc. I attached 2 patches to this e-mail.
There should be only one of the patches used to fix this.
The first one fixes the problem for all mips systems. The second one fixes this
only for r5900. I think it is a general problem. I assume the undefined
references could appear on all mips64 systems which are not Linux. So the first
patch should be applied.
Checking for ac_cv_sizeof_long_double should work on all mips systems, but I
don't know why the check was only in the mips*-linux part of the file
libgcc/config.host.
Best regards
JürgenIndex: libgcc/config.host
===
--- libgcc/config.host (Revision 200155)
+++ libgcc/config.host (Arbeitskopie)
@@ -136,6 +136,9 @@
mips*-*-*)
cpu_type=mips
tmake_file=mips/t-mips
+ if test ${ac_cv_sizeof_long_double} = 16; then
+ tmake_file=${tmake_file} mips/t-tpbit
+ fi
;;
powerpc*-*-*)
cpu_type=rs6000
@@ -751,9 +754,6 @@
;;
esac
md_unwind_header=mips/linux-unwind.h
- if test ${ac_cv_sizeof_long_double} = 16; then
- tmake_file=${tmake_file} mips/t-tpbit
- fi
;;
mips*-sde-elf*)
tmake_file=$tmake_file mips/t-crtstuff mips/t-mips16
Index: libgcc/config.host
===
--- libgcc/config.host (Revision 200155)
+++ libgcc/config.host (Arbeitskopie)
@@ -798,6 +798,9 @@
mips64r5900-*-elf* | mips64r5900el-*-elf*)
tmake_file=$tmake_file mips/t-elf mips/t-crtstuff
extra_parts=$extra_parts crti.o crtn.o
+ if test ${ac_cv_sizeof_long_double} = 16; then
+ tmake_file=${tmake_file} mips/t-tpbit
+ fi
;;
mips64vr-*-elf* | mips64vrel-*-elf*)
tmake_file=$tmake_file mips/t-elf mips/t-vr mips/t-crtstuff
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: Hello Richard, Does it still work with those changes, as below? If so, I'll check it in. I tested it. It is still working. So the patch is OK, please check it in. OK, I've applied this and the config.gcc patch. Thanks. In the native PS2SDK (i.e. no Linux) I detected that there are undefined references to `__fixtfsi', `__floatsitf', `__subtf3', `__multf3', __extenddftf2', `__lttf2' and `__gttf2'. These are the functions for handling long double. There is a fix needed for this in libgcc. I attached 2 patches to this e-mail. There should be only one of the patches used to fix this. The first one fixes the problem for all mips systems. The second one fixes this only for r5900. I think it is a general problem. I assume the undefined references could appear on all mips64 systems which are not Linux. So the first patch should be applied. The second patch is right. Not all targets have 128-bit long doubles, so t-tpbit is intentionally an opt-in rather than opt-out thing. E.g. mips*-sde-elf and mips*-mti-elf both use: #undef LONG_DOUBLE_TYPE_SIZE #define LONG_DOUBLE_TYPE_SIZE 64 to get a form of n32 in which long doubles are the same as doubles. Do you want to stick with 128-bit long doubles for PS2, or would you prefer to do what SDE does? Thanks, Richard
Aw: Re: [PATCH] Basic support for MIPS r5900
Hello Richard, The code is now completely moved into libgcc/config/mips/t-mips and libgcc/config/mips/lib2funcs.c (new file). The code should now be easier to understand. I used the code from libgcc/config/m32c as example (e.g. same file name lib2funcs.c). I copied the file header (LGPL) from a file which I believed to be new and correct. Thanks, this looks very clean. It's good that the new file compiles to nothing for ISA_HAS_DMULT/ISA_HAS_DDIV targets. In that case though, I think it should be added to LIB2ADD_ST rather than LIB2ADD. Objects from LIB2ADD are included in libgcc.so, which needs to have a stable interface, whereas LIB2ADD_ST is purely for libgcc.a, where this kind of variation is OK. Regarding LIB2ADD vs. LIB2ADD_ST: At the moment I can't run a test with shared libraries, but it seems to work when linking a program using shared libraries. There is no undefined reference to __muldi3 when linking shared and using the toolchain for r5900. Putting them in one file means they'll either all be pulled in or none will, but I doubt the size is going to matter in practice, right? Besides, that kind of thing could easily be tweaked later if it shows up as a problem. Also, I see you changed the patch so that mulmode3 tests ISA_HAS_DMULT in the C body rather than in the condition. Was that in response to my previous comment about define_expand conditions? Yes. Your first version was right because mulmode3 is a public pattern that's exposed to optabs (insn-opinit.c tests HAVE_mulmode3). The other two define_expands you mentioned are private to the MIPS port though and we never use HAVE_* for them. We only use them from places where the insns are already known to be valid. OK, now I know the missing details. The ISA_HAS_DMUL3 part was redundant, sorry for not noticing it last time. Yes, I thought it must be changed, but you are right. Does it still work with those changes, as below? If so, I'll check it in. I tested it. It is still working. So the patch is OK, please check it in. Best regards Jürgen
Re: Aw: Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: Does it still work with those changes, as below? If so, I'll check it in. I tested it. It is still working. So the patch is OK, please check it in. OK, I've applied this and the config.gcc patch. Thanks, Richard
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: Richard Sandiford rdsandif...@googlemail.com writes: I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc maintainer. Ian: the problem is that _muldi3.o on 64-bit targets is actually an implementation of __multi3. Jürgen wants to have a __muldi3 too, with the same implementation as on 32-bit targets. My assumption is that target maintainers can approve target-specific changes to libgcc, including Makefile changes. That said, it seems that this particular patch ought to mostly be in libgcc/config/mips/t-mips, using LIB2FUNCS_EXCLUDE and LIB2ADD. It's not clear to me that libgcc/Makefile.in needs any changes, and in case it should not be necessary for it to have anything like MIPSTYPE. That kind of thing belongs in config/mips. The code is now completely moved into libgcc/config/mips/t-mips and libgcc/config/mips/lib2funcs.c (new file). The code should now be easier to understand. I used the code from libgcc/config/m32c as example (e.g. same file name lib2funcs.c). I copied the file header (LGPL) from a file which I believed to be new and correct. Thanks, this looks very clean. It's good that the new file compiles to nothing for ISA_HAS_DMULT/ISA_HAS_DDIV targets. In that case though, I think it should be added to LIB2ADD_ST rather than LIB2ADD. Objects from LIB2ADD are included in libgcc.so, which needs to have a stable interface, whereas LIB2ADD_ST is purely for libgcc.a, where this kind of variation is OK. Putting them in one file means they'll either all be pulled in or none will, but I doubt the size is going to matter in practice, right? Besides, that kind of thing could easily be tweaked later if it shows up as a problem. Also, I see you changed the patch so that mulmode3 tests ISA_HAS_DMULT in the C body rather than in the condition. Was that in response to my previous comment about define_expand conditions? Your first version was right because mulmode3 is a public pattern that's exposed to optabs (insn-opinit.c tests HAVE_mulmode3). The other two define_expands you mentioned are private to the MIPS port though and we never use HAVE_* for them. We only use them from places where the insns are already known to be valid. The ISA_HAS_DMUL3 part was redundant, sorry for not noticing it last time. Does it still work with those changes, as below? If so, I'll check it in. Thanks, Richard gcc/ 2013-06-15 Jürgen Urban juergenur...@gmx.de * config/mips/mips.h (ISA_HAS_MUL3): Include TARGET_R5900. (ISA_HAS_MULT, ISA_HAS_DMULT, ISA_HAS_DIV, ISA_HAS_DDIV): New macros. * config/mips/mips.md (mulmode3, mulmode3_internal) (mulmode3_r4000): Require ISA_HAS_DMULT. (mulmode3_mul3): Handle TARGET_R5900. (mulsidi3_64bit_dmul): Remove redundant TARGET_64BIT test. (sumuldi3_highpart, sumuldi3_highpart_internal, umulditi3) (umulditi3_internal, umulditi3_r4000): Require ISA_HAS_DMULT instead of TARGET_64BIT. (divmodmode4, udivmodmode4, udivmodGPR:mode4_hilo_HILO:mode): Require ISA_HAS_DDIV. libgcc/ 2013-06-15 Jürgen Urban juergenur...@gmx.de * config/mips/lib2funcs.c: New file. * config/mips/t-mips (LIB2ADD_ST): Add it. Index: gcc/config/mips/mips.h === --- gcc/config/mips/mips.h 2013-06-15 14:55:16.985850737 +0100 +++ gcc/config/mips/mips.h 2013-06-15 19:32:51.637536044 +0100 @@ -807,6 +807,7 @@ #define ISA_HAS_BRANCHLIKELY(!ISA_MIPS1 #define ISA_HAS_MUL3 ((TARGET_MIPS3900 \ || TARGET_MIPS5400\ || TARGET_MIPS5500\ + || TARGET_MIPS5900\ || TARGET_MIPS7000\ || TARGET_MIPS9000\ || TARGET_MAD \ @@ -821,6 +822,22 @@ #define ISA_HAS_DMUL3 (TARGET_64BIT TARGET_OCTEON \ !TARGET_MIPS16) +/* ISA supports instructions DMULT and DMULTU. */ +#define ISA_HAS_DMULT (TARGET_64BIT !TARGET_MIPS5900) + +/* ISA supports instructions MULT and MULTU. + This is always true, but the macro is needed for ISA_HAS_DMULT + in mips.md. */ +#define ISA_HAS_MULT (1) + +/* ISA supports instructions DDIV and DDIVU. */ +#define ISA_HAS_DDIV (TARGET_64BIT !TARGET_MIPS5900) + +/* ISA supports instructions DIV and DIVU. + This is always true, but the macro is needed for ISA_HAS_DDIV + in mips.md. */ +#define ISA_HAS_DIV(1) + #define ISA_HAS_DIV3 ((TARGET_LOONGSON_2EF \ || TARGET_LOONGSON_3A)
Re: [PATCH] Basic support for MIPS r5900
Hello Richard,
I updated the patch as requested.
Richard Sandiford rdsandif...@googlemail.com writes:
I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc
maintainer. Ian: the problem is that _muldi3.o on 64-bit targets
is actually an implementation of __multi3. Jürgen wants to have a
__muldi3 too, with the same implementation as on 32-bit targets.
My assumption is that target maintainers can approve target-specific
changes to libgcc, including Makefile changes.
That said, it seems that this particular patch ought to mostly be in
libgcc/config/mips/t-mips, using LIB2FUNCS_EXCLUDE and LIB2ADD. It's
not clear to me that libgcc/Makefile.in needs any changes, and in case
it should not be necessary for it to have anything like MIPSTYPE. That
kind of thing belongs in config/mips.
The code is now completely moved into libgcc/config/mips/t-mips and
libgcc/config/mips/lib2funcs.c (new file).
The code should now be easier to understand.
I used the code from libgcc/config/m32c as example (e.g. same file name
lib2funcs.c). I copied the file header (LGPL) from a file which I believed to
be new and correct.
You can change it to whatever needed.
Best regards
JürgenIndex: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h (Revision 199708)
+++ gcc/config/mips/mips.h (Arbeitskopie)
@@ -807,6 +807,7 @@
#define ISA_HAS_MUL3 ((TARGET_MIPS3900 \
|| TARGET_MIPS5400 \
|| TARGET_MIPS5500 \
+ || TARGET_MIPS5900 \
|| TARGET_MIPS7000 \
|| TARGET_MIPS9000 \
|| TARGET_MAD\
@@ -819,8 +820,25 @@
/* ISA has a three-operand multiplication instruction. */
#define ISA_HAS_DMUL3 (TARGET_64BIT\
TARGET_OCTEON \
+ !TARGET_MIPS5900\
!TARGET_MIPS16)
+/* ISA supports instructions DMULT and DMULTU. */
+#define ISA_HAS_DMULT (TARGET_64BIT !TARGET_MIPS5900)
+
+/* ISA supports instructions MULT and MULTU.
+ This is always supported, but the macro is needed for ISA_HAS_DMULT
+ in mips.md. */
+#define ISA_HAS_MULT (1)
+
+/* ISA supports instructions DDIV and DDIVU. */
+#define ISA_HAS_DDIV(TARGET_64BIT !TARGET_MIPS5900)
+
+/* ISA supports instructions DIV and DIVU.
+ This is always supported, but the macro is needed for ISA_HAS_DDIV
+ in mips.md. */
+#define ISA_HAS_DIV (1)
+
#define ISA_HAS_DIV3 ((TARGET_LOONGSON_2EF \
|| TARGET_LOONGSON_3A) \
!TARGET_MIPS16)
Index: gcc/config/mips/mips.md
===
--- gcc/config/mips/mips.md (Revision 199708)
+++ gcc/config/mips/mips.md (Arbeitskopie)
@@ -1498,9 +1498,11 @@
}
else if (TARGET_FIX_R4000)
emit_insn (gen_mulmode3_r4000 (operands[0], operands[1], operands[2]));
- else
+ else if (ISA_HAS_DMULT)
emit_insn
(gen_mulmode3_internal (operands[0], operands[1], operands[2]));
+ else
+FAIL;
DONE;
})
@@ -1527,7 +1529,7 @@
{
if (which_alternative == 1)
return dmult\t%1,%2;
- if (MODEmode == SImode TARGET_MIPS3900)
+ if (MODEmode == SImode (TARGET_MIPS3900 || TARGET_MIPS5900))
return mult\t%0,%1,%2;
return dmul\t%0,%1,%2;
}
@@ -1561,7 +1563,7 @@
[(set (match_operand:GPR 0 muldiv_target_operand =l)
(mult:GPR (match_operand:GPR 1 register_operand d)
(match_operand:GPR 2 register_operand d)))]
- !TARGET_FIX_R4000
+ ISA_HAS_DMULT !TARGET_FIX_R4000
dmult\t%1,%2
[(set_attr type imul)
(set_attr mode MODE)])
@@ -1571,7 +1573,7 @@
(mult:GPR (match_operand:GPR 1 register_operand d)
(match_operand:GPR 2 register_operand d)))
(clobber (match_scratch:GPR 3 =l))]
- TARGET_FIX_R4000
+ ISA_HAS_DMULT TARGET_FIX_R4000
dmult\t%1,%2\;mflo\t%0
[(set_attr type imul)
(set_attr mode MODE)
@@ -2038,7 +2040,7 @@
(mult:DI (sign_extend:DI (match_operand:SI 1 register_operand d))
(sign_extend:DI (match_operand:SI 2 register_operand d
(clobber (match_scratch:DI 3 =l))]
- TARGET_64BIT ISA_HAS_DMUL3
+ ISA_HAS_DMUL3
dmul\t%0,%1,%2
[(set_attr type imul3)
(set_attr mode DI)])
@@ -2192,7 +2194,7 @@
(mult:TI (any_extend:TI (match_operand:DI 1 register_operand))
(any_extend:TI (match_operand:DI 2 register_operand)))
(const_int 64]
- TARGET_64BIT !(CODE == ZERO_EXTEND TARGET_FIX_VR4120)
+ ISA_HAS_DMULT !(CODE == ZERO_EXTEND TARGET_FIX_VR4120)
{
if (TARGET_MIPS16)
emit_insn (gen_sumuldi3_highpart_split (operands[0], operands[1],
@@ -2211,7 +2213,7 @@
(any_extend:TI (match_operand:DI 2 register_operand d)))
(const_int 64
(clobber (match_scratch:DI 3 =l))]
- TARGET_64BIT
+ ISA_HAS_DMULT
!TARGET_MIPS16
!(CODE == ZERO_EXTEND TARGET_FIX_VR4120)
{ return TARGET_FIX_R4000 ? dmultu\t%1,%2\n\tmfhi\t%0 : #; }
@@ -2247,7 +2249,7 @@
[(set (match_operand:TI 0 register_operand)
(mult:TI (any_extend:TI
Re: [PATCH] Basic support for MIPS r5900
On Fri, Jun 14, 2013 at 11:48 AM, Jürgen Urban juergenur...@gmx.de wrote: Hello Richard, I updated the patch as requested. Richard Sandiford rdsandif...@googlemail.com writes: I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc maintainer. Ian: the problem is that _muldi3.o on 64-bit targets is actually an implementation of __multi3. Jürgen wants to have a __muldi3 too, with the same implementation as on 32-bit targets. My assumption is that target maintainers can approve target-specific changes to libgcc, including Makefile changes. That said, it seems that this particular patch ought to mostly be in libgcc/config/mips/t-mips, using LIB2FUNCS_EXCLUDE and LIB2ADD. It's not clear to me that libgcc/Makefile.in needs any changes, and in case it should not be necessary for it to have anything like MIPSTYPE. That kind of thing belongs in config/mips. The code is now completely moved into libgcc/config/mips/t-mips and libgcc/config/mips/lib2funcs.c (new file). The code should now be easier to understand. I used the code from libgcc/config/m32c as example (e.g. same file name lib2funcs.c). I copied the file header (LGPL) from a file which I believed to be new and correct. You can change it to whatever needed. I think this patch requires only target maintainer approval, not libgcc maintainer approval. Ian
Re: Aw: Re: [PATCH] Basic support for MIPS r5900
Richard Sandiford rdsandif...@googlemail.com writes: I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc maintainer. Ian: the problem is that _muldi3.o on 64-bit targets is actually an implementation of __multi3. Jürgen wants to have a __muldi3 too, with the same implementation as on 32-bit targets. My assumption is that target maintainers can approve target-specific changes to libgcc, including Makefile changes. That said, it seems that this particular patch ought to mostly be in libgcc/config/mips/t-mips, using LIB2FUNCS_EXCLUDE and LIB2ADD. It's not clear to me that libgcc/Makefile.in needs any changes, and in case it should not be necessary for it to have anything like MIPSTYPE. That kind of thing belongs in config/mips. Ian
Re: Aw: Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: How much other changes will be currently accepted here? There is other stuff which I want to prepare and submit here, e.g.: 1. disable use of dmult and ddiv (ABI n32). 2. use trunc.w.s instead of cvt.w.s (to get single float working for normal range calculations; i.e. calculating without inf or nan). 3. fix use of ll/sc in libgomp, either increase mips ISA level or use syscall (which is broken in Linux 2.6.35.4). 4. fix libgcc to build a real muldi3 function for ABI n32 (not the multi3 function which is stored in muldi3.o file). 5. add support for configure parameters --float=single and --float=double in addition to --float=soft and --float=hard. 6. rework floating point to support single float with ABI n32 (either break the ABI or store floating point values in general purpose registers like soft float). 7. change libgcc or mips.md in way so that the non IEEE 754 compatible FPU of the r5900 gets compatible. Well, I'm afraid that's hard to say in advance. It really depends on what the changes look like. (1) and (2) sound harmless enough, although (1) should probably only be done in conjunction with (4). I'm not sure what (3) involves. (5) sounds like a good idea. (6) is worth doing, but anything ABI-related gets extra-paranoid treatment. :-) The attached patch fixes (1) and (4). This makes mips64r5900el usable with r5900. If (4) is a problem (i.e. patching libgcc/Makefile.in), it would be good if at least (1) is accepted. I can't approve the Makefile.in bits. I've cc'ed Ian, who's the libgcc maintainer. Ian: the problem is that _muldi3.o on 64-bit targets is actually an implementation of __multi3. Jürgen wants to have a __muldi3 too, with the same implementation as on 32-bit targets. I think (1) and (4) should go in together though. (1) doesn't make much sense without a libgcc function to back it up. The patch for mips.md after line 1992 (adds TARGET_64BIT) is a more general fix. This is not needed for r5900 support, but I think this should be fixed. The same applies for patch after 2233 (adds ISA_HAS_DMULT). The fix here would be also adding TARGET_64BIT, but for r5900 we need ISA_HAS_DMULT here. The current state is actually deliberate. define_expand conditions are only ever used in HAVE_* macros, so whatever we put there will not get tested. I think it's less confusing to have no test than an unused one, just like we try not to have constraints in define_expands. The other bits of the config/mips patch look good, thanks. A couple of formatting niggles: +/* ISA supports instructions dmult and dmultu. */ +#define ISA_HAS_DMULT (TARGET_64BIT \ + !TARGET_MIPS5900) + +/* ISA supports instructions mult and multu. + This always supported, but the macro is needed for ISA_HAS_DMULT + in mips.md. */ +#define ISA_HAS_MULT (1) + +/* ISA supports instructions ddiv and ddivu. */ +#define ISA_HAS_DDIV(TARGET_64BIT \ + !TARGET_MIPS5900) Please keep ISA_HAS_DMULT and ISA_HAS_DDIV on one line while they fit. I prefer caps for insn names in the comments, but the code isn't yet as consistent as it should be, sorry... +/* ISA supports instructions div and divu. + This always supported, but the macro is needed for ISA_HAS_DDIV + in mips.md. */ +#define ISA_HAS_DIV (1) + + Excess blank line here. Thanks, Richard
Aw: Re: [PATCH] Basic support for MIPS r5900
Hello Richard,
How much other changes will be currently accepted here? There is other
stuff which I want to prepare and submit here, e.g.:
1. disable use of dmult and ddiv (ABI n32).
2. use trunc.w.s instead of cvt.w.s (to get single float working for
normal range calculations; i.e. calculating without inf or nan).
3. fix use of ll/sc in libgomp, either increase mips ISA level or use
syscall (which is broken in Linux 2.6.35.4).
4. fix libgcc to build a real muldi3 function for ABI n32 (not the
multi3 function which is stored in muldi3.o file).
5. add support for configure parameters --float=single and
--float=double in addition to --float=soft and --float=hard.
6. rework floating point to support single float with ABI n32 (either
break the ABI or store floating point values in general purpose
registers like soft float).
7. change libgcc or mips.md in way so that the non IEEE 754 compatible
FPU of the r5900 gets compatible.
Well, I'm afraid that's hard to say in advance. It really depends
on what the changes look like. (1) and (2) sound harmless enough,
although (1) should probably only be done in conjunction with (4).
I'm not sure what (3) involves. (5) sounds like a good idea.
(6) is worth doing, but anything ABI-related gets extra-paranoid
treatment. :-)
The attached patch fixes (1) and (4). This makes mips64r5900el usable with
r5900. If (4) is a problem (i.e. patching libgcc/Makefile.in), it would be good
if at least (1) is accepted.
The patch for mips.md after line 1992 (adds TARGET_64BIT) is a more general
fix. This is not needed for r5900 support, but I think this should be fixed.
The same applies for patch after 2233 (adds ISA_HAS_DMULT). The fix here would
be also adding TARGET_64BIT, but for r5900 we need ISA_HAS_DMULT here. Other
changes in mips.md should not change the behaviour of GCC on non r5900
toolchains.
Best regards
JürgenIndex: gcc/config/mips/mips.h
===
--- gcc/config/mips/mips.h (Revision 199708)
+++ gcc/config/mips/mips.h (Arbeitskopie)
@@ -807,6 +807,7 @@
#define ISA_HAS_MUL3 ((TARGET_MIPS3900 \
|| TARGET_MIPS5400 \
|| TARGET_MIPS5500 \
+ || TARGET_MIPS5900 \
|| TARGET_MIPS7000 \
|| TARGET_MIPS9000 \
|| TARGET_MAD\
@@ -819,8 +820,28 @@
/* ISA has a three-operand multiplication instruction. */
#define ISA_HAS_DMUL3 (TARGET_64BIT\
TARGET_OCTEON \
+ !TARGET_MIPS5900\
!TARGET_MIPS16)
+/* ISA supports instructions dmult and dmultu. */
+#define ISA_HAS_DMULT (TARGET_64BIT\
+ !TARGET_MIPS5900)
+
+/* ISA supports instructions mult and multu.
+ This always supported, but the macro is needed for ISA_HAS_DMULT
+ in mips.md. */
+#define ISA_HAS_MULT (1)
+
+/* ISA supports instructions ddiv and ddivu. */
+#define ISA_HAS_DDIV(TARGET_64BIT\
+ !TARGET_MIPS5900)
+
+/* ISA supports instructions div and divu.
+ This always supported, but the macro is needed for ISA_HAS_DDIV
+ in mips.md. */
+#define ISA_HAS_DIV (1)
+
+
#define ISA_HAS_DIV3 ((TARGET_LOONGSON_2EF \
|| TARGET_LOONGSON_3A) \
!TARGET_MIPS16)
Index: gcc/config/mips/mips.md
===
--- gcc/config/mips/mips.md (Revision 199708)
+++ gcc/config/mips/mips.md (Arbeitskopie)
@@ -1481,7 +1481,7 @@
[(set (match_operand:GPR 0 register_operand)
(mult:GPR (match_operand:GPR 1 register_operand)
(match_operand:GPR 2 register_operand)))]
-
+ ISA_HAS_DMULT
{
rtx lo;
@@ -1527,7 +1527,7 @@
{
if (which_alternative == 1)
return dmult\t%1,%2;
- if (MODEmode == SImode TARGET_MIPS3900)
+ if (MODEmode == SImode (TARGET_MIPS3900 || TARGET_MIPS5900))
return mult\t%0,%1,%2;
return dmul\t%0,%1,%2;
}
@@ -1561,7 +1561,7 @@
[(set (match_operand:GPR 0 muldiv_target_operand =l)
(mult:GPR (match_operand:GPR 1 register_operand d)
(match_operand:GPR 2 register_operand d)))]
- !TARGET_FIX_R4000
+ ISA_HAS_DMULT !TARGET_FIX_R4000
dmult\t%1,%2
[(set_attr type imul)
(set_attr mode MODE)])
@@ -1571,7 +1571,7 @@
(mult:GPR (match_operand:GPR 1 register_operand d)
(match_operand:GPR 2 register_operand d)))
(clobber (match_scratch:GPR 3 =l))]
- TARGET_FIX_R4000
+ ISA_HAS_DMULT TARGET_FIX_R4000
dmult\t%1,%2\;mflo\t%0
[(set_attr type imul)
(set_attr mode MODE)
@@ -1992,7 +1992,7 @@
(mult:DI (any_extend:DI (match_operand:SI 1 register_operand))
(any_extend:DI (match_operand:SI 2 register_operand
(clobber (match_operand:DI 3 register_operand))]
-
+ TARGET_64BIT
{
rtx hilo;
@@ -2038,7 +2038,7 @@
(mult:DI (sign_extend:DI (match_operand:SI 1 register_operand d))
(sign_extend:DI (match_operand:SI 2 register_operand d
(clobber (match_scratch:DI 3 =l))]
- TARGET_64BIT ISA_HAS_DMUL3
+ ISA_HAS_DMUL3
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes: Hello Richard, Thanks, looks good. The comments I have are only minor and seemed easier to spell out as a revised patch, attached below. The changes are: * removing the config.sub bit, which looked redundant. We already have the up-to-date upstream config.sub. * removing the target_cpu_default setting. I realise this was taken from mips64-elf, but it was redundant here, there, and elsewhere. I've just committed a patch to remove the existing cases. * removing the TUNE_5900 definition. I prefer not to define these kinds of macro until they're used. * removing the ISA_HAS_LDC1_SDC1 setting. I realise what you did describes the reality of the processor, but the problem is that the patch doesn't provide an alternative for 64-bit loads and stores when -mfp64 is used. That combination also isn't rejected, so we're likely to get an internal compiler error instead. This change shouldn't affect the soft-float case you describe. It also shouldn't be important for the single-float code. * tweaking the mips_reorg_process_insns comment slightly * fixing a few minor formatting issues Does this version look OK to you? I'll commit it if so. This is OK and the generated code is still working on the PS2 in my test run. Thanks, now applied. FWIW, the Cygnus/Red Hat version of the port just stuck with the R5900 behaviour and made GCC understand it (MODE_HAS_* various other bits). This code was then updated and extended for the SPU. I'd have expected the support to be in reasonably good shape because of the SPU. I assume that you mean the cell processor of the PS3 and not the Sound Processing Unit of the PS2. :-) The macros MODE_HAS_* in the GCC look promising. You've probably already seen it, but there's also spu_single_format. Richard
Re: [PATCH] Basic support for MIPS r5900
On 06/02/2013 01:45 PM, Jürgen Urban wrote: Hello, after some months I reworked the patch for r5900. It would be nice if this could be accepted. The patch contains only changes to get basic support for MIPS r5900. It can be used to compile a working Linux kernel for the Playstation 2. It is also possible to get Linux programs working with software floating point and ABI o32. Other stuff like hardware floating point and ABI n32 is not fully supported yet. How much other changes will be currently accepted here? There is other stuff which I want to prepare and submit here, e.g.: 1. disable use of dmult and ddiv (ABI n32). 2. use trunc.w.s instead of cvt.w.s (to get single float working for normal range calculations; i.e. calculating without inf or nan). 3. fix use of ll/sc in libgomp, either increase mips ISA level or use syscall (which is broken in Linux 2.6.35.4). 4. fix libgcc to build a real muldi3 function for ABI n32 (not the multi3 function which is stored in muldi3.o file). 5. add support for configure parameters --float=single and --float=double in addition to --float=soft and --float=hard. 6. rework floating point to support single float with ABI n32 (either break the ABI or store floating point values in general purpose registers like soft float). 7. change libgcc or mips.md in way so that the non IEEE 754 compatible FPU of the r5900 gets compatible. I'd like those more regularly working on the MIPS backend to chime in on final approval. However, it looks reasonable to me. jeff
Re: [PATCH] Basic support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes:
after some months I reworked the patch for r5900. It would be nice if
this could be accepted. The patch contains only changes to get basic
support for MIPS r5900. It can be used to compile a working Linux kernel
for the Playstation 2. It is also possible to get Linux programs working
with software floating point and ABI o32. Other stuff like hardware
floating point and ABI n32 is not fully supported yet.
Thanks, looks good. The comments I have are only minor and seemed easier
to spell out as a revised patch, attached below. The changes are:
* removing the config.sub bit, which looked redundant. We already have
the up-to-date upstream config.sub.
* removing the target_cpu_default setting. I realise this was taken
from mips64-elf, but it was redundant here, there, and elsewhere.
I've just committed a patch to remove the existing cases.
* removing the TUNE_5900 definition. I prefer not to define these
kinds of macro until they're used.
* removing the ISA_HAS_LDC1_SDC1 setting. I realise what you did
describes the reality of the processor, but the problem is that
the patch doesn't provide an alternative for 64-bit loads and
stores when -mfp64 is used. That combination also isn't rejected,
so we're likely to get an internal compiler error instead.
This change shouldn't affect the soft-float case you describe.
It also shouldn't be important for the single-float code.
* tweaking the mips_reorg_process_insns comment slightly
* fixing a few minor formatting issues
Does this version look OK to you? I'll commit it if so.
How much other changes will be currently accepted here? There is other
stuff which I want to prepare and submit here, e.g.:
1. disable use of dmult and ddiv (ABI n32).
2. use trunc.w.s instead of cvt.w.s (to get single float working for
normal range calculations; i.e. calculating without inf or nan).
3. fix use of ll/sc in libgomp, either increase mips ISA level or use
syscall (which is broken in Linux 2.6.35.4).
4. fix libgcc to build a real muldi3 function for ABI n32 (not the
multi3 function which is stored in muldi3.o file).
5. add support for configure parameters --float=single and
--float=double in addition to --float=soft and --float=hard.
6. rework floating point to support single float with ABI n32 (either
break the ABI or store floating point values in general purpose
registers like soft float).
7. change libgcc or mips.md in way so that the non IEEE 754 compatible
FPU of the r5900 gets compatible.
Well, I'm afraid that's hard to say in advance. It really depends
on what the changes look like. (1) and (2) sound harmless enough,
although (1) should probably only be done in conjunction with (4).
I'm not sure what (3) involves. (5) sounds like a good idea.
(6) is worth doing, but anything ABI-related gets extra-paranoid
treatment. :-)
I'm not sure about (7) though. I'd imagine trying to get true IEEE
conformance out of the R5900 FPU would be pretty difficult and carry
quite a bit of runtime overhead, especially with the subnormal handling.
Is it really worth it? Do you have any particular use cases in mind?
FWIW, the Cygnus/Red Hat version of the port just stuck with the R5900
behaviour and made GCC understand it (MODE_HAS_* various other bits).
This code was then updated and extended for the SPU. I'd have expected
the support to be in reasonably good shape because of the SPU.
Thanks,
Richard
gcc/
2013-06-03 Jürgen Urban juergenur...@gmx.de
* config.gcc (mipsr5900-*-elf*, mipsr5900el-*-elf*, mips64r5900-*-elf*)
(mips64r5900el-*-elf*): New configurations.
* config/mips/mips-cpus.def (r5900): New processor.
* config/mips/mips-tables.opt: Regenerate.
* config/mips/mips.c (mips_rtx_cost_data): Add an R5900 entry.
(mips_issue_rate): Handle PROCESSOR_R5900.
(mips_reorg_process_insns): Force reorder mode for the R5900.
* config/mips/mips.h (TARGET_MIPS5900): Define.
(ISA_HAS_CONDMOVE, ISA_HAS_PREFETCH, ISA_HAS_HILO_INTERLOCKS): Include
TARGET_MIPS5900.
(ISA_HAS_LOAD_DELAY, ISA_HAS_XFER_DELAY, ISA_HAS_FCMP_DELAY): Exclude
TARGET_MIPS5900.
* config/mips/mips.md (processor): Add r5900.
(MOVECC): Disallow CCmode conditions for TARGET_MIPS5900.
libgcc/
2013-06-03 Jürgen Urban juergenur...@gmx.de
* config.host (mipsr5900-*-elf*, mipsr5900el-*-elf*, mips64r5900-*-elf*)
(mips64r5900el-*-elf*): New configurations.
Index: gcc/config.gcc
===
--- gcc/config.gcc 2013-06-03 20:28:18.959933736 +0100
+++ gcc/config.gcc 2013-06-03 20:30:19.110139050 +0100
@@ -1935,10 +1935,15 @@ mipsisa64sb1-*-elf* | mipsisa64sb1el-*-e
tmake_file=mips/t-elf mips/t-sb1
tm_defines=${tm_defines} MIPS_ISA_DEFAULT=64
MIPS_CPU_STRING_DEFAULT=\\\sb1\\\ MIPS_ABI_DEFAULT=ABI_O64
;;
-mips-*-elf
Re: [PATCH] Basic support for MIPS r5900
Hello Richard, Thanks, looks good. The comments I have are only minor and seemed easier to spell out as a revised patch, attached below. The changes are: * removing the config.sub bit, which looked redundant. We already have the up-to-date upstream config.sub. * removing the target_cpu_default setting. I realise this was taken from mips64-elf, but it was redundant here, there, and elsewhere. I've just committed a patch to remove the existing cases. * removing the TUNE_5900 definition. I prefer not to define these kinds of macro until they're used. * removing the ISA_HAS_LDC1_SDC1 setting. I realise what you did describes the reality of the processor, but the problem is that the patch doesn't provide an alternative for 64-bit loads and stores when -mfp64 is used. That combination also isn't rejected, so we're likely to get an internal compiler error instead. This change shouldn't affect the soft-float case you describe. It also shouldn't be important for the single-float code. * tweaking the mips_reorg_process_insns comment slightly * fixing a few minor formatting issues Does this version look OK to you? I'll commit it if so. This is OK and the generated code is still working on the PS2 in my test run. How much other changes will be currently accepted here? There is other stuff which I want to prepare and submit here, e.g.: 1. disable use of dmult and ddiv (ABI n32). 2. use trunc.w.s instead of cvt.w.s (to get single float working for normal range calculations; i.e. calculating without inf or nan). 3. fix use of ll/sc in libgomp, either increase mips ISA level or use syscall (which is broken in Linux 2.6.35.4). 4. fix libgcc to build a real muldi3 function for ABI n32 (not the multi3 function which is stored in muldi3.o file). 5. add support for configure parameters --float=single and --float=double in addition to --float=soft and --float=hard. 6. rework floating point to support single float with ABI n32 (either break the ABI or store floating point values in general purpose registers like soft float). 7. change libgcc or mips.md in way so that the non IEEE 754 compatible FPU of the r5900 gets compatible. Well, I'm afraid that's hard to say in advance. It really depends on what the changes look like. (1) and (2) sound harmless enough, although (1) should probably only be done in conjunction with (4). I'm not sure what (3) involves. (5) sounds like a good idea. (6) is worth doing, but anything ABI-related gets extra-paranoid treatment. :-) I'm not sure about (7) though. I'd imagine trying to get true IEEE conformance out of the R5900 FPU would be pretty difficult and carry quite a bit of runtime overhead, especially with the subnormal handling. Is it really worth it? Do you have any particular use cases in mind? My target was to get existing C programs working (e.g. all mipsel programs from Debian 5 or 6, all mips64el programs from Fedora 12 or 13). The programs should work like programs on normal mipsel or mips64el Linux. I don't know what in the different programs is used. FWIW, the Cygnus/Red Hat version of the port just stuck with the R5900 behaviour and made GCC understand it (MODE_HAS_* various other bits). This code was then updated and extended for the SPU. I'd have expected the support to be in reasonably good shape because of the SPU. I assume that you mean the cell processor of the PS3 and not the Sound Processing Unit of the PS2. The macros MODE_HAS_* in the GCC look promising. Best regards Jürgen
[PATCH] Basic support for MIPS r5900
Hello,
after some months I reworked the patch for r5900. It would be nice if this
could be accepted. The patch contains only changes to get basic support for
MIPS r5900. It can be used to compile a working Linux kernel for the
Playstation 2. It is also possible to get Linux programs working with software
floating point and ABI o32. Other stuff like hardware floating point and ABI
n32 is not fully supported yet.
How much other changes will be currently accepted here? There is other stuff
which I want to prepare and submit here, e.g.:
1. disable use of dmult and ddiv (ABI n32).
2. use trunc.w.s instead of cvt.w.s (to get single float working for normal
range calculations; i.e. calculating without inf or nan).
3. fix use of ll/sc in libgomp, either increase mips ISA level or use syscall
(which is broken in Linux 2.6.35.4).
4. fix libgcc to build a real muldi3 function for ABI n32 (not the multi3
function which is stored in muldi3.o file).
5. add support for configure parameters --float=single and --float=double in
addition to --float=soft and --float=hard.
6. rework floating point to support single float with ABI n32 (either break the
ABI or store floating point values in general purpose registers like soft
float).
7. change libgcc or mips.md in way so that the non IEEE 754 compatible FPU of
the r5900 gets compatible.
Best regards
Jürgen--- gcc/libgcc/config.host (Revision 199343)
+++ gcc/libgcc/config.host (Arbeitskopie)
@@ -739,7 +739,17 @@
;;
mips*-*-linux*)# Linux MIPS, either endian.
extra_parts=$extra_parts crtfastmath.o
- tmake_file=${tmake_file} t-crtfm mips/t-mips16
+ tmake_file=${tmake_file} t-crtfm
+ # Check for MicroMIPS support.
+ case ${host} in
+ mips64r5900* | mipsr5900*)
+ # MicroMIPS uses floating point instructions
+ # which are not supported on r5900.
+ ;;
+ *)
+ tmake_file=${tmake_file} mips/t-mips16
+ ;;
+ esac
md_unwind_header=mips/linux-unwind.h
if test ${ac_cv_sizeof_long_double} = 16; then
tmake_file=${tmake_file} mips/t-tpbit
@@ -777,10 +787,18 @@
tmake_file=$tmake_file mips/t-elf mips/t-crtstuff mips/t-mips16
extra_parts=$extra_parts crti.o crtn.o
;;
+mipsr5900-*-elf* | mipsr5900el-*-elf*)
+ tmake_file=$tmake_file mips/t-elf mips/t-crtstuff
+ extra_parts=$extra_parts crti.o crtn.o
+ ;;
mips64-*-elf* | mips64el-*-elf*)
tmake_file=$tmake_file mips/t-elf mips/t-crtstuff mips/t-mips16
extra_parts=$extra_parts crti.o crtn.o
;;
+mips64r5900-*-elf* | mips64r5900el-*-elf*)
+ tmake_file=$tmake_file mips/t-elf mips/t-crtstuff
+ extra_parts=$extra_parts crti.o crtn.o
+ ;;
mips64vr-*-elf* | mips64vrel-*-elf*)
tmake_file=$tmake_file mips/t-elf mips/t-vr mips/t-crtstuff
extra_parts=$extra_parts crti.o crtn.o
--- gcc/gcc/config.gcc (Revision 199343)
+++ gcc/gcc/config.gcc (Arbeitskopie)
@@ -1937,10 +1937,16 @@
target_cpu_default=MASK_64BIT|MASK_FLOAT64
tm_defines=${tm_defines} MIPS_ISA_DEFAULT=64 MIPS_CPU_STRING_DEFAULT=\\\sb1\\\ MIPS_ABI_DEFAULT=ABI_O64
;;
-mips-*-elf* | mipsel-*-elf*)
+mips-*-elf* | mipsel-*-elf* | mipsr5900-*-elf* | mipsr5900el-*-elf*)
tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h
tmake_file=mips/t-elf
;;
+mips64r5900-*-elf* | mips64r5900el-*-elf*)
+ tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h
+ tmake_file=mips/t-elf
+ target_cpu_default=MASK_64BIT
+ tm_defines=${tm_defines} MIPS_ISA_DEFAULT=3 MIPS_ABI_DEFAULT=ABI_N32
+ ;;
mips64-*-elf* | mips64el-*-elf*)
tm_file=elfos.h newlib-stdint.h ${tm_file} mips/elf.h
tmake_file=mips/t-elf
@@ -2973,6 +2979,19 @@
;;
esac
;;
+mips64r5900-*-*|mips64r5900el-*-*|mipsr5900-*-*|mipsr5900el-*-*)
+ with_arch=r5900
+ with_tune=r5900
+ if test x$with_llsc = x; then
+ # r5900 doesn't support ll, sc, lld and scd instructions:
+ with_llsc=no
+ fi
+ if test x$with_float = x; then
+ # r5900 doesn't support 64 bit float:
+ # 32 bit float doesn't comply with IEEE 754.
+ with_float=soft
+ fi
+ ;;
mips*-*-vxworks)
with_arch=mips2
;;
--- gcc/gcc/config/mips/mips.c (Revision 199343)
+++ gcc/gcc/config/mips/mips.c (Arbeitskopie)
@@ -1029,6 +1029,19 @@
1, /* branch_cost */
4/* memory_latency */
},
+ { /* R5900 */
+COSTS_N_INSNS (4),/* fp_add */
+COSTS_N_INSNS (4),/* fp_mult_sf */
+COSTS_N_INSNS (256), /* fp_mult_df */
+COSTS_N_INSNS (8),/* fp_div_sf */
+COSTS_N_INSNS (256), /* fp_div_df */
+COSTS_N_INSNS (4),/* int_mult_si */
+COSTS_N_INSNS (256), /* int_mult_di */
+COSTS_N_INSNS (37), /* int_div_si */
+COSTS_N_INSNS (256), /* int_div_di */
+ 1, /* branch_cost */
+ 4/* memory_latency */
+ },
{ /* R7000 */
/* The only costs that are changed here are
integer multiplication. */
@@ -13005,6 +13018,7 @@
case PROCESSOR_R4130:
case PROCESSOR_R5400:
case PROCESSOR_R5500
Re: Support for MIPS r5900
Hello Maciej, I tested the calculation with the type float. ABI o32 with -mhard-float and -msingle-float produces the following results: 1.00 (0x3f80) / 0.00 (0x) = nan (0x7fff) 0.00 (0x) / 0.00 (0x) = nan (0x7fff) 0.00 (0x) / nan (0x7fc0) = 0.00 (0x) 1.00 (0x3f80) + 1.00 (0x3f80) = 2.00 (0x4000) 1.00 (0x3f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + inf (0x7f80) = nan (0x7fff) inf (0x7f80) + -inf (0xff80) = 0.00 (0x) nan (0x7fc0) + nan (0x7fc0) = nan (0x7fff) nan (0x7fc0) + nan (0xffc0) = 0.00 (0x) The r5900 manual calls the result of 0/0 Fmax. So 0x7fff seems to be Fmax. So presumably you can get 0x7fff as an arithmetic result of a calculation involving regular numbers as well, right? Say 0x7f7e + 0x7400 (using the binary-encoded notation)? That would be beyond the IEEE-754 single range. The FPU of the r5900 calculates the following: 340282306073709652508363335590014353408.00 (0x7f7d) + 40564819207303340847894502572032.00 (0x7400) = 340282346638528859811704183484516925440.00 (0x7f7f) 340282326356119256160033759537265639424.00 (0x7f7e) + 40564819207303340847894502572032.00 (0x7400) = inf (0x7f80) 340282346638528859811704183484516925440.00 (0x7f7f) + 40564819207303340847894502572032.00 (0x7400) = inf (0x7f80) inf (0x7f80) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7f81) nan (0x7f81) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7f82) nan (0x7f90) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7f91) nan (0x7f91) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7f92) nan (0x7ff1) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7ff2) nan (0x7ffc) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7ffd) nan (0x7ffd) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7ffe) nan (0x7ffe) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7fff) nan (0x7fff) + 40564819207303340847894502572032.00 (0x7400) = nan (0x7fff) So it seems that it interprets nan and inf as normal numbers, but it stops at 0x7fff. So 0x7fff should be interpreted as overflow. Best regards Jürgen
Re: Support for MIPS r5900
Maciej W. Rozycki ma...@codesourcery.com writes: I tested the calculation with the type float. ABI o32 with -mhard-float and -msingle-float produces the following results: 1.00 (0x3f80) / 0.00 (0x) = nan (0x7fff) 0.00 (0x) / 0.00 (0x) = nan (0x7fff) 0.00 (0x) / nan (0x7fc0) = 0.00 (0x) 1.00 (0x3f80) + 1.00 (0x3f80) = 2.00 (0x4000) 1.00 (0x3f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + inf (0x7f80) = nan (0x7fff) inf (0x7f80) + -inf (0xff80) = 0.00 (0x) nan (0x7fc0) + nan (0x7fc0) = nan (0x7fff) nan (0x7fc0) + nan (0xffc0) = 0.00 (0x) The r5900 manual calls the result of 0/0 Fmax. So 0x7fff seems to be Fmax. So presumably you can get 0x7fff as an arithmetic result of a calculation involving regular numbers as well, right? Say 0x7f7e + 0x7400 (using the binary-encoded notation)? That would be beyond the IEEE-754 single range. Yeah, if I recall correctly. We already support what I think is the same format for SPU (spu_single_format), which I suppose makes sense given its heritage. Hopefully the format itself won't need much work in GCC. Richard
Re: Support for MIPS r5900
Hello Maciej, Please note that the issue of LLD and SCD remains open -- these instructions are a part of the base MIPS III 64-bit ISA and therefore they are assumed by glibc and elsewhere to be present, and they are not emulated by Linux. So not only you'll have to fix up glibc to surround their use with .set mips3 for the n64 and n32 ABIs (please note that .set mips3 is needed for LL and SC for these ABIs as well to avoid a miscalculation of addresses where applicable), but you'll have to add emulation code to Linux as well. I didn't see any code yet that uses lld/scd, so it doesn't seem to be a problem. I will create a patch which includes tests that will ensure that .set mips3 will work. Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit data type is involved. Of course that also requires a 64-bit ABI, either n64 or n32, as these are 64-bit instructions -- from what you wrote thus far I've gathered, perhaps incorrectly, that you've been using either or both too, in addition to o32 -- is my understanding correct? I used o32 and n32 for Linux programs and with the OS of the PS2. I tried to use o64 for the Linux kernel, but I've got problems with the 64 bit TLBs and that the type long is used for pointers, so I decided to use the o32 kernel which was patched to support n32 user space. I never tried n64. I was not able to find an option to enable n64 in the gcc 4.3 (I mean more than -mabi=n64; i.e. multilib). How are unsupported floating-point data treated, BTW -- what results does the processor produce for floating-point encodings that would normally be interpreted as not-a-number, an infinity or a denormalised number? Are they treated numerically, beyond the range IEEE-754 single provides? You say that the Invalid Operation exception is not raised, so they cannot be trapped and emulated. The manual says that the traps can be emulated by a conditional trap instructions. I saw such code before, but I can't remember if this was x86, ARM, mipsel or r5900. I tested the calculation with the type float. ABI o32 with -mhard-float and -msingle-float produces the following results: 1.00 (0x3f80) / 0.00 (0x) = nan (0x7fff) 0.00 (0x) / 0.00 (0x) = nan (0x7fff) 0.00 (0x) / nan (0x7fc0) = 0.00 (0x) 1.00 (0x3f80) + 1.00 (0x3f80) = 2.00 (0x4000) 1.00 (0x3f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + inf (0x7f80) = nan (0x7fff) inf (0x7f80) + -inf (0xff80) = 0.00 (0x) nan (0x7fc0) + nan (0x7fc0) = nan (0x7fff) nan (0x7fc0) + nan (0xffc0) = 0.00 (0x) The r5900 manual calls the result of 0/0 Fmax. So 0x7fff seems to be Fmax. ABI n32 with -msoft-float and -mdouble-float produces the following results (this should be correct): 1.00 (0x3f80) / 0.00 (0x) = inf (0x7f80) 0.00 (0x) / 0.00 (0x) = nan (0x7f8f) 0.00 (0x) / nan (0x7fc0) = nan (0x7fcf) 1.00 (0x3f80) + 1.00 (0x3f80) = 2.00 (0x4000) 1.00 (0x3f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + -inf (0xff80) = nan (0x7f8f) nan (0x7fc0) + nan (0x7fc0) = nan (0x7fcf) nan (0x7fc0) + nan (0xffc0) = nan (0x7fcf) Just for comparison: x86_64, Intel(R) Core(TM) i7-2600 CPU 1.00 (0x3f80) / 0.00 (0x) = inf (0x7f80) 0.00 (0x) / 0.00 (0x) = -nan (0xffc0) 0.00 (0x) / nan (0x7fc0) = nan (0x7fc0) 1.00 (0x3f80) + 1.00 (0x3f80) = 2.00 (0x4000) 1.00 (0x3f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + inf (0x7f80) = inf (0x7f80) inf (0x7f80) + -inf (0xff80) = -nan (0xffc0) nan (0x7fc0) + nan (0x7fc0) = nan (0x7fc0) nan (0x7fc0) + -nan (0xffc0) = -nan (0xffc0) Here is some information from the EE core user's manual regarding FPU: This unit is not IEEE 754 compatible. Supports single-precision format as defined in the IEEE 754 specification. Plus/Minus 0 in line with IEEE 754 specification are supported. NaNs and plus/minus infinities are not supported. No hardware exception mechanism to affect instruction execution. The FPU only supports Rounding towards 0. ... the results may differ from the IEEE 754 Rounding to 0. This difference is usually restricted to the least significant bit only. NaN, +inf, -inf and denormalized numbers are not supported The FPU does not use the Guard, Round and Sticky bits during computations. Invalid Operation exceptions due to NaN, +/-inf and Inexact exceptions are not supported. Operations with different results: - 0/0 - Sqrt (negative number) - Division by zero
Re: Support for MIPS r5900
Hi Jürgen,
Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit
data type is involved. Of course that also requires a 64-bit ABI, either
n64 or n32, as these are 64-bit instructions -- from what you wrote thus
far I've gathered, perhaps incorrectly, that you've been using either or
both too, in addition to o32 -- is my understanding correct?
I used o32 and n32 for Linux programs and with the OS of the PS2. I
tried to use o64 for the Linux kernel, but I've got problems with the 64
bit TLBs and that the type long is used for pointers, so I decided to
use the o32 kernel which was patched to support n32 user space. I never
tried n64. I was not able to find an option to enable n64 in the gcc 4.3
(I mean more than -mabi=n64; i.e. multilib).
Well, -mabi= is exactly the option that switches between the three ABIs
supported under Linux. The o64 ABI is not supported with Linux, neither
for userland programs nor for building the kernel.
The kernel can be built either for 32-bit or for 64-bit support. In the
former case the resulting binary is o32 and can only run o32 user
programs. In the latter case the kernel binary is n64 and can run n64
user programs, and can optionally be configured to run either or both o32
and n32 user programs as well.
Of course to be able to build and run user programs for the respective
ABIs you need to have the right development environment and shared
libraries installed.
For 32-bit systems it's easy as you only have one ABI to choose from.
The mips-unknown-linux-gnu and mipsel-unknown-linux-gnu targets are the
canonical configuration triplets to configure all the pieces for, starting
from binutils and GCC, for the big and the little endianness respectively.
That'll build an o32 development environment.
For 64-bit systems all the three ABIs are supported so it gets a tad more
complicated. The mips64-unknown-linux-gnu mips64el-unknown-linux-gnu
targets are the canonical configuration triplets here and that'll build
binutils and GCC that support all the three ABIs. Then the compiler
chooses among them by using different library paths -- there are multiple
of them for each of the ABIs supported, but the rule of thumb is the
actual directories where the libraries are located in is called lib for
the n32 ABI, lib64 for the n64 ABI and lib32 for the o32 ABI. You
need to take that into account and set the correct library path -- e.g.
with --libdir=\${exec_prefix}/lib64 for GNU autoconf scripts and the n64
ABI -- when building further libraries as they are not normally
automatically built for all the three ABIs. Of course you then need to
include -mabi=n64 among CFLAGS somewhere too.
How are unsupported floating-point data treated, BTW -- what results does
the processor produce for floating-point encodings that would normally be
interpreted as not-a-number, an infinity or a denormalised number? Are
they treated numerically, beyond the range IEEE-754 single provides? You
say that the Invalid Operation exception is not raised, so they cannot be
trapped and emulated.
The manual says that the traps can be emulated by a conditional trap
instructions. I saw such code before, but I can't remember if this was x86,
ARM, mipsel or r5900.
Yeah, but then you'd have to put these explicit trap instructions
througout code somehow -- it's not like the affected floating-point
instructions are going to trap themselves as expected.
I tested the calculation with the type float.
ABI o32 with -mhard-float and -msingle-float produces the following results:
1.00 (0x3f80) / 0.00 (0x) = nan (0x7fff)
0.00 (0x) / 0.00 (0x) = nan (0x7fff)
0.00 (0x) / nan (0x7fc0) = 0.00 (0x)
1.00 (0x3f80) + 1.00 (0x3f80) = 2.00 (0x4000)
1.00 (0x3f80) + inf (0x7f80) = inf (0x7f80)
inf (0x7f80) + inf (0x7f80) = nan (0x7fff)
inf (0x7f80) + -inf (0xff80) = 0.00 (0x)
nan (0x7fc0) + nan (0x7fc0) = nan (0x7fff)
nan (0x7fc0) + nan (0xffc0) = 0.00 (0x)
The r5900 manual calls the result of 0/0 Fmax. So 0x7fff seems to be Fmax.
So presumably you can get 0x7fff as an arithmetic result of a
calculation involving regular numbers as well, right? Say 0x7f7e +
0x7400 (using the binary-encoded notation)? That would be beyond the
IEEE-754 single range.
OK, I guess you could still make it a supported processing unit with GCC,
however I can't speak for GCC maintainers as to whether they would be
willing to accept such support for inclusion. Both ISO C and GCC do
permit non-IEEE-754 floating point arithmetic (cf. VAX, that does not
support qNaNs, infinities or denormals; sNaNs in a sense are supported).
You'd probably have to bail out on sources referring to unsupported
features, e.g. __builtin_inf; I
Re: Support for MIPS r5900
Hi Jürgen, Now if that failed for you, then it's a plain bug in GAS that should be fixed. Can you therefore check whether a piece like: .setmips2 ll $2, ($3) assembles correctly with -march=r5900? This seems to work. I didn't know that this would work. I thought it would never be possible to generate ll and sc. Excellent, I hoped that it would work as we've been using these overrides for years, except that usually they are used to tweak the ISA selected rather than a specific CPU (with -march= you can request either an ISA or a CPU). Your case is the first I've personally encountered where the CPU selected needs an override, so I'm glad that it just works. Please note that the issue of LLD and SCD remains open -- these instructions are a part of the base MIPS III 64-bit ISA and therefore they are assumed by glibc and elsewhere to be present, and they are not emulated by Linux. So not only you'll have to fix up glibc to surround their use with .set mips3 for the n64 and n32 ABIs (please note that .set mips3 is needed for LL and SC for these ABIs as well to avoid a miscalculation of addresses where applicable), but you'll have to add emulation code to Linux as well. I didn't see any code yet that uses lld/scd, so it doesn't seem to be a problem. I will create a patch which includes tests that will ensure that .set mips3 will work. Glibc uses them exactly where it uses 32-bit LL/SC, except where a 64-bit data type is involved. Of course that also requires a 64-bit ABI, either n64 or n32, as these are 64-bit instructions -- from what you wrote thus far I've gathered, perhaps incorrectly, that you've been using either or both too, in addition to o32 -- is my understanding correct? There are even more problems when running unchanged code from official Fedora 12 on PS2, because of some different opcode encoding. The users of my PS2 Linux 2.6 complain about low speed, because many instructions are emulated. I need some fast implementation, even if the size of the floating point data types is smaller. So 32 bit FPU must be default for r5900. That sounds weird -- why would anyone want to use a non-standard encoding for any instructions? The base MIPS III 64-bit ISA was set as far back as in 1991. Is R5900 documentation publicly available BTW? The documentation for r5900 is available on the first DVD of Sony's Linux Toolkit and in the SDK for the PS2 which is only available for people which I would call verified Sony customers. OK, I see, so not really public, sigh... The TX79 core is similar to the r5900: http://www.lukasz.dk/files/tx79architecture.pdf But the TX79 has a 64 Bit FPU, so there are no real problems with opcode encoding. This document also says that mips isa III is supported, but not ll,sc,lld,scd,dmult and ddiv. In binutils/opcodes/mips-opc.c you can see the different opcode encoding for c.lt.s and trunc.w.s, the missing c.olt.s and cvt.w.s instructions. These are caused by the FPU. This is no problem on the TX79. Oh well, missing instructions are not that much of a problem, they can always be emulated. Instruction words that implement operation different to one expected are a show-stopper though. I see that the encodings supposed to implement C.OLT.S and C.OLE.S are interpreted as C.LT.S and C.LE.S, respectively. However the former instructions differ from the latters only in how quiet NaNs are treated. Given that, as you say, the processor does not support NaNs anyway, this may well be considered correct operation. You may still need to emulate the other encoding though. How are unsupported floating-point data treated, BTW -- what results does the processor produce for floating-point encodings that would normally be interpreted as not-a-number, an infinity or a denormalised number? Are they treated numerically, beyond the range IEEE-754 single provides? You say that the Invalid Operation exception is not raised, so they cannot be trapped and emulated. For Fedora 12 I need to disable the FPU and emulate everything. Well, given the lack of full IEEE-754 support you'll always have to do that for generic MIPS code. The kernel could interpret E_MIPS_MACH_5900 set in the ELF file header flags though and enable the FPU selectively for compatible binaries. Such binaries might produce computational results different to expected of course. You'd have to enforce object-file compatibility though and make sure R5900 binaries do not run with the FPU enabled on other hardware too. That might be an interesting project if you'd like to dive into it. One of the biggest problem is that most Linux programs use the rdhwr instruction (0x7c03e83b). I don't know any MIPS CPU which supports this instruction. Oh, pretty much all modern MIPS processors do -- this instruction has been mandatory since the introduction of the MIPS32r2 and
Re: Support for MIPS r5900
Hello Maciej, Now if that failed for you, then it's a plain bug in GAS that should be fixed. Can you therefore check whether a piece like: .setmips2 ll $2, ($3) assembles correctly with -march=r5900? This seems to work. I didn't know that this would work. I thought it would never be possible to generate ll and sc. Please note that the issue of LLD and SCD remains open -- these instructions are a part of the base MIPS III 64-bit ISA and therefore they are assumed by glibc and elsewhere to be present, and they are not emulated by Linux. So not only you'll have to fix up glibc to surround their use with .set mips3 for the n64 and n32 ABIs (please note that .set mips3 is needed for LL and SC for these ABIs as well to avoid a miscalculation of addresses where applicable), but you'll have to add emulation code to Linux as well. I didn't see any code yet that uses lld/scd, so it doesn't seem to be a problem. I will create a patch which includes tests that will ensure that .set mips3 will work. So the FPU needs to be disabled and completely emulated by the kernel, because then all FPU instructions lead to an exception. This is working with Linux 2.6 on PS2. Naturally, as long as they got the Coprocessor Unusable exception right. Yes, this exception is also working for instructions with undefined behavior. There are even more problems when running unchanged code from official Fedora 12 on PS2, because of some different opcode encoding. The users of my PS2 Linux 2.6 complain about low speed, because many instructions are emulated. I need some fast implementation, even if the size of the floating point data types is smaller. So 32 bit FPU must be default for r5900. That sounds weird -- why would anyone want to use a non-standard encoding for any instructions? The base MIPS III 64-bit ISA was set as far back as in 1991. Is R5900 documentation publicly available BTW? The documentation for r5900 is available on the first DVD of Sony's Linux Toolkit and in the SDK for the PS2 which is only available for people which I would call verified Sony customers. The TX79 core is similar to the r5900: http://www.lukasz.dk/files/tx79architecture.pdf But the TX79 has a 64 Bit FPU, so there are no real problems with opcode encoding. This document also says that mips isa III is supported, but not ll,sc,lld,scd,dmult and ddiv. In binutils/opcodes/mips-opc.c you can see the different opcode encoding for c.lt.s and trunc.w.s, the missing c.olt.s and cvt.w.s instructions. These are caused by the FPU. This is no problem on the TX79. For Fedora 12 I need to disable the FPU and emulate everything. One of the biggest problem is that most Linux programs use the rdhwr instruction (0x7c03e83b). I don't know any MIPS CPU which supports this instruction. This has the same encoding as the sq v1,-6085(zero) instruction on the r5900. Luckily this always leads to an alignment exception which is handled correctly by my Linux kernel to emulate rdhwr. Here is some information from the EE core user's manual regarding FPU: This unit is not IEEE 754 compatible. Supports single-precision format as defined in the IEEE 754 specification. Plus/Minus 0 in line with IEEE 754 specification are supported. NaNs and plus/minus infinities are not supported. No hardware exception mechanism to affect instruction execution. The FPU only supports Rounding towards 0. ... the results may differ from the IEEE 754 Rounding to 0. This difference is usually restricted to the least significant bit only. NaN, +inf, -inf and denormalized numbers are not supported The FPU does not use the Guard, Round and Sticky bits during computations. Invalid Operation exceptions due to NaN, +/-inf and Inexact exceptions are not supported. Operations with different results: - 0/0 - Sqrt (negative number) - Division by zero - Exponent overflow - Exponent underflow - Conversion of Floating-point to Integer Overflow Best regards Jürgen
Re: Support for MIPS r5900
Maciej W. Rozycki ma...@codesourcery.com writes: And in any case I insist that the instructions are correctly marked in the opcode table. I agree that it would be better to exclude the unimplemented instructions. Jürgen: if you're happy to submit a patch along those lines, I promise to review it. BTW Maciej, sorry to be prickly about this, but: where I live, I insist has a very domineering ring to it, at least in this kind of context. The implication tends to be that having insisted, I really expect it to happen, simply because it is _I_ who insisted. Maybe it's not the same everywhere though. Richard
Re: Support for MIPS r5900
On Fri, 11 Jan 2013, Richard Sandiford wrote: BTW Maciej, sorry to be prickly about this, but: where I live, I insist has a very domineering ring to it, at least in this kind of context. The implication tends to be that having insisted, I really expect it to happen, simply because it is _I_ who insisted. Maybe it's not the same everywhere though. That's probably a shortcoming of my English skills -- sorry about that -- I didn't want to sound impolite or to insult anyone, especially you, Jürgen. Your contribution is very welcome even if there are minor issues there or some design decisions are not immediately obvious to everyone. Please feel free to disagree or argue if you think any opinion expressed does not convince you. Maciej
Re: Support for MIPS r5900
Hello Jeff, If you're using something from the Cygnus port, then it would be covered by the blanket copyright assignment Cygnus had in place with the FSF. If there are any doubts about the origin of a hunk of GCC code I could probably pull out the old sources to determine if it came from Cygnus's code base or not. Can you please tell me whether the following lines of the patches are covered by the blanket copyright assignment? Lines 335-533 of GCC patch (mips_r5900_lengthen_loops()): http://pastie.org/5664783 Lines 410-565 and 581-589 of binutils patch (check_short_loop()): http://pastie.org/5664824 The patches are from the second DVD of Sony's Linux Toolkit for the PS2. Best regards Jürgen
Re: Support for MIPS r5900
Jürgen, Adding the binutils list as more appropriate for some concerns discussed here. ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. This has raised my attention -- AFAICS the binutils change recently approved correctly disables DMULT, DDIV, CVT.W.S, etc. for -march=r5900, but does not do that for LL or SC. I think that should be fixed. And I gather LLD and SCD should then be disabled as well. The glibc can only be compiled with support for ll and sc. The Linux kernel successfully emulates these instructions. When compiling GCC for mips*r5900*-elf (i.e. not Linux), the instructions ll/sc and lld/scd are disabled by my patch. That a particular OS emulates some instructions in software does not necessarily make them a part of the architecture. GAS needs to support any target environment, including bare iron, and as such should closely match the hardware implementation. I think the right place to address it is glibc. The library can be built for the base MIPS I ISA that did not have LL or SC instructions either and therefore already has some provisions in place to override the processor/ISA selection for the code fragments in question so that the instructions otherwise missing from the target hardware selected are nevertheless assembled successfully. This is currently enabled for the o32 ABI, where .set mips2 is used to enable the assembly of LL and SC. Now if that failed for you, then it's a plain bug in GAS that should be fixed. Can you therefore check whether a piece like: .setmips2 ll $2, ($3) assembles correctly with -march=r5900? Please note that the issue of LLD and SCD remains open -- these instructions are a part of the base MIPS III 64-bit ISA and therefore they are assumed by glibc and elsewhere to be present, and they are not emulated by Linux. So not only you'll have to fix up glibc to surround their use with .set mips3 for the n64 and n32 ABIs (please note that .set mips3 is needed for LL and SC for these ABIs as well to avoid a miscalculation of addresses where applicable), but you'll have to add emulation code to Linux as well. And in any case I insist that the instructions are correctly marked in the opcode table. Things would get more complicated if one wanted to run a real OS such as Linux on the R5900 and let the kernel FP emulator handle the missing double FP automagically -- this is a little bit out of scope here as regular -mdouble-float would then just do, but makes me wonder whether -mfp32 should really be enforced (as opposed to just defaulted) for the R5900, hmm... I tried to emulate the 64 Bit FPU when the real 32 Bit FPU was enabled in Linux. There are 2 problems with this: 1. When the program starts, I don't know if it needs a 64 Bit or 32 Bit FPRs. So registers are initialized for 32 bit. When dmfc0 or dmtc0 appears, I need to emulate them using 32 Bit FPU, because some 32 bit programs use these instructions with a 32 Bit FPU (e.g. Linux 2.6.35 kernel and Debian 5.0). When a 64 bit calculation instructions appears, I need to switch from 32 bit FPRs to 64 bit FPRs. When the program used 32 bit instructions with the odd FPRs, there is no way to reconstruct the overwritten part of the 64 bit FPRs. The mode of the FPU is determined by the ABI -- o32 programs use the 32-bit configuration (CP0.Status.FR set to 0) and n64/n32 programs use the 64-bit arrangement (CP0.Status.FR set to 1). That's already handled correctly by the kernel, by configuring the FPU on a process-by-process basis according to data obtained from the ELF file header of the executable run. Of course all double arithmetic would have to be handled by the emulator, by trapping the Unimplemented Operation exception. This would clearly be a new mode of operation and not supported out of the box with current code as that would have to be tweaked to handle the case where only half the register state is stored in hardware. 2. Some undefined instructions (e.g. c.eq.d) doesn't lead to an exception on an r5900, but have undefined behavior. So there is no emulation possible. It just calculates random stuff. Oh well, that rules out any practical use of the FPU under Linux then. So the FPU needs to be disabled and completely emulated by the kernel, because then all FPU instructions lead to an exception. This is working with Linux 2.6 on PS2. Naturally, as long as they got the Coprocessor Unusable exception right. There are even more problems when running unchanged code from official Fedora 12 on PS2, because of some different opcode encoding. The users of my PS2 Linux 2.6 complain about low speed, because many instructions are emulated. I need some fast
Re: Support for MIPS r5900
On 01/10/2013 03:58 PM, Jürgen Urban wrote: Hello Jeff, If you're using something from the Cygnus port, then it would be covered by the blanket copyright assignment Cygnus had in place with the FSF. If there are any doubts about the origin of a hunk of GCC code I could probably pull out the old sources to determine if it came from Cygnus's code base or not. Can you please tell me whether the following lines of the patches are covered by the blanket copyright assignment? Lines 335-533 of GCC patch (mips_r5900_lengthen_loops()): http://pastie.org/5664783 Lines 410-565 and 581-589 of binutils patch (check_short_loop()): http://pastie.org/5664824 The patches are from the second DVD of Sony's Linux Toolkit for the PS2. Neither of those would be covered by the blanket assignment as to the best of my knowledge they were not written by a Cygnus/Red Hat engineer while working for Cygnus/Red Hat. Clearly they're working around a chip bug, which seems to be documented reasonably well in a comment. Given that documentation you could write your own check for that processor bug. jeff
Re: Support for MIPS r5900
On Tue, 8 Jan 2013, Richard Sandiford wrote: I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? Do you pass those in FPRs or GPRs? IIUC the R5900 has an FPU that is functionally the same as that of the R4640/R4650. If that is the case, then there is no way to pass doubles in FPRs -- there is no room to store the upper halves. My point was that you could pass them in consecutive FPRs, like n32 does for long double. There's no architectural support for long double either, but the decision was still to pass them in FPRs rather than GPRs. You mean using a pair of FPRs (e.g. $f0/$f2) as a sum of two values of different exponents for extra precision? That would make sense, but would not match the way the double type has been defined in the ISO C standard for IEEE-754 targets -- please note that contrariwise the standard provides more freedom as to how the long double type can be implemented on IEEE-754 targets. Otherwise it would make no sense IMO, the contents would have to be moved back to GPRs for any use anyway. I'm not saying that that's a sensible precendent to copy. I was just using it as one example of why an ABI has to be defined. Not necessarily, the double type may simply be banned or alias to the single type. Especially the latter -- such an arrangement is allowed by ISO C as long as the target does not claim IEEE-754 compliance (we'd have a problem with the Java frontend though) and I think such a compilation mode might be permitted as long as it is useful to someone. Maciej
Re: Support for MIPS r5900
Maciej W. Rozycki ma...@codesourcery.com writes: On Tue, 8 Jan 2013, Richard Sandiford wrote: I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? Do you pass those in FPRs or GPRs? IIUC the R5900 has an FPU that is functionally the same as that of the R4640/R4650. If that is the case, then there is no way to pass doubles in FPRs -- there is no room to store the upper halves. My point was that you could pass them in consecutive FPRs, like n32 does for long double. There's no architectural support for long double either, but the decision was still to pass them in FPRs rather than GPRs. You mean using a pair of FPRs (e.g. $f0/$f2) as a sum of two values of different exponents for extra precision? That would make sense, but would not match the way the double type has been defined in the ISO C standard for IEEE-754 targets -- please note that contrariwise the standard provides more freedom as to how the long double type can be implemented on IEEE-754 targets. No, I mean passing the two 32-bit halves in two FPRs, like we pass the two 64-bit halves of long doubles in two FPRs. Like I say... I'm not saying that that's a sensible precendent to copy. I was just using it as one example of why an ABI has to be defined. Not necessarily, the double type may simply be banned or alias to the single type. Especially the latter -- such an arrangement is allowed by ISO C as long as the target does not claim IEEE-754 compliance (we'd have a problem with the Java frontend though) and I think such a compilation mode might be permitted as long as it is useful to someone. But that's the point: we have to define what the rules are. The definition includes what isn't allowed. Richard
Re: Support for MIPS r5900
Hello Richard, cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. trunc.w.s is enabled by ISA_HAS_TRUNC_W_S. This automatically disables cvt.w.s, because trunc.w.s is preferred. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? This seems to work. There are no unsupported instructions generated. Do you pass those in FPRs or GPRs? I used -mhard-float together with -msingle-float, so it is using FPRs. The n32 TImode support you mention uses pairs of GPRs, whereas I imagine you'd eventually want to use a single 128-bit GPR. Is that right? Most old PS2 code will work when supporting this: typedef unsigned int __u128 __attribute__((mode(TI))); This is currently working with n32 ABI without any change, but not in o32 ABI. Support for 128-bit GPR would be better, so we have full compatibility to old PS2 code. For the record, I think all those patches would be too invasive this late into the 4.8 cycle so would have to wait for 4.9. OK. I also want to go step by step here. Please use ISA_HAS_* for consistency with other macros. I think it'd be better to drop the '(integer)'. OK. I thought ISA_HAS_* was related to MIPS ISA. My stuff is only related to one CPU here. Several other cases later on, I won't bore you with them all :-) I rework it and try to get it stable and tested. Best regards Jürgen
Re: Support for MIPS r5900
Hello Maciej, ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. This has raised my attention -- AFAICS the binutils change recently approved correctly disables DMULT, DDIV, CVT.W.S, etc. for -march=r5900, but does not do that for LL or SC. I think that should be fixed. And I gather LLD and SCD should then be disabled as well. The glibc can only be compiled with support for ll and sc. The Linux kernel successfully emulates these instructions. When compiling GCC for mips*r5900*-elf (i.e. not Linux), the instructions ll/sc and lld/scd are disabled by my patch. Things would get more complicated if one wanted to run a real OS such as Linux on the R5900 and let the kernel FP emulator handle the missing double FP automagically -- this is a little bit out of scope here as regular -mdouble-float would then just do, but makes me wonder whether -mfp32 should really be enforced (as opposed to just defaulted) for the R5900, hmm... I tried to emulate the 64 Bit FPU when the real 32 Bit FPU was enabled in Linux. There are 2 problems with this: 1. When the program starts, I don't know if it needs a 64 Bit or 32 Bit FPRs. So registers are initialized for 32 bit. When dmfc0 or dmtc0 appears, I need to emulate them using 32 Bit FPU, because some 32 bit programs use these instructions with a 32 Bit FPU (e.g. Linux 2.6.35 kernel and Debian 5.0). When a 64 bit calculation instructions appears, I need to switch from 32 bit FPRs to 64 bit FPRs. When the program used 32 bit instructions with the odd FPRs, there is no way to reconstruct the overwritten part of the 64 bit FPRs. 2. Some undefined instructions (e.g. c.eq.d) doesn't lead to an exception on an r5900, but have undefined behavior. So there is no emulation possible. It just calculates random stuff. So the FPU needs to be disabled and completely emulated by the kernel, because then all FPU instructions lead to an exception. This is working with Linux 2.6 on PS2. There are even more problems when running unchanged code from official Fedora 12 on PS2, because of some different opcode encoding. The users of my PS2 Linux 2.6 complain about low speed, because many instructions are emulated. I need some fast implementation, even if the size of the floating point data types is smaller. So 32 bit FPU must be default for r5900. Best regards Jürgen
Re: Support for MIPS r5900
IIRC we defined doubles as 32bits wide in our old port. We simply didn't support 64bit wide doubles. I don't remember what mechanism we used to make this happen. Ah, yeah. I think limiting wide doubles would be good. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Not sure, sorry. IIRC I simply disabled muldi3_internal2 and I think we defined away everything related to timode except register-register moves. @Jeff: I think you know the stringent copyright rules for GCC. I want to use the code from the original patch, but I don't know how many people were involved. So I can't use it without copyright problems. Can you please tell me which code can I use without encountering copyright problems? I plan to submit the code for fixing the r5900 short loop bug in GCC. AIUI the problem that Jürgen's hitting is that _muldi3.o in libgcc actually contains __multi3 on 64-bit targets, because LIBGCC2_UNITS_PER_WORD == 8. Presumably _mulsi3.o would then contain __muldi3 where needed, but that file doesn't exist. So he was trying to add it. Yes, this is exactly what happened. Best regards Jürgen
Re: Support for MIPS r5900
On 01/08/2013 03:49 PM, Jürgen Urban wrote: @Jeff: I think you know the stringent copyright rules for GCC. I want to use the code from the original patch, but I don't know how many people were involved. So I can't use it without copyright problems. Can you please tell me which code can I use without encountering copyright problems? I plan to submit the code for fixing the r5900 short loop bug in GCC. If you're using something from the Cygnus port, then it would be covered by the blanket copyright assignment Cygnus had in place with the FSF. If there are any doubts about the origin of a hunk of GCC code I could probably pull out the old sources to determine if it came from Cygnus's code base or not. Jeff
Re: Support for MIPS r5900
On 01/06/2013 03:56 PM, Jürgen Urban wrote: Hello, I created a patch from scratch to support MIPS r5900 used in the Playstation 2, but I have some problems with it. The attached patch only works with the latest binutils from CVS. The binutils forces the compiler to use r5900 compatible instructions which is good to find errors in the GCC. Later I will try to submit a patch here, but first I need some help. The MIPS r5900 supports 32 bit, 64 bit and 128 bit data accesses on a 32 Bit address bus. It supports instructions from MIPS ISA I, II, III, IV and has additional instructions, but none of them are complete. On each ISA level there are instructions missing. It can run MIPS ABI o32, n32 and o64 code, as long as unsupported instructions are not used or emulated by the operating system and the addresses keep in the first 32 bit. My patch adds support for r5900 and tries to disable the following unsupported instructions: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Does someone know how to enable TImode in MIPS ABI o32 (this doesn't need to use the 128 bit instructions at the moment)? There is some old code for the Playstation 2 which needs this. I know that TImode is supported in ABI n32, but some code uses also the 32 bit FPU and FPU registers are not available with -msoft-float in inline assembler. What is the best way to change the alignment to 128 bit for all structures and stack in any MIPS ABI? Much old code for the Playstation 2 expects this. Hmm, I did a R5900 port back in the late 90s... Did that port never get contributed (yes, my memory is that bad these days) As far as getting TI mode working, IIRC I did a configury hack of some sort to force using a 64bit host wide integer, that in turn made it possible to support TImode as a pair of 64bit HWIs. As far as aligning structures and the stack, GCC has a standard set of macros to define structure stack alignment. Jeff
Re: Support for MIPS r5900
Jeff Law l...@redhat.com writes: On 01/06/2013 03:56 PM, Jürgen Urban wrote: Hello, I created a patch from scratch to support MIPS r5900 used in the Playstation 2, but I have some problems with it. The attached patch only works with the latest binutils from CVS. The binutils forces the compiler to use r5900 compatible instructions which is good to find errors in the GCC. Later I will try to submit a patch here, but first I need some help. The MIPS r5900 supports 32 bit, 64 bit and 128 bit data accesses on a 32 Bit address bus. It supports instructions from MIPS ISA I, II, III, IV and has additional instructions, but none of them are complete. On each ISA level there are instructions missing. It can run MIPS ABI o32, n32 and o64 code, as long as unsupported instructions are not used or emulated by the operating system and the addresses keep in the first 32 bit. My patch adds support for r5900 and tries to disable the following unsupported instructions: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Does someone know how to enable TImode in MIPS ABI o32 (this doesn't need to use the 128 bit instructions at the moment)? There is some old code for the Playstation 2 which needs this. I know that TImode is supported in ABI n32, but some code uses also the 32 bit FPU and FPU registers are not available with -msoft-float in inline assembler. What is the best way to change the alignment to 128 bit for all structures and stack in any MIPS ABI? Much old code for the Playstation 2 expects this. Hmm, I did a R5900 port back in the late 90s... Did that port never get contributed (yes, my memory is that bad these days) I remember there was talk in the early 2000s of contributing it, but we never had time. I think the MIPS copro support was from the r5900 port -- so it's effectively dead at the moment -- and the MODE_HAS_* stuff was from a refresh of it. Both of those made their way in, but I think that was about it. Richard
Re: Support for MIPS r5900
Jürgen Urban juergenur...@gmx.de writes:
ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
ll and sc is disabled with -mno-llsc and works.
cvt.w.s is replaced by trunc.w.s. This seems to work.
Probably showing my ignorance, but I couldn't see this in the patch.
I disabled 64 bit FPU instructions by -msoft-float. This works, but
using -msingle-float fails. This would be the better
configuration. There are still 64 bit FPU instructions used (e.g. dmfc1
$2,$f0 when using long double multiplication). So -msingle-float
doesn't seem to work on generic mips64-linux-gnu.
Right. That combination hasn't really been defined. What happens
for plain doubles? Do you pass those in FPRs or GPRs?
I tried to disable dmult and ddiv (see mips.md). Disabling worked, but
now muldi3 calls itself in libgcc2. I thought this should work, because
I got this working with GCC 4.3, but the latest GCC version is a
problem. multi3 is calling muldi3, so that muldi3 should be able to use
mulsi3, because it is the same C code in libgcc2. Can someone get me
some hints or comments? How can this be debugged?
Not sure, sorry.
Does someone know how to enable TImode in MIPS ABI o32 (this doesn't
need to use the 128 bit instructions at the moment)? There is some old
code for the Playstation 2 which needs this. I know that TImode is
supported in ABI n32, but some code uses also the 32 bit FPU and FPU
registers are not available with -msoft-float in inline assembler.
The n32 TImode support you mention uses pairs of GPRs, whereas I imagine
you'd eventually want to use a single 128-bit GPR. Is that right?
TImode in the current n32 sense doesn't really make practical sense
for 32-bit targets. We'd be dealing with quad registers in that case.
I think it would only make sense with TImode registers.
ISTR the TImode registers being a can of worms, especially with the
optimisation to only store the lower 64 bits if the upper 64 weren't used.
(Am I remembering that right?)
When you submit the TImode register support, please make the support
itself a separate patch from the ABI changes. I.e. one patch to
add TImode registers, one to add TImode to o32, one to add single-GPR
TImode to n32, etc. For the record, I think all those patches would be
too invasive this late into the 4.8 cycle so would have to wait for 4.9.
Also, any ABI changes should be conditional on a new flag rather than
keyed off the architecture. That flag would then be the default for
your new configuration.
What is the best way to change the alignment to 128 bit for all
structures and stack in any MIPS ABI? Much old code for the Playstation
2 expects this.
The stack is STACK_BOUNDARY (already 128 for n32). Do you mean the
padding of all structure types, or just global structure variables?
If the former, it sounds like ROUND_TYPE_ALIGN, but also sounds scary :-)
If the latter, it's DATA_ALIGNMENT.
@@ -15801,6 +15816,11 @@ mips_reorg_process_insns (void)
if (TARGET_FIX_VR4120 || TARGET_FIX_24K)
cfun-machine-all_noreorder_p = false;
+ /* Code compiled for R5900 can't be all noreorder because
+ we rely on the assembler to work around some errata. */
+ if (TARGET_MIPS5900)
+cfun-machine-all_noreorder_p = false;
+
/* The same is true for -mfix-vr4130 if we might generate MFLO or
MFHI instructions. Note that we avoid using MFLO and MFHI if
the VR4130 MACC and DMACC instructions are available instead;
Please fold this into the clause above it.
+/* Target supports instructions dmult and dmultu (integer). */
+#define TARGET_HAS_DMULT (TARGET_64BIT \
+ !TARGET_MIPS5900)
Please use ISA_HAS_* for consistency with other macros. I think it'd
be better to drop the '(integer)'.
+/* Target supports instructions mult and multu in 32 bit mode (integer). */
+#define TARGET_HAS_MULT (mips_isa = 1)
...and here drop 'in 32 bit mode (integer)'. 32-bit-mode isn't really
relevant here.
+/* Target supports instructions dmult and dmultu (integer). */
+#define TARGET_HAS_DDIV (TARGET_64BIT
\
+ !TARGET_MIPS5900)
Same as above.
+/* Target supports instructions mult and multu in 32 bit mode (integer). */
+#define TARGET_HAS_DIV (mips_isa = 1)
Here too, plus div rather than mult.
@@ -841,10 +859,10 @@ struct mips_cpu_info {
/* ISA has the integer conditional move instructions introduced in mips4 and
ST Loongson 2E/2F. */
-#define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE || TARGET_LOONGSON_2EF)
+#define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE || TARGET_LOONGSON_2EF
|| TARGET_MIPS5900)
GCC has a strict 80-column limit, so please make this:
#define ISA_HAS_CONDMOVE(ISA_HAS_FP_CONDMOVE \
|| TARGET_LOONGSON_2EF \
|| TARGET_MIPS5900)
/* ISA has LDC1 and
Re: Support for MIPS r5900
On Mon, 7 Jan 2013, Richard Sandiford wrote: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. This has raised my attention -- AFAICS the binutils change recently approved correctly disables DMULT, DDIV, CVT.W.S, etc. for -march=r5900, but does not do that for LL or SC. I think that should be fixed. And I gather LLD and SCD should then be disabled as well. I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? Do you pass those in FPRs or GPRs? IIUC the R5900 has an FPU that is functionally the same as that of the R4640/R4650. If that is the case, then there is no way to pass doubles in FPRs -- there is no room to store the upper halves. The single-precision FPU of the R4640/R4650 processors can be configured with CP0.Status.FR to present a register file of either 16 or 32 32-bit registers. The upper halves are not implemented. Frankly I don't think we have an ABI to express doubles on such platforms -- we could approximate one by passing doubles in GPRs and singles in FPRs (where mandated by o32), but that would really be an entirely new ABI. The compiler could presumably be taught to call soft-float routines for double arithmetic and emit FP machine code for single arithmetic. I'm not sure how feasible the use of single float could be in the soft-float library. Things would get more complicated if one wanted to run a real OS such as Linux on the R5900 and let the kernel FP emulator handle the missing double FP automagically -- this is a little bit out of scope here as regular -mdouble-float would then just do, but makes me wonder whether -mfp32 should really be enforced (as opposed to just defaulted) for the R5900, hmm... Maciej
Re: Support for MIPS r5900
On 01/07/2013 02:52 PM, Richard Sandiford wrote: I disabled 64 bit FPU instructions by -msoft-float. This works, but using -msingle-float fails. This would be the better configuration. There are still 64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double multiplication). So -msingle-float doesn't seem to work on generic mips64-linux-gnu. Right. That combination hasn't really been defined. What happens for plain doubles? Do you pass those in FPRs or GPRs? IIRC we defined doubles as 32bits wide in our old port. We simply didn't support 64bit wide doubles. I don't remember what mechanism we used to make this happen. I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now muldi3 calls itself in libgcc2. I thought this should work, because I got this working with GCC 4.3, but the latest GCC version is a problem. multi3 is calling muldi3, so that muldi3 should be able to use mulsi3, because it is the same C code in libgcc2. Can someone get me some hints or comments? How can this be debugged? Not sure, sorry. IIRC I simply disabled muldi3_internal2 and I think we defined away everything related to timode except register-register moves. Jeff
Re: Support for MIPS r5900
Richard Sandiford rdsandif...@googlemail.com writes: Jürgen Urban juergenur...@gmx.de writes: ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions. ll and sc is disabled with -mno-llsc and works. cvt.w.s is replaced by trunc.w.s. This seems to work. Probably showing my ignorance, but I couldn't see this in the patch. Maciej's reply made me realise that this sounded like I was responding to all three lines. The LL and SC stuff is fine. It was the CVT.W.S bit that I couldn't see. Sorry for the confusion. Richard
Support for MIPS r5900
Hello,
I created a patch from scratch to support MIPS r5900 used in the Playstation 2,
but I have some problems with it.
The attached patch only works with the latest binutils from CVS. The binutils
forces the compiler to use r5900 compatible instructions which is good to find
errors in the GCC. Later I will try to submit a patch here, but first I need
some help.
The MIPS r5900 supports 32 bit, 64 bit and 128 bit data accesses on a 32 Bit
address bus. It supports instructions from MIPS ISA I, II, III, IV and has
additional instructions, but none of them are complete. On each ISA level there
are instructions missing.
It can run MIPS ABI o32, n32 and o64 code, as long as unsupported instructions
are not used or emulated by the operating system and the addresses keep in the
first 32 bit.
My patch adds support for r5900 and tries to disable the following unsupported
instructions:
ll, sc, dmult, ddiv, cvt.w.s, 64 bit FPU instructions.
ll and sc is disabled with -mno-llsc and works.
cvt.w.s is replaced by trunc.w.s. This seems to work.
I disabled 64 bit FPU instructions by -msoft-float. This works, but using
-msingle-float fails. This would be the better configuration. There are still
64 bit FPU instructions used (e.g. dmfc1 $2,$f0 when using long double
multiplication). So -msingle-float doesn't seem to work on generic
mips64-linux-gnu.
I tried to disable dmult and ddiv (see mips.md). Disabling worked, but now
muldi3 calls itself in libgcc2. I thought this should work, because I got this
working with GCC 4.3, but the latest GCC version is a problem. multi3 is
calling muldi3, so that muldi3 should be able to use mulsi3, because it is the
same C code in libgcc2. Can someone get me some hints or comments? How can this
be debugged?
Does someone know how to enable TImode in MIPS ABI o32 (this doesn't need to
use the 128 bit instructions at the moment)? There is some old code for the
Playstation 2 which needs this. I know that TImode is supported in ABI n32, but
some code uses also the 32 bit FPU and FPU registers are not available with
-msoft-float in inline assembler.
What is the best way to change the alignment to 128 bit for all structures and
stack in any MIPS ABI? Much old code for the Playstation 2 expects this.
Best regards
Jürgen Urban
diff -Nurp '--exclude=build01' ../gcc-svn-20130105.orig/config.sub gcc-svn-20130105-mips64r5900el-linux-patched/config.sub
--- ../gcc-svn-20130105.orig/config.sub 2013-01-05 20:06:32.859960482 +0100
+++ gcc-svn-20130105-mips64r5900el-linux-patched/config.sub 2013-01-06 19:11:56.332755480 +0100
@@ -284,6 +284,8 @@ case $basic_machine in
| mips64vr4300 | mips64vr4300el \
| mips64vr5000 | mips64vr5000el \
| mips64vr5900 | mips64vr5900el \
+ | mips64r5900 | mips64r5900el \
+ | mipsr5900 | mipsr5900el \
| mipsisa32 | mipsisa32el \
| mipsisa32r2 | mipsisa32r2el \
| mipsisa64 | mipsisa64el \
@@ -401,6 +403,8 @@ case $basic_machine in
| mips64vr4300-* | mips64vr4300el-* \
| mips64vr5000-* | mips64vr5000el-* \
| mips64vr5900-* | mips64vr5900el-* \
+ | mips64r5900-* | mips64r5900el-* \
+ | mipsr5900-* | mipsr5900el-* \
| mipsisa32-* | mipsisa32el-* \
| mipsisa32r2-* | mipsisa32r2el-* \
| mipsisa64-* | mipsisa64el-* \
diff -Nurp '--exclude=build01' ../gcc-svn-20130105.orig/gcc/config/mips/mips.c gcc-svn-20130105-mips64r5900el-linux-patched/gcc/config/mips/mips.c
--- ../gcc-svn-20130105.orig/gcc/config/mips/mips.c 2013-01-05 20:03:24.231962472 +0100
+++ gcc-svn-20130105-mips64r5900el-linux-patched/gcc/config/mips/mips.c 2013-01-06 19:11:56.336755480 +0100
@@ -1025,6 +1025,19 @@ static const struct mips_rtx_cost_data
1, /* branch_cost */
4/* memory_latency */
},
+ { /* R5900 */
+COSTS_N_INSNS (4),/* fp_add */
+COSTS_N_INSNS (4),/* fp_mult_sf */
+COSTS_N_INSNS (256), /* fp_mult_df */
+COSTS_N_INSNS (8),/* fp_div_sf */
+COSTS_N_INSNS (256), /* fp_div_df */
+COSTS_N_INSNS (4),/* int_mult_si */
+COSTS_N_INSNS (256), /* int_mult_di */
+COSTS_N_INSNS (37), /* int_div_si */
+COSTS_N_INSNS (256), /* int_div_di */
+ 1, /* branch_cost */
+ 4/* memory_latency */
+ },
{ /* R7000 */
/* The only costs that are changed here are
integer multiplication. */
@@ -12793,6 +12806,7 @@ mips_issue_rate (void)
case PROCESSOR_R4130:
case PROCESSOR_R5400:
case PROCESSOR_R5500:
+case PROCESSOR_R5900:
case PROCESSOR_R7000:
case PROCESSOR_R9000:
case PROCESSOR_OCTEON:
@@ -15573,6 +15587,7 @@ vr4130_align_insns (void)
}
dfa_finish ();
}
+
/* This structure records that the current function has a LO_SUM
involving SYMBOL_REF or LABEL_REF BASE and that MAX_OFFSET is
@@ -15801,6 +15816,11 @@ mips_reorg_process_insns (void)
if (TARGET_FIX_VR4120 || TARGET_FIX_24K)
cfun-machine-all_noreorder_p
