[Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900

[Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900

[Fredrik Noring]

The primary purpose of these changes is to support programs compiled
by GCC for the R5900 target and thereby run R5900 Linux distributions,
for example Gentoo.

GCC in version 7.3, by itself, by inspection of the GCC source code
and inspection of the generated machine code, for the R5900 target,
only emits two instructions that are specific to the R5900: the three-
operand MULT and MULTU. GCC and libc also emit certain MIPS III
instructions that are not part of the R5900 ISA. They are normally
trapped and emulated by the Linux kernel, and therefore need to be
treated accordingly by QEMU. This is addressed, in turn, by the
patch series.

A program compiled by GCC is taken to mean source code compiled by GCC
under the restrictions above. One can, with the apparent limitations,
with a bit of effort obtain a fully functioning operating system such
as R5900 Gentoo. Strictly speaking, programs need not be compiled by
GCC to make use of this change.

Instructions and other facilities of the R5900 not implemented by these
changes are intended to signal provisional exceptions. One such example
is the FPU that is not compliant with IEEE 754-1985 in system mode. It
is therefore provisionally disabled. In user space the FPU is trapped
and emulated by IEEE 754-1985 compliant software in the kernel, and
this is handled accordingly by QEMU. Another example is the 93
multimedia instructions specific to the R5900 that generate provisional
reserved instruction exception signals.

One of the benefits of running a Linux distribution under QEMU is that
programs can be compiled with a native compiler, where the host and
target are the same, as opposed to a cross-compiler, where they are
not the same. This is especially important in cases where the target
hardware does not have the resources to run a native compiler.

Problems with cross-compilation are often related to host and target
differences in integer sizes, pointer sizes, endianness, machine code,
ABI, etc. Sometimes cross-compilation is not even supported by the
build script for a given package. One effective way to avoid those
problems is to replace the cross-compiler with a native compiler. This
change of compilation methods does not resolve the inherent problems
with cross-compilation.

The native compiler naturally replaces the cross-compiler, because one
typically uses one or the other, and preferably the native compiler
when the circumstances admit this. The native compiler is also a good
test case for the R5900 QEMU user mode. Additionally, Gentoo is well-
known for compiling and installing its packages from sources.

This change has been tested with Gentoo compiled for R5900, including
native compilation of several packages under QEMU. I used the Gentoo
sys-devel/crossdev package

https://wiki.gentoo.org/wiki/Crossdev

with patches mainly to simplify the handling of LL/SC and floating
point support, to avoid complications with additional configure and
compiler flags. Busybox

https://busybox.net/

can also be used to build a simple functional R5900 program. It can be
used to test the R5900 CPU in QEMU user mode.

The R5900 implements the 64-bit MIPS III instruction set except DMULT,
DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD. The MIPS IV instructions MOVN,
MOVZ and PREF are implemented. It has the R5900 specific three-operand
instructions MADD, MADDU, MULT and MULTU as well as pipeline 1 versions
MULT1, MULTU1, DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and
MTLO1. A set of 93 128-bit multimedia instructions specific to the
R5900 is also implemented.

The Toshiba TX System RISC TX79 Core Architecture manual

http://www.lukasz.dk/files/tx79architecture.pdf

describes the C790 processor that is a follow-up to the R5900. There
are a few notable differences in that the R5900 FPU

- is not IEEE 754-1985 compliant,
- does not implement double format, and
- its machine code is nonstandard.

Changes in v7:
- Rename gen_mul_txxx to gen_mul_txx9
- Use MIPS_INVAL("mul TXx9")
- Reviewed-by: Philippe Mathieu-Daudé

Changes in v6:
- Set the CP0 PRId implementation number to 0x2E for the R5900
- Refer to the C790 follow-up in the definition of the R5900
- Define and use check_insn_opc_user_only in the same change
- Rename gen_mul_r5900 to gen_mul_txxx
- Enclose single statements in braces
- Expand and reword commit messages and notes
- Reword the cover letter subject line
- All changes build with GCC and Clang
- Approval from checkpatch.pl

Changes in v5:
- Reorder check_insn_opc_user_only calls
- Call check_insn_opc_removed in check_insn_opc_user_only

Changes in v4:
- Split into a patch series consting of eight changes
- Expand commit messages and notes
- Introduce check_insn_opc_user_only
- Base R5900 on MIPS III, with MOVN, MOVZ and PREF from MIPS IV
- DMULT, DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD are user only
- Note Toshiba/Sony R5900 for EF_MIPS_MACH_R5900 definition
- Rework gen_mul_r5900
- Fix ICE and DCE
- Fix SEGBITS and PABITS
- Fix indentation

Changes in v3:
- Apply to HEAD
- Remove the word "initial" from subject line

Changes in v2:
- Update mips_defs array with R5900 values
- LL/SC and FPU are user only

Fredrik Noring (7):
  target/mips: Define R5900 instructions and CPU preprocessor constants
  target/mips: Support R5900 specific three-operand MULT and MULTU
  target/mips: Support R5900 instructions MOVN, MOVZ and PREF from MIPS IV
  target/mips: R5900 DMULT[U], DDIV[U], LL[D] and SC[D] are user only
  target/mips: Define the R5900 CPU
  linux-user/mips: Recognise the R5900 CPU model
  elf: Toshiba/Sony rather than MIPS are the implementors of the R5900

 include/elf.h                    |   2 +-
 linux-user/mips/target_elf.h     |   3 ++
 target/mips/mips-defs.h          |   2 +
 target/mips/translate.c          | 101 +++++++++++++++++++++++++++++++++++++--
 target/mips/translate_init.inc.c |  59 +++++++++++++++++++++++
 5 files changed, 163 insertions(+), 4 deletions(-)

-- 
2.16.4

[Qemu-devel] [PATCH v7 1/7] target/mips: Define R5900 instructions and CPU preprocessor constants

[Fredrik Noring]

The R5900 implements the 64-bit MIPS III instruction set except DMULT,
DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD. The MIPS IV instructions MOVN,
MOVZ and PREF are implemented. It has the R5900 specific three-operand
instructions MADD, MADDU, MULT and MULTU as well as pipeline 1 versions
MULT1, MULTU1, DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and
MTLO1. A set of 93 128-bit multimedia instructions specific to the
R5900 is also implemented.

The Toshiba TX System RISC TX79 Core Architecture manual

http://www.lukasz.dk/files/tx79architecture.pdf

describes the C790 processor that is a follow-up to the R5900. There
are a few notable differences in that the R5900 FPU

- is not IEEE 754-1985 compliant,
- does not implement double format, and
- its machine code is nonstandard.

Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/mips/mips-defs.h | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
index c8e99791ad..76550de2da 100644
--- a/target/mips/mips-defs.h
+++ b/target/mips/mips-defs.h
@@ -53,6 +53,7 @@
 #define   ASE_MSA       0x01000000
 
 /* Chip specific instructions. */
+#define         INSN_R5900       0x10000000
 #define		INSN_LOONGSON2E  0x20000000
 #define		INSN_LOONGSON2F  0x40000000
 #define		INSN_VR54XX	0x80000000
@@ -63,6 +64,7 @@
 #define		CPU_MIPS3	(CPU_MIPS2 | ISA_MIPS3)
 #define		CPU_MIPS4	(CPU_MIPS3 | ISA_MIPS4)
 #define		CPU_VR54XX	(CPU_MIPS4 | INSN_VR54XX)
+#define         CPU_R5900       (CPU_MIPS3 | INSN_R5900)
 #define		CPU_LOONGSON2E  (CPU_MIPS3 | INSN_LOONGSON2E)
 #define		CPU_LOONGSON2F  (CPU_MIPS3 | INSN_LOONGSON2F)
 
-- 
2.16.4

[Qemu-devel] [PATCH v7 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU

[Fredrik Noring]

The three-operand MULT and MULTU are the only R5900 specific
instructions emitted by GCC 7.3. The R5900 also implements the three-
operand MADD and MADDU instructions, but they are omitted in QEMU for
now since they are absent in programs compiled by current GCC versions.

Likewise, the R5900 specific pipeline 1 instruction variants MULT1,
MULTU1, DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and MTLO1
are omitted here as well.

Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/mips/translate.c | 73 +++++++++++++++++++++++++++++++++++++++++++++++++
 1 file changed, 73 insertions(+)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index ab16cdb911..a32e021745 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -3768,6 +3768,77 @@ static void gen_muldiv(DisasContext *ctx, uint32_t opc,
     tcg_temp_free(t1);
 }
 
+/*
+ * These MULT and MULTU instructions implemented in for example the
+ * Toshiba/Sony R5900 and the Toshiba TX19, TX39 and TX79 core
+ * architectures are special three-operand variants with the syntax
+ *
+ *     MULT[U] rd, rs, rt
+ *
+ * such that
+ *
+ *     (rd, LO, HI) <- rs * rt
+ *
+ * where the low-order 32-bits of the result is placed into both the
+ * GPR rd and the special register LO. The high-order 32-bits of the
+ * result is placed into the special register HI.
+ *
+ * If the GPR rd is omitted in assembly language, it is taken to be 0,
+ * which is the zero register that always reads as 0.
+ */
+static void gen_mul_txx9(DisasContext *ctx, uint32_t opc,
+                         int acc, int rd, int rs, int rt)
+{
+    TCGv t0 = tcg_temp_new();
+    TCGv t1 = tcg_temp_new();
+
+    gen_load_gpr(t0, rs);
+    gen_load_gpr(t1, rt);
+
+    switch (opc) {
+    case OPC_MULT:
+        {
+            TCGv_i32 t2 = tcg_temp_new_i32();
+            TCGv_i32 t3 = tcg_temp_new_i32();
+            tcg_gen_trunc_tl_i32(t2, t0);
+            tcg_gen_trunc_tl_i32(t3, t1);
+            tcg_gen_muls2_i32(t2, t3, t2, t3);
+            if (rd) {
+                tcg_gen_ext_i32_tl(cpu_gpr[rd], t2);
+            }
+            tcg_gen_ext_i32_tl(cpu_LO[acc], t2);
+            tcg_gen_ext_i32_tl(cpu_HI[acc], t3);
+            tcg_temp_free_i32(t2);
+            tcg_temp_free_i32(t3);
+        }
+        break;
+    case OPC_MULTU:
+        {
+            TCGv_i32 t2 = tcg_temp_new_i32();
+            TCGv_i32 t3 = tcg_temp_new_i32();
+            tcg_gen_trunc_tl_i32(t2, t0);
+            tcg_gen_trunc_tl_i32(t3, t1);
+            tcg_gen_mulu2_i32(t2, t3, t2, t3);
+            if (rd) {
+                tcg_gen_ext_i32_tl(cpu_gpr[rd], t2);
+            }
+            tcg_gen_ext_i32_tl(cpu_LO[acc], t2);
+            tcg_gen_ext_i32_tl(cpu_HI[acc], t3);
+            tcg_temp_free_i32(t2);
+            tcg_temp_free_i32(t3);
+        }
+        break;
+    default:
+        MIPS_INVAL("mul TXx9");
+        generate_exception_end(ctx, EXCP_RI);
+        goto out;
+    }
+
+ out:
+    tcg_temp_free(t0);
+    tcg_temp_free(t1);
+}
+
 static void gen_mul_vr54xx (DisasContext *ctx, uint32_t opc,
                             int rd, int rs, int rt)
 {
@@ -22378,6 +22449,8 @@ static void decode_opc_special_legacy(CPUMIPSState *env, DisasContext *ctx)
             check_insn(ctx, INSN_VR54XX);
             op1 = MASK_MUL_VR54XX(ctx->opcode);
             gen_mul_vr54xx(ctx, op1, rd, rs, rt);
+        } else if (ctx->insn_flags & INSN_R5900) {
+            gen_mul_txx9(ctx, op1, 0, rd, rs, rt);
         } else {
             gen_muldiv(ctx, op1, rd & 3, rs, rt);
         }
-- 
2.16.4

[Qemu-devel] [PATCH v7 3/7] target/mips: Support R5900 instructions MOVN, MOVZ and PREF from MIPS IV

[Fredrik Noring]

The R5900 is taken to be MIPS III with certain modifications. From
MIPS IV it implements the instructions MOVN, MOVZ and PREF.

Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/mips/translate.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index a32e021745..9d9be199e4 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -22422,7 +22422,7 @@ static void decode_opc_special_legacy(CPUMIPSState *env, DisasContext *ctx)
     case OPC_MOVN:         /* Conditional move */
     case OPC_MOVZ:
         check_insn(ctx, ISA_MIPS4 | ISA_MIPS32 |
-                   INSN_LOONGSON2E | INSN_LOONGSON2F);
+                   INSN_LOONGSON2E | INSN_LOONGSON2F | INSN_R5900);
         gen_cond_move(ctx, op1, rd, rs, rt);
         break;
     case OPC_MFHI:          /* Move from HI/LO */
@@ -25006,7 +25006,8 @@ static void decode_opc(CPUMIPSState *env, DisasContext *ctx)
         break;
     case OPC_PREF:
         check_insn_opc_removed(ctx, ISA_MIPS32R6);
-        check_insn(ctx, ISA_MIPS4 | ISA_MIPS32);
+        check_insn(ctx, ISA_MIPS4 | ISA_MIPS32 |
+                   INSN_R5900);
         /* Treat as NOP. */
         break;
 
-- 
2.16.4

[Qemu-devel] [PATCH v7 4/7] target/mips: R5900 DMULT[U], DDIV[U], LL[D] and SC[D] are user only

[Fredrik Noring]

The Linux kernel traps certain reserved instruction exceptions to
emulate the corresponding instructions. QEMU is the kernel in user
mode, so those traps are emulated by accepting the instructions.

This change adds the function check_insn_opc_user_only to signal a
reserved instruction exception for flagged CPUs in QEMU system mode.

The MIPS III instructions DMULT[U], DDIV[U], LL[D] and SC[D] are not
implemented in R5900 hardware. They are trapped and emulated by the
Linux kernel and, accordingly, therefore QEMU user only instructions.

Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/mips/translate.c | 23 ++++++++++++++++++++++-
 1 file changed, 22 insertions(+), 1 deletion(-)

diff --git a/target/mips/translate.c b/target/mips/translate.c
index 9d9be199e4..2d5c0a8173 100644
--- a/target/mips/translate.c
+++ b/target/mips/translate.c
@@ -1887,6 +1887,21 @@ static inline void check_insn_opc_removed(DisasContext *ctx, int flags)
     }
 }
 
