Hi Aleksandar,
> Pull request with 32 patches from this series is already sent, and I would
> like to avoid sending v2 of that request. Let's wait for some time until
> the pull request is hopefully accepted. There will be most likely another
> one at the beginning of the next week.
>
> We are appoaching QEMU 3.1 soft freeze (Oct 30), and at this point we
> would like to stabilize the code, and to integrate only crucial patches.
> I suggest that you create a new series "target/mips: Amend R5900 support".
> It should be based on the code submitted in the pull request. Place the
> most crucial patches as the first ones, at the beginning of the series.
The R5900 testsuite in tests/tcg/mips/mipsr5900 fails unless ASE_MMI is
part of insn_flags for the R5900:
--- a/target/mips/translate_init.inc.c
+++ b/target/mips/translate_init.inc.c
@@ -466,7 +466,7 @@ const mips_def_t mips_defs[] =
#endif /* !CONFIG_USER_ONLY */
.SEGBITS = 32,
.PABITS = 32,
- .insn_flags = CPU_R5900,
+ .insn_flags = CPU_R5900 | ASE_MMI,
.mmu_type = MMU_TYPE_R4000,
},
{
Perhaps that is the only (somewhat) crucial problem, depending on how the
testsuites are used, of course.
The other ASE_MMI changes and the disassembly of MULT1 and MULTU1 can wait,
as can R5900 support for MADD, MADDU, MADD1 and MADDU1, in my opinion.
> FPU changes are too risky at this stage od 3.1 development cycle, and I
> would leave them for QEMU 3.2+.
Agreed! As Maciej just noted, there are also toolchain issues that need
to be addressed for the R5900 FPU.
Fredrik