+/*
+ * The Linux kernel traps certain reserved instruction exceptions to
+ * emulate the corresponding instructions. QEMU is the kernel in user
+ * mode, so those traps are emulated by accepting the instructions.
+ *
+ * A reserved instruction exception is generated for flagged CPUs if
+ * QEMU runs in system mode.
+ */
+static inline void check_insn_opc_user_only(DisasContext *ctx, int flags)
+{
+#ifndef CONFIG_USER_ONLY
+    check_insn_opc_removed(ctx, flags);
+#endif
+}
+
 /* This code generates a "reserved instruction" exception if the
    CPU does not support 64-bit paired-single (PS) floating point data type */
 static inline void check_ps(DisasContext *ctx)
@@ -22465,6 +22480,7 @@ static void decode_opc_special_legacy(CPUMIPSState *env, DisasContext *ctx)
     case OPC_DDIV:
     case OPC_DDIVU:
         check_insn(ctx, ISA_MIPS3);
+        check_insn_opc_user_only(ctx, INSN_R5900);
         check_mips_64(ctx);
         gen_muldiv(ctx, op1, 0, rs, rt);
         break;
@@ -24968,6 +24984,7 @@ static void decode_opc(CPUMIPSState *env, DisasContext *ctx)
          break;
     case OPC_LL: /* Load and stores */
         check_insn(ctx, ISA_MIPS2);
+        check_insn_opc_user_only(ctx, INSN_R5900);
         /* Fallthrough */
     case OPC_LWL:
     case OPC_LWR:
@@ -24993,6 +25010,7 @@ static void decode_opc(CPUMIPSState *env, DisasContext *ctx)
     case OPC_SC:
         check_insn(ctx, ISA_MIPS2);
          check_insn_opc_removed(ctx, ISA_MIPS32R6);
+        check_insn_opc_user_only(ctx, INSN_R5900);
          gen_st_cond(ctx, op, rt, rs, imm);
          break;
     case OPC_CACHE:
@@ -25259,9 +25277,11 @@ static void decode_opc(CPUMIPSState *env, DisasContext *ctx)
 
 #if defined(TARGET_MIPS64)
     /* MIPS64 opcodes */
+    case OPC_LLD:
+        check_insn_opc_user_only(ctx, INSN_R5900);
+        /* fall through */
     case OPC_LDL:
     case OPC_LDR:
-    case OPC_LLD:
         check_insn_opc_removed(ctx, ISA_MIPS32R6);
         /* fall through */
     case OPC_LWU:
@@ -25282,6 +25302,7 @@ static void decode_opc(CPUMIPSState *env, DisasContext *ctx)
     case OPC_SCD:
         check_insn_opc_removed(ctx, ISA_MIPS32R6);
         check_insn(ctx, ISA_MIPS3);
+        check_insn_opc_user_only(ctx, INSN_R5900);
         check_mips_64(ctx);
         gen_st_cond(ctx, op, rt, rs, imm);
         break;
-- 
2.16.4

[Qemu-devel] [PATCH v7 5/7] target/mips: Define the R5900 CPU

[Fredrik Noring]

The primary purpose of this change is to support programs compiled by
GCC for the R5900 target and thereby run R5900 Linux distributions, for
example Gentoo.

GCC in version 7.3, by itself, by inspection of the GCC source code
and inspection of the generated machine code, for the R5900 target,
only emits two instructions that are specific to the R5900: the three-
operand MULT and MULTU. GCC and libc also emit certain MIPS III
instructions that are not part of the R5900 ISA. They are normally
trapped and emulated by the Linux kernel, and therefore need to be
treated accordingly by QEMU.

A program compiled by GCC is taken to mean source code compiled by GCC
under the restrictions above. One can, with the apparent limitations,
with a bit of effort obtain a fully functioning operating system such
as R5900 Gentoo. Strictly speaking, programs need not be compiled by
GCC to make use of this change.

Instructions and other facilities of the R5900 not implemented by this
change are intended to signal provisional exceptions. One such example
is the FPU that is not compliant with IEEE 754-1985 in system mode. It
is therefore provisionally disabled. In user space the FPU is trapped
and emulated by IEEE 754-1985 compliant software in the kernel, and
this is handled accordingly by QEMU. Another example is the 93
multimedia instructions specific to the R5900 that generate provisional
reserved instruction exception signals.

One of the benefits of running a Linux distribution under QEMU is that
programs can be compiled with a native compiler, where the host and
target are the same, as opposed to a cross-compiler, where they are
not the same. This is especially important in cases where the target
hardware does not have the resources to run a native compiler.

Problems with cross-compilation are often related to host and target
differences in integer sizes, pointer sizes, endianness, machine code,
ABI, etc. Sometimes cross-compilation is not even supported by the
build script for a given package. One effective way to avoid those
problems is to replace the cross-compiler with a native compiler. This
change of compilation methods does not resolve the inherent problems
with cross-compilation.

The native compiler naturally replaces the cross-compiler, because one
typically uses one or the other, and preferably the native compiler
when the circumstances admit this. The native compiler is also a good
test case for the R5900 QEMU user mode. Additionally, Gentoo is well-
known for compiling and installing its packages from sources.

This change has been tested with Gentoo compiled for R5900, including
native compilation of several packages under QEMU.

Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 target/mips/translate_init.inc.c | 59 ++++++++++++++++++++++++++++++++++++++++
 1 file changed, 59 insertions(+)

diff --git a/target/mips/translate_init.inc.c b/target/mips/translate_init.inc.c
index b3320b9dc7..b5dacf4ffe 100644
--- a/target/mips/translate_init.inc.c
+++ b/target/mips/translate_init.inc.c
@@ -410,6 +410,65 @@ const mips_def_t mips_defs[] =
         .insn_flags = CPU_MIPS32R5 | ASE_MSA,
         .mmu_type = MMU_TYPE_R4000,
     },
+    {
+        /*
+         * The Toshiba TX System RISC TX79 Core Architecture manual
+         *
+         * http://www.lukasz.dk/files/tx79architecture.pdf
+         *
+         * describes the C790 processor that is a follow-up to the R5900.
+         * There are a few notable differences in that the R5900 FPU
+         *
+         * - is not IEEE 754-1985 compliant,
+         * - does not implement double format, and
+         * - its machine code is nonstandard.
+         */
+        .name = "R5900",
+        .CP0_PRid = 0x00002E00,
+        /* No L2 cache, icache size 32k, dcache size 32k, uncached coherency. */
+        .CP0_Config0 = (0x3 << 9) | (0x3 << 6) | (0x2 << CP0C0_K0),
+        .CP0_Status_rw_bitmask = 0xF4C79C1F,
+#ifdef CONFIG_USER_ONLY
+        /*
+         * R5900 hardware traps to the Linux kernel for IEEE 754-1985 and LL/SC
+         * emulation. For user only, QEMU is the kernel, so we emulate the traps
+         * by simply emulating the instructions directly.
+         *
+         * Note: Config1 is only used internally, the R5900 has only Config0.
+         */
+        .CP0_Config1 = (1 << CP0C1_FP) | (47 << CP0C1_MMU),
+        .CP0_LLAddr_rw_bitmask = 0xFFFFFFFF,
+        .CP0_LLAddr_shift = 4,
+        .CP1_fcr0 = (0x38 << FCR0_PRID) | (0x0 << FCR0_REV),
+        .CP1_fcr31 = 0,
+        .CP1_fcr31_rw_bitmask = 0x0183FFFF,
+#else
+        /*
+         * The R5900 COP1 FPU implements single-precision floating-point
+         * operations but is not entirely IEEE 754-1985 compatible. In
+         * particular,
+         *
+         * - NaN (not a number) and +/- infinities are not supported;
+         * - exception mechanisms are not fully supported;
+         * - denormalized numbers are not supported;
+         * - rounding towards nearest and +/- infinities are not supported;
+         * - computed results usually differs in the least significant bit;
+         * - saturations can differ more than the least significant bit.
+         *
+         * Since only rounding towards zero is supported, the two least
+         * significant bits of FCR31 are hardwired to 01.
+         *
+         * FPU emulation is disabled here until it is implemented.
+         *
+         * Note: Config1 is only used internally, the R5900 has only Config0.
+         */
+        .CP0_Config1 = (47 << CP0C1_MMU),
+#endif /* !CONFIG_USER_ONLY */
+        .SEGBITS = 32,
+        .PABITS = 32,
+        .insn_flags = CPU_R5900,
+        .mmu_type = MMU_TYPE_R4000,
+    },
     {
         /* A generic CPU supporting MIPS32 Release 6 ISA.
            FIXME: Support IEEE 754-2008 FP.
-- 
2.16.4

[Qemu-devel] [PATCH v7 6/7] linux-user/mips: Recognise the R5900 CPU model

[Fredrik Noring]

This kind of ELF for the R5900 relies on an IEEE 754-1985 compliant FPU.
The R5900 FPU hardware is noncompliant and it is therefore emulated in
software by the Linux kernel. QEMU emulates a compliant FPU accordingly.

Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 linux-user/mips/target_elf.h | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/linux-user/mips/target_elf.h b/linux-user/mips/target_elf.h
index fa5d30bf99..a98c9bd6ad 100644
--- a/linux-user/mips/target_elf.h
+++ b/linux-user/mips/target_elf.h
@@ -12,6 +12,9 @@ static inline const char *cpu_get_model(uint32_t eflags)
     if ((eflags & EF_MIPS_ARCH) == EF_MIPS_ARCH_32R6) {
         return "mips32r6-generic";
     }
+    if ((eflags & EF_MIPS_MACH) == EF_MIPS_MACH_5900) {
+        return "R5900";
+    }
     return "24Kf";
 }
 #endif
-- 
2.16.4

[Qemu-devel] [PATCH v7 7/7] elf: Toshiba/Sony rather than MIPS are the implementors of the R5900

[Fredrik Noring]

Sources [1][2] indicate that the Emotion Engine was designed by Toshiba
and licensed to Sony. Others [3][4][5] claim it was a joint effort. It
therefore makes sense to refer to the CPU as "Toshiba/Sony R5900".

[1] http://cs.nyu.edu/courses/spring02/V22.0480-002/projects/aldrich/emotionengine.ppt
[2] http://archive.arstechnica.com/reviews/1q00/playstation2/m-ee-3.html
[3] http://docencia.ac.upc.edu/ETSETB/SEGPAR/microprocessors/emotionengine%20(mpr).pdf
[4] http://www.eetimes.com/document.asp?doc_id=1144055
[5] https://www.toshiba.co.jp/about/press/2001_09/pr2701.htm

Reported-by: Maciej W. Rozycki <macro@linux-mips.org>
Signed-off-by: Fredrik Noring <noring@nocrew.org>
Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
---
 include/elf.h | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/include/elf.h b/include/elf.h
index 312f68af81..2510fc7be4 100644
--- a/include/elf.h
+++ b/include/elf.h
@@ -76,7 +76,7 @@ typedef int64_t  Elf64_Sxword;
 #define EF_MIPS_MACH_OCTEON2  0x008d0000  /* Cavium Networks Octeon2         */
 #define EF_MIPS_MACH_OCTEON3  0x008e0000  /* Cavium Networks Octeon3         */
 #define EF_MIPS_MACH_5400     0x00910000  /* NEC VR5400                      */
-#define EF_MIPS_MACH_5900     0x00920000  /* MIPS R5900                      */
+#define EF_MIPS_MACH_5900     0x00920000  /* Toshiba/Sony R5900              */
 #define EF_MIPS_MACH_5500     0x00980000  /* NEC VR5500                      */
 #define EF_MIPS_MACH_9000     0x00990000  /* PMC-Sierra's RM9000             */
 #define EF_MIPS_MACH_LS2E     0x00a00000  /* ST Microelectronics Loongson 2E */
-- 
2.16.4

Re: [Qemu-devel] [PATCH v7 1/7] target/mips: Define R5900 instructions and CPU preprocessor constants

[Philippe Mathieu-Daudé]

On Sat, Oct 13, 2018 at 1:10 PM Fredrik Noring <noring@nocrew.org> wrote:
>
> The R5900 implements the 64-bit MIPS III instruction set except DMULT,
> DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD. The MIPS IV instructions MOVN,
> MOVZ and PREF are implemented. It has the R5900 specific three-operand
> instructions MADD, MADDU, MULT and MULTU as well as pipeline 1 versions
> MULT1, MULTU1, DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and
> MTLO1. A set of 93 128-bit multimedia instructions specific to the
> R5900 is also implemented.
>
> The Toshiba TX System RISC TX79 Core Architecture manual
>
> http://www.lukasz.dk/files/tx79architecture.pdf

Also available on https://wiki.qemu.org/File:C790.pdf

>
> describes the C790 processor that is a follow-up to the R5900. There
> are a few notable differences in that the R5900 FPU
>
> - is not IEEE 754-1985 compliant,
> - does not implement double format, and
> - its machine code is nonstandard.
>
> Signed-off-by: Fredrik Noring <noring@nocrew.org>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  target/mips/mips-defs.h | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/target/mips/mips-defs.h b/target/mips/mips-defs.h
> index c8e99791ad..76550de2da 100644
> --- a/target/mips/mips-defs.h
> +++ b/target/mips/mips-defs.h
> @@ -53,6 +53,7 @@
>  #define   ASE_MSA       0x01000000
>
>  /* Chip specific instructions. */
> +#define         INSN_R5900       0x10000000
>  #define                INSN_LOONGSON2E  0x20000000
>  #define                INSN_LOONGSON2F  0x40000000
>  #define                INSN_VR54XX     0x80000000
> @@ -63,6 +64,7 @@
>  #define                CPU_MIPS3       (CPU_MIPS2 | ISA_MIPS3)
>  #define                CPU_MIPS4       (CPU_MIPS3 | ISA_MIPS4)
>  #define                CPU_VR54XX      (CPU_MIPS4 | INSN_VR54XX)
> +#define         CPU_R5900       (CPU_MIPS3 | INSN_R5900)
>  #define                CPU_LOONGSON2E  (CPU_MIPS3 | INSN_LOONGSON2E)
>  #define                CPU_LOONGSON2F  (CPU_MIPS3 | INSN_LOONGSON2F)
>
> --
> 2.16.4
>

Re: [Qemu-devel] [PATCH v7 7/7] elf: Toshiba/Sony rather than MIPS are the implementors of the R5900

[Aleksandar Markovic]

> From: Fredrik Noring <noring@nocrew.org>
> Sent: Saturday, October 13, 2018 1:11 PM
> To: Aleksandar Markovic; Maciej W. Rozycki; Philippe Mathieu-Daudé
> Cc: Richard Henderson; Aurelien Jarno; Petar Jovanovic; Peter Maydell; Jürgen Urban; > qemu-devel@nongnu.org
> Subject: [PATCH v7 7/7] elf: Toshiba/Sony rather than MIPS are the implementors of the > R5900
> 

Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com>

This patch will be applied to the next MIPS queue, perhaps in a slightly
modified form. The queue is planned to be created very soon.

> Sources [1][2] indicate that the Emotion Engine was designed by Toshiba
> and licensed to Sony. Others [3][4][5] claim it was a joint effort. It
> therefore makes sense to refer to the CPU as "Toshiba/Sony R5900".
> 
> [1] http://cs.nyu.edu/courses/spring02/V22.0480-002/projects/aldrich/emotionengine.ppt
> [2] http://archive.arstechnica.com/reviews/1q00/playstation2/m-ee-3.html
> [3] http://docencia.ac.upc.edu/ETSETB/SEGPAR/microprocessors/emotionengine%20(mpr).pdf
> [4] http://www.eetimes.com/document.asp?doc_id=1144055
> [5] https://www.toshiba.co.jp/about/press/2001_09/pr2701.htm
> 
> Reported-by: Maciej W. Rozycki <macro@linux-mips.org>
> Signed-off-by: Fredrik Noring <noring@nocrew.org>
> Reviewed-by: Philippe Mathieu-Daudé <f4bug@amsat.org>
> ---
>  include/elf.h | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/include/elf.h b/include/elf.h
> index 312f68af81..2510fc7be4 100644
> --- a/include/elf.h
> +++ b/include/elf.h
> @@ -76,7 +76,7 @@ typedef int64_t  Elf64_Sxword;
>  #define EF_MIPS_MACH_OCTEON2  0x008d0000  /* Cavium Networks Octeon2         */
>  #define EF_MIPS_MACH_OCTEON3  0x008e0000  /* Cavium Networks Octeon3         */
>  #define EF_MIPS_MACH_5400     0x00910000  /* NEC VR5400                      */
> -#define EF_MIPS_MACH_5900     0x00920000  /* MIPS R5900                      */
> +#define EF_MIPS_MACH_5900     0x00920000  /* Toshiba/Sony R5900              */
>  #define EF_MIPS_MACH_5500     0x00980000  /* NEC VR5500                      */
>  #define EF_MIPS_MACH_9000     0x00990000  /* PMC-Sierra's RM9000             */
>  #define EF_MIPS_MACH_LS2E     0x00a00000  /* ST Microelectronics Loongson 2E */
> --
> 2.16.4
> 
> 

Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900

[Aleksandar Markovic]

> From: Fredrik Noring <noring@nocrew.org>
> Sent: Saturday, October 13, 2018 1:09 PM
> To: Aleksandar Markovic; Maciej W. Rozycki; Philippe Mathieu-Daudé
> Cc: Richard Henderson; Aurelien Jarno; Petar Jovanovic; Peter Maydell; Jürgen Urban; > qemu-devel@nongnu.org
> Subject: [PATCH v7 0/7] target/mips: Limited support for the R5900
> 
> The primary purpose of these changes is to support programs compiled
> by GCC for the R5900 target and thereby run R5900 Linux distributions,
> for example Gentoo.
> 

Hello, Fredrik.

Your series is getting better and better with each version, which is very good. For a change, I don't have any objection about the title. :) Patch 7 will be integrated shortly in the MIPS queue, you don't need to worry about it. With this series you are not only supporting your prime use case, but you are introducing a new instruction set to QEMU. Try to step back and get wider perspective. No matter how limited the support for the new ISA is, its introduction to QEMU must have following elements:

(1) Definition of basic preprocessor constants for the new ISA.
(2) All opcodes for the ISA.
(3) Basic decoding engine for new instructions.

Your patch 1 adresses 1). However, there are no patches for (2) and (3) in this series. Let me walk though the details on how to implement (2) and (3).

(2) All opcodes for the ISA.

Only if an R5900 instruction has the same name, opcode, and functionality, corresponding MIPS III/IV opcode can and must be reused for R5900. For all other cases, R5900-specific opcode must be supplied. I'll limit further consideration to MMI instructions, but you should consider the whole R5900 instruction set.

For MMI instruction, there should be a patch "target/mips: Add R5900 Emotion Engine MMI instruction opcodes" that adds following code segment:

/*
 *  Emotion Engine MMI instruction set opcodes
 *  ==========================================
 */

#define EE_CLASS_MMI        0x1C    /* the same as OPC_SPECIAL2 */

/*
 *  MMI instruction class
 *
 *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 *  +-----------+---------+---------+---------+---------+-----------+
 *  | CLASS_MMI |         |         |         |         |   opcode  |
 *  +-----------+---------+---------+---------+---------+-----------+
 */

#define EE_MMI_MADD         0x00
#define EE_MMI_MADDU        0x01
#define EE_MMI_PLZCW        0x04
#define EE_MMI_CLASS_MMI0   0x08
#define EE_MMI_CLASS_MMI2   0x09
#define EE_MMI_MFHI1        0x10
#define EE_MMI_MTHI1        0x11
#define EE_MMI_MFLO1        0x12
#define EE_MMI_MTLO1        0x13
#define EE_MMI_MULT1        0x18
#define EE_MMI_MULTU1       0x19
#define EE_MMI_DIV1         0x1a
#define EE_MMI_DIVU1        0x1b
#define EE_MMI_MADD1        0x20
#define EE_MMI_MADDU1       0x21
#define EE_MMI_CLASS_MMI1   0x28
#define EE_MMI_CLASS_MMI3   0x29
#define EE_MMI_PMFHL        0x30
#define EE_MMI_PMTHL        0x31
#define EE_MMI_PSLLH        0x34
#define EE_MMI_PSRLH        0x36
#define EE_MMI_PSRAH        0x37
#define EE_MMI_PSLLW        0x3c
#define EE_MMI_PSRLW        0x3e
#define EE_MMI_PSRAW        0x3f

/*
 *  MMI0 instruction class
 *
 *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 *  +-----------+---------+---------+---------+---------+-----------+
 *  | CLASS_MMI |         |         |         |  opcode | CLASS_MMI0|
 *  +-----------+---------+---------+---------+---------+-----------+
 */

#define EE_MMI0_PADDW       0x00
#define EE_MMI0_PSUBW       0x01
#define EE_MMI0_PCGTW       0x02
#define EE_MMI0_PMAXW       0x03
#define EE_MMI0_PADDH       0x04
#define EE_MMI0_PSUBH       0x05
#define EE_MMI0_PCGTH       0x06
#define EE_MMI0_PMAXH       0x07
#define EE_MMI0_PADDB       0x08
#define EE_MMI0_PSUBB       0x09
#define EE_MMI0_PCGTB       0x0a
#define EE_MMI0_PADDSW      0x10
#define EE_MMI0_PSUBSW      0x11
#define EE_MMI0_PEXTLW      0x12
#define EE_MMI0_PPACW       0x13
#define EE_MMI0_PADDSH      0x14
#define EE_MMI0_PSUBSH      0x15
#define EE_MMI0_PEXTLH      0x16
#define EE_MMI0_PPACH       0x17
#define EE_MMI0_PADDSB      0x18
#define EE_MMI0_PSUBSB      0x19
#define EE_MMI0_PEXTLB      0x1a
#define EE_MMI0_PPACB       0x1b
#define EE_MMI0_PEXT5       0x1e
#define EE_MMI0_PPAC5       0x1f

/*
 *  MMI1 instruction class
 *
 *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 *  +-----------+---------+---------+---------+---------+-----------+
 *  | CLASS_MMI |         |         |         |  opcode | CLASS_MMI1|
 *  +-----------+---------+---------+---------+---------+-----------+
 */

#define EE_MMI1_PABSW       0x01
#define EE_MMI1_PCEQW       0x02
#define EE_MMI1_PMINW       0x03
#define EE_MMI1_PADSBH      0x04
#define EE_MMI1_PABSH       0x05
#define EE_MMI1_PCEQH       0x06
#define EE_MMI1_PMINH       0x07
#define EE_MMI1_PCEQB       0x0a
#define EE_MMI1_PADDUW      0x10
#define EE_MMI1_PSUBUW      0x11
#define EE_MMI1_PEXTUW      0x12
#define EE_MMI1_PADDUH      0x14
#define EE_MMI1_PSUBUH      0x15
#define EE_MMI1_PEXTUH      0x16
#define EE_MMI1_PADDUB      0x18
#define EE_MMI1_PSUBUB      0x19
#define EE_MMI1_PEXTUB      0x1a
#define EE_MMI1_QFSRV       0x1b

/*
 *  MMI2 instruction class
 *
 *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 *  +-----------+---------+---------+---------+---------+-----------+
 *  | CLASS_MMI |         |         |         |  opcode | CLASS_MMI2|
 *  +-----------+---------+---------+---------+---------+-----------+
 */

#define EE_MMI2_PMADDW      0x00
#define EE_MMI2_PSLLVW      0x02
#define EE_MMI2_PSRLVW      0x03
#define EE_MMI2_PMSUBW      0x04
#define EE_MMI2_PMFHI       0x08
#define EE_MMI2_PMFLO       0x09
#define EE_MMI2_PINTH       0x0a
#define EE_MMI2_PMULTW      0x0c
#define EE_MMI2_PDIVW       0x0d
#define EE_MMI2_PCPYLD      0x0e
#define EE_MMI2_PMADDH      0x10
#define EE_MMI2_PHMADH      0x11
#define EE_MMI2_PAND        0x12
#define EE_MMI2_PXOR        0x13
#define EE_MMI2_PMSUBH      0x14
#define EE_MMI2_PHMSBH      0x15
#define EE_MMI2_PEXEH       0x1a
#define EE_MMI2_PREVH       0x1b
#define EE_MMI2_PMULTH      0x1c
#define EE_MMI2_PDIVBW      0x1d
#define EE_MMI2_PEXEW       0x1e
#define EE_MMI2_PROT3W      0x1f

/*
 *  MMI3 instruction class
 *
 *   1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
 *  +-----------+---------+---------+---------+---------+-----------+
 *  | CLASS_MMI |         |         |         |  opcode | CLASS_MMI3|
 *  +-----------+---------+---------+---------+---------+-----------+
 */

#define EE_MMI3_PMADDUW     0x00
#define EE_MMI3_PSRAVW      0x03
#define EE_MMI3_PMTHI       0x08
#define EE_MMI3_PMTLO       0x09
#define EE_MMI3_PINTEH      0x0a
#define EE_MMI3_PMULTUW     0x0c
#define EE_MMI3_PDIVUW      0x0d
#define EE_MMI3_PCPYUD      0x0e
#define EE_MMI3_POR         0x12
#define EE_MMI3_PNOR        0x13
#define EE_MMI3_PEXCH       0x1a
#define EE_MMI3_PCPYH       0x1b
#define EE_MMI3_PEXCW       0x1e

(This is just a suggestion, the organization and naming of course can be different; double-check accuracy of opcodes)



(3) Basic decoding engine for new instructions.

As you can notice, MMI opcodes occupy the same space as OPC_SPECIAL2. So this segment from translate.c:

    case OPC_SPECIAL2:
        decode_opc_special2_legacy(env, ctx);
        break;

should become something like this:

    case OPC_SPECIAL2:
        if(ctx->insn_flags & INSN_R5900) {
            decode_ee_mmi(env, ctx);
        } else {}
            decode_opc_special2_legacy(env, ctx);
        }
        break;

where decode_ee_mmi() is defined by yourself as something like this:


static void decode_ee_mmi(CPUMIPSState *env, DisasContext *ctx)
{
    uint32_t opcode = extract32(ctx->opcode, 6, 0);

    switch(opcode) {
    
    case EE_MMI_MADD:
        /* TODO: Implement emulation of EE_MMI_MADD */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MADDU:
        /* TODO: Implement emulation of EE_MMI_MADDU */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PLZCW:
        /* TODO: Implement emulation of EE_MMI_PLZCW */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_CLASS_MMI0:
        decode_ee_mmi0(env, ctx);
        break; 
    case EE_MMI_CLASS_MMI2:
        decode_ee_mmi2(env, ctx);
        break; 
    case EE_MMI_MFHI1:
        /* TODO: Implement emulation of EE_MMI_MFHI1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MTHI1:
        /* TODO: Implement emulation of EE_MMI_MTHI1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MFLO1:
        /* TODO: Implement emulation of EE_MMI_MFLO1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MTLO1:
        /* TODO: Implement emulation of EE_MMI_MTLO1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MULT1:
        /* TODO: Implement emulation of EE_MMI_MULT1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MULTU1:
        /* TODO: Implement emulation of EE_MMI_MULTU1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_DIV1:
        /* TODO: Implement emulation of EE_MMI_DIV1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_DIVU1:
        /* TODO: Implement emulation of EE_MMI_DIVU1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MADD1:
        /* TODO: Implement emulation of EE_MMI_MADD1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_MADDU1:
        /* TODO: Implement emulation of EE_MMI_MADDU1 */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_CLASS_MMI1:
        decode_ee_mmi1(env, ctx);
        break; 
    case EE_MMI_CLASS_MMI3:
        decode_ee_mmi3(env, ctx);
        break; 
    case EE_MMI_PMFHL:
        /* TODO: Implement emulation of EE_MMI_PMFHL */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PMTHL:
        /* TODO: Implement emulation of EE_MMI_PMTHL */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PSLLH:
        /* TODO: Implement emulation of EE_MMI_PSLLH */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PSRLH:
        /* TODO: Implement emulation of EE_MMI_PSRLH */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PSRAH:
        /* TODO: Implement emulation of EE_MMI_PSRAH */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PSLLW:
        /* TODO: Implement emulation of EE_MMI_PSLLW */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PSRLW:
        /* TODO: Implement emulation of EE_MMI_PSRLW */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    case EE_MMI_PSRAW:
        /* TODO: Implement emulation of EE_MMI_PSRAW */
        generate_exception_end(ctx, EXCP_RI);
        break; 
    default:
        generate_exception_end(ctx, EXCP_RI);
        break; 
    }

Of course, you need to specify functions decode_ee_mmi0(), decode_ee_mmi1(), decode_ee_mmi2(), and decode_ee_mmi3() too.

You can change format and naming in the code above, but I insist that each unimplemeted instuction has its own "TODO" and "generate_exception()".

Please focus on the elements I presented in this email. They are necessary to complete this patch series.

Keep MMI changes described above in two separate patches. You'll need probably several such pairs to cover the whole R5900.

FPU opcodes need such treatment too. This will affect your overall solution, hopefully it will be better after the reorganization.

Thanks,
Aleksandar


> GCC in version 7.3, by itself, by inspection of the GCC source code
> and inspection of the generated machine code, for the R5900 target,
> only emits two instructions that are specific to the R5900: the three-
> operand MULT and MULTU. GCC and libc also emit certain MIPS III
> instructions that are not part of the R5900 ISA. They are normally
> trapped and emulated by the Linux kernel, and therefore need to be
> treated accordingly by QEMU. This is addressed, in turn, by the
> patch series.
> 
> A program compiled by GCC is taken to mean source code compiled by GCC
> under the restrictions above. One can, with the apparent limitations,
> with a bit of effort obtain a fully functioning operating system such
> as R5900 Gentoo. Strictly speaking, programs need not be compiled by
> GCC to make use of this change.
> 
> Instructions and other facilities of the R5900 not implemented by these
> changes are intended to signal provisional exceptions. One such example
> is the FPU that is not compliant with IEEE 754-1985 in system mode. It
> is therefore provisionally disabled. In user space the FPU is trapped
> and emulated by IEEE 754-1985 compliant software in the kernel, and
> this is handled accordingly by QEMU. Another example is the 93
> multimedia instructions specific to the R5900 that generate provisional
> reserved instruction exception signals.
> 
> One of the benefits of running a Linux distribution under QEMU is that
> programs can be compiled with a native compiler, where the host and
> target are the same, as opposed to a cross-compiler, where they are
> not the same. This is especially important in cases where the target
> hardware does not have the resources to run a native compiler.
> 
> Problems with cross-compilation are often related to host and target
> differences in integer sizes, pointer sizes, endianness, machine code,
> ABI, etc. Sometimes cross-compilation is not even supported by the
> build script for a given package. One effective way to avoid those
> problems is to replace the cross-compiler with a native compiler. This
> change of compilation methods does not resolve the inherent problems
> with cross-compilation.
> 
> The native compiler naturally replaces the cross-compiler, because one
> typically uses one or the other, and preferably the native compiler
> when the circumstances admit this. The native compiler is also a good
> test case for the R5900 QEMU user mode. Additionally, Gentoo is well-
> known for compiling and installing its packages from sources.
> 
> This change has been tested with Gentoo compiled for R5900, including
> native compilation of several packages under QEMU. I used the Gentoo
> sys-devel/crossdev package
> 
> https://wiki.gentoo.org/wiki/Crossdev
> 
> with patches mainly to simplify the handling of LL/SC and floating
> point support, to avoid complications with additional configure and
> compiler flags. Busybox
> 
> https://busybox.net/
> 
> can also be used to build a simple functional R5900 program. It can be
> used to test the R5900 CPU in QEMU user mode.
> 
> The R5900 implements the 64-bit MIPS III instruction set except DMULT,
> DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD. The MIPS IV instructions MOVN,
> MOVZ and PREF are implemented. It has the R5900 specific three-operand
> instructions MADD, MADDU, MULT and MULTU as well as pipeline 1 versions
> MULT1, MULTU1, DIV1, DIVU1, MADD1, MADDU1, MFHI1, MFLO1, MTHI1 and
> MTLO1. A set of 93 128-bit multimedia instructions specific to the
> R5900 is also implemented.
> 
> The Toshiba TX System RISC TX79 Core Architecture manual
> 
> http://www.lukasz.dk/files/tx79architecture.pdf
> 
> describes the C790 processor that is a follow-up to the R5900. There
> are a few notable differences in that the R5900 FPU
> 
> - is not IEEE 754-1985 compliant,
> - does not implement double format, and
> - its machine code is nonstandard.
> 
> Changes in v7:
> - Rename gen_mul_txxx to gen_mul_txx9
> - Use MIPS_INVAL("mul TXx9")
> - Reviewed-by: Philippe Mathieu-Daudé
> 
> Changes in v6:
> - Set the CP0 PRId implementation number to 0x2E for the R5900
> - Refer to the C790 follow-up in the definition of the R5900
> - Define and use check_insn_opc_user_only in the same change
> - Rename gen_mul_r5900 to gen_mul_txxx
> - Enclose single statements in braces
> - Expand and reword commit messages and notes
> - Reword the cover letter subject line
> - All changes build with GCC and Clang
> - Approval from checkpatch.pl
> 
> Changes in v5:
> - Reorder check_insn_opc_user_only calls
> - Call check_insn_opc_removed in check_insn_opc_user_only
> 
> Changes in v4:
> - Split into a patch series consting of eight changes
> - Expand commit messages and notes
> - Introduce check_insn_opc_user_only
> - Base R5900 on MIPS III, with MOVN, MOVZ and PREF from MIPS IV
> - DMULT, DMULTU, DDIV, DDIVU, LL, SC, LLD and SCD are user only
> - Note Toshiba/Sony R5900 for EF_MIPS_MACH_R5900 definition
> - Rework gen_mul_r5900
> - Fix ICE and DCE
> - Fix SEGBITS and PABITS
> - Fix indentation
> 
> Changes in v3:
> - Apply to HEAD
> - Remove the word "initial" from subject line
> 
> Changes in v2:
> - Update mips_defs array with R5900 values
> - LL/SC and FPU are user only
> 
> Fredrik Noring (7):
>   target/mips: Define R5900 instructions and CPU preprocessor constants
>   target/mips: Support R5900 specific three-operand MULT and MULTU
>   target/mips: Support R5900 instructions MOVN, MOVZ and PREF from MIPS IV
>   target/mips: R5900 DMULT[U], DDIV[U], LL[D] and SC[D] are user only
>   target/mips: Define the R5900 CPU
>   linux-user/mips: Recognise the R5900 CPU model
>   elf: Toshiba/Sony rather than MIPS are the implementors of the R5900
> 
>  include/elf.h                    |   2 +-
>  linux-user/mips/target_elf.h     |   3 ++
>  target/mips/mips-defs.h          |   2 +
>  target/mips/translate.c          | 101 +++++++++++++++++++++++++++++++++++++--
>  target/mips/translate_init.inc.c |  59 +++++++++++++++++++++++
>  5 files changed, 163 insertions(+), 4 deletions(-)
> 
> --
> 2.16.4
> 
> 

Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900

[Laurent Vivier]

Le 15/10/2018 à 14:16, Aleksandar Markovic a écrit :
>> From: Fredrik Noring <noring@nocrew.org>
>> Sent: Saturday, October 13, 2018 1:09 PM
>> To: Aleksandar Markovic; Maciej W. Rozycki; Philippe Mathieu-Daudé
>> Cc: Richard Henderson; Aurelien Jarno; Petar Jovanovic; Peter Maydell; Jürgen Urban; > qemu-devel@nongnu.org
>> Subject: [PATCH v7 0/7] target/mips: Limited support for the R5900
>>
>> The primary purpose of these changes is to support programs compiled
>> by GCC for the R5900 target and thereby run R5900 Linux distributions,
>> for example Gentoo.
>>
> 
> Hello, Fredrik.
> 
> Your series is getting better and better with each version, which is very good. For a change, I don't have any objection about the title. :) Patch 7 will be integrated shortly in the MIPS queue, you don't need to worry about it. With this series you are not only supporting your prime use case, but you are introducing a new instruction set to QEMU. Try to step back and get wider perspective. No matter how limited the support for the new ISA is, its introduction to QEMU must have following elements:
> 
> (1) Definition of basic preprocessor constants for the new ISA.
> (2) All opcodes for the ISA.
> (3) Basic decoding engine for new instructions.
> 
> Your patch 1 adresses 1). However, there are no patches for (2) and (3) in this series. Let me walk though the details on how to implement (2) and (3).
> 
> (2) All opcodes for the ISA.

As Fredrik only wants to use R5900 gentoo userland binaries using qemu
linux-user mode, does he really need to implement all the opcodes of the
ISA?

Most of the architectures have started with only the userland
instruction set, and the privileged instruction set was added once this
part was validated (see the risu project
https://wiki.linaro.org/PeterMaydell/Risu). It was really helpful for me
to add the m680x0 processor emulation in QEMU by this way (I've added
FPU and MMU later)

It can be a lot of work to add all the opcodes for the ISA, and be very
time consuming, and Fredrik has only test case for the opcode he has
implemented, the rest of the ISA will not be tested, or will need more
work from him.

So perhaps a not fully implemented R5900 ISA (with big WARNINGs in the
code, and perhaps assert()?) would be better than nothing at all?

Thanks,
Laurent

Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900

[Aleksandar Markovic]

> From: Laurent Vivier <laurent@vivier.eu>
> Sent: Friday, October 19, 2018 3:28 PM
> Subject: Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900
> 
> Le 15/10/2018 à 14:16, Aleksandar Markovic a écrit :
> >> From: Fredrik Noring <noring@nocrew.org>
> >> Sent: Saturday, October 13, 2018 1:09 PM
> >> To: Aleksandar Markovic; Maciej W. Rozycki; Philippe Mathieu-Daudé
> >> Cc: Richard Henderson; Aurelien Jarno; Petar Jovanovic; Peter Maydell; Jürgen Urban; > > qemu-devel@nongnu.org
> >> Subject: [PATCH v7 0/7] target/mips: Limited support for the R5900
> >>
> >> The primary purpose of these changes is to support programs compiled
> >> by GCC for the R5900 target and thereby run R5900 Linux distributions,
> >> for example Gentoo.
> >>
> >
> > Hello, Fredrik.
> >
> > Your series is getting better and better with each version, which is very good. For a change,
> > I don't have any objection about the title. :) Patch 7 will be integrated shortly in the MIPS
> > queue, you don't need to worry about it. With this series you are not only supporting your 
> > prime use case, but you are introducing a new instruction set to QEMU. Try to step back and get
> > wider perspective. No matter how limited the support for the new ISA is, its introduction to
> > QEMU must have following elements:
> >
> > (1) Definition of basic preprocessor constants for the new ISA.
> > (2) All opcodes for the ISA.
> > (3) Basic decoding engine for new instructions.
> >
> > Your patch 1 adresses 1). However, there are no patches for (2) and (3) in this series. Let > me walk though the details on how to implement (2) and (3).
> >
> > (2) All opcodes for the ISA.
> 
> As Fredrik only wants to use R5900 gentoo userland binaries using qemu
> linux-user mode, does he really need to implement all the opcodes of the
> ISA?
>

It should be clear from my previous mail, but this is what I meant by (2) and (3):

(2) A list of all R5900 instructions not covered by MIPS III/IV, in the form of '#defines' or enum elements, logically clustered.

(3) A set of functions (in my estimation, around a dozen of them is needed), each containing a switch statement with cases for individual instructions, each case containing only "TODO" comment and raising EXCP_RI. Of course, all such function should be interconnected and integrated with the rest of MIPS code according to the R5900 doc.

In my view, it is really a stretch that this is 'very time consuming'. True, it does require focus and meticulousness.

My impression is that Fridrik understood my guidance correctly. Fridrik, please let me know if you need clarification of any kind.

Sincerely,
Aleksandar


> Most of the architectures have started with only the userland
> instruction set, and the privileged instruction set was added once this
> part was validated (see the risu project
> https://wiki.linaro.org/PeterMaydell/Risu). It was really helpful for me
> to add the m680x0 processor emulation in QEMU by this way (I've added
> FPU and MMU later)
> 
> It can be a lot of work to add all the opcodes for the ISA, and be very
> time consuming, and Fredrik has only test case for the opcode he has
> implemented, the rest of the ISA will not be tested, or will need more
> work from him.
> 
> So perhaps a not fully implemented R5900 ISA (with big WARNINGs in the
> code, and perhaps assert()?) would be better than nothing at all?
> 
> Thanks,
> Laurent
> 
> 
> 

Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900

[Fredrik Noring]

Hi Aleksandar,

> Your series is getting better and better with each version, which is very
> good. For a change, I don't have any objection about the title. :)

Good!

> Patch 7 will be integrated shortly in the MIPS queue, you don't need to
> worry about it.

Thanks!

> With this series you are not only supporting your prime use case, but you
> are introducing a new instruction set to QEMU. Try to step back and get
> wider perspective. No matter how limited the support for the new ISA is,
> its introduction to QEMU must have following elements:
> 
> (1) Definition of basic preprocessor constants for the new ISA.
> (2) All opcodes for the ISA.
> (3) Basic decoding engine for new instructions.
> 
> Your patch 1 adresses 1). However, there are no patches for (2) and (3) in
> this series. Let me walk though the details on how to implement (2) and (3).

Thank you for your detailed description, it was helpful.

> (2) All opcodes for the ISA.
> 
> Only if an R5900 instruction has the same name, opcode, and functionality,
> corresponding MIPS III/IV opcode can and must be reused for R5900. For all
> other cases, R5900-specific opcode must be supplied. I'll limit further
> consideration to MMI instructions, but you should consider the whole R5900
> instruction set.

I'm preparing v8 with (2) and (3) and other changes, to be posted shortly.

> Of course, you need to specify functions decode_ee_mmi0(),
> decode_ee_mmi1(), decode_ee_mmi2(), and decode_ee_mmi3() too.

Done.

> You can change format and naming in the code above, but I insist that each
> unimplemeted instuction has its own "TODO" and "generate_exception()".

They have TODOs, but it turns out that having individual generate_exception
calls is somewhat impractical, because instructions are typically grouped
and folded into other functions in various ways. I think this is reasonable
evident when looking at how the v8 patch series develops.

> FPU opcodes need such treatment too. This will affect your overall
> solution, hopefully it will be better after the reorganization.

I'm not sure whether the R5900 FPU opcode anomalies are documented. I will
have to investigate this.

Fredrik