| Message ID | e8e6bfd053f051d5195ec030f06749b24f867b13.1541616663.git.noring@nocrew.org |
|---|---|
| State | New |
| Headers | show |
| Series | Fix decoding mechanisms of the R5900 | expand |
> > From: Fredrik Noring <noring@nocrew.org> > Subject: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes > > MOVN, MOVZ, MFHI, MFLO, MTHI, MTLO, MULT, MULTU, DIV, DIVU, DMULT, > DMULTU, DDIV, DDIVU and JR are decoded in decode_opc_special_tx79 > instead of the generic decode_opc_special_legacy. > > Signed-off-by: Fredrik Noring <noring@nocrew.org> > --- > target/mips/translate.c | 54 ++++++++++++++++++++++++++++++++++++++--- > 1 file changed, 50 insertions(+), 4 deletions(-) > > +#if defined(TARGET_MIPS64) > + case OPC_DMULT: > + case OPC_DMULTU: > + case OPC_DDIV: > + case OPC_DDIVU: > + check_insn_opc_user_only(ctx, INSN_R5900); > + gen_muldiv(ctx, op1, 0, rs, rt); > + break; > +#endif Fredrik, do you know by any chance if a document exists that would justify inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by gcc for R5900? Is it included by cross-gcc or by native gcc, or by both? I think gcc folks must have had a good reason for that, some kind of design - it can't be 'I really like/miss this instruction, let's include it...' Thanks, Aleksandar
Hi Aleksandar, > Fredrik, do you know by any chance if a document exists that would justify > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both? > > I think gcc folks must have had a good reason for that, some kind of > design - it can't be 'I really like/miss this instruction, let's include > it...' The R5900 reports itself as MIPS III and DMULT, DMULTU, DDIV and DDIVU are part of the MIPS III ISA. They are emulated in user mode to support generic MIPS III programs. I have now obtained an R5900 n32 ABI toolchain. R5900 n32 ABI emulation support is recognised with http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01609.html and a test of DMULT emulation is available with http://lists.nongnu.org/archive/html/qemu-devel/2018-11/msg01610.html Fredrik
On Thu, 8 Nov 2018, Fredrik Noring wrote: > > Fredrik, do you know by any chance if a document exists that would justify > > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by > > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both? > > > > I think gcc folks must have had a good reason for that, some kind of > > design - it can't be 'I really like/miss this instruction, let's include > > it...' > > The R5900 reports itself as MIPS III and DMULT, DMULTU, DDIV and DDIVU > are part of the MIPS III ISA. They are emulated in user mode to support > generic MIPS III programs. FAOD, GCC does not emit these instructions if the R5900 architecture has been selected for compilation, e.g.: /* ISA supports instructions DMULT and DMULTU. */ #define ISA_HAS_DMULT (TARGET_64BIT \ && !TARGET_MIPS5900 \ && mips_isa_rev <= 5) however they are a part of the base 64-bit MIPS Linux user psABI, which is the whole of the MIPS III ISA, so the runtime has to support them one way or another (just like LL, SC and SYNC are a part of the 32-bit MIPS Linux user psABI even though they are not supported by MIPS I hardware). Maciej
> From: Fredrik Noring <noring@nocrew.org> > Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes > > Hi Aleksandar, > > > Fredrik, do you know by any chance if a document exists that would justify > > inclusion of non-R5900 DMULT, DMULTU, DDIV, DDIVU in R5900 executables by > > gcc for R5900? Is it included by cross-gcc or by native gcc, or by both? > > > > I think gcc folks must have had a good reason for that, some kind of > > design - it can't be 'I really like/miss this instruction, let's include > > it...' > > The R5900 reports itself as MIPS III ... This is very unclear. What do you mean by this? How does R5900 do that? I can't find any trace of such intentions in R5900 docs. > ... and DMULT, DMULTU, DDIV and DDIVU > are part of the MIPS III ISA. They are emulated in user mode to support > generic MIPS III programs. Pure MIPS III executables should not be a concern of the R5900 emulation, but R5900 executables. Could you please provide a document that would justify inclusion of these non-R5900 instruction in an R5900 emulation? Thanks, Aleksandar
Hi Aleksandar, > > The R5900 reports itself as MIPS III ... > > This is very unclear. What do you mean by this? How does R5900 do that? I > can't find any trace of such intentions in R5900 docs. In QEMU, we have previously defined the R5900 as MIPS III by #define CPU_R5900 (CPU_MIPS3 | INSN_R5900) by referring to the "Toshiba TX System RISC TX79 Core Architecture" manual https://wiki.qemu.org/File:C790.pdf It says in the introduction, for example, that 3.1 Introduction The C790 supports all MIPS III instructions with the exception of 64-bit multiply, 64-bit divide, Load Linked and Store Conditional instructions. It also supports a limited number of MIPS IV instructions and additional C790-specific instructions, such as Multiply/Add instructions and multimedia instructions. The manual mentions MIPS III in several other places, and appendix A-1 "CPU Instruction Set Details" describes the implemented MIPS III subset. > > ... and DMULT, DMULTU, DDIV and DDIVU > > are part of the MIPS III ISA. They are emulated in user mode to support > > generic MIPS III programs. > > Pure MIPS III executables should not be a concern of the R5900 emulation, > but R5900 executables. Many Linux distributions rely on precompiled packages, and they are often made to work with a broad range of hardware. This is done in part by choosing a common denominator, such as MIPS III. Compatibility with other implementations means that the R5900 more easily can be part of the MIPS Linux ecosystem. In contrast, Gentoo Linux mainly builds its packages locally from source, often optimised for the hardware, such as the R5900. Even so, Gentoo does rely on a small set of precompiled "stage 3" packages for the installation, and so the argument above still applies. > Could you please provide a document that would justify inclusion of these > non-R5900 instruction in an R5900 emulation? Would you accept the TX79 manual mentioned above as such a document? Fredrik
On Fri, 9 Nov 2018, Aleksandar Markovic wrote: > > ... and DMULT, DMULTU, DDIV and DDIVU > > are part of the MIPS III ISA. They are emulated in user mode to support > > generic MIPS III programs. > > Pure MIPS III executables should not be a concern of the R5900 > emulation, but R5900 executables. I repeat: MIPS III is the available instruction set defined with the base 64-bit MIPS Linux psABI and must not be subsetted. You have to support it in QEMU Linux user emulation mode for any 64-bit MIPS processor and this is not debatable, period. QEMU has no control over the Linux ABI, it has to accept it as it is. Maciej
> From: Fredrik Noring <noring@nocrew.org> > Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes > > > > > Could you please provide a document that would justify inclusion of these > > non-R5900 instruction in an R5900 emulation? > > Would you accept the TX79 manual mentioned above as such a document? > Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not included in R5900 set. I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU in a separate patch - there is no document to support their inclusion. Aleksandar
Hi Aleksandar, > Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not > included in R5900 set. > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU > in a separate patch - there is no document to support their inclusion. As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could your alternative possibly work? Fredrik
> From: Fredrik Noring <noring@nocrew.org> > Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes > > Hi Aleksandar, > > > Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not > > included in R5900 set. > > > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU > > in a separate patch - there is no document to support their inclusion. > > As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could > your alternative possibly work? Provide the document, and then let's talk. Thanks, Aleksandar
> From: Fredrik Noring <noring@nocrew.org> > Subject: Re: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes > > Hi Aleksandar, > > > Tx79 mentions the opposite: that DDIV, DDIVU, DMULT, DMULTU are not > > included in R5900 set. > > > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU > > in a separate patch - there is no document to support their inclusion. > > As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could > your alternative possibly work? Since we are rapidly approaching 3.1 release, we don't have time for prolonged discussions - so please provide the patch that removes emulation of these instructions that don't belong to R5900 set, and, if you find a justification document later on, they can be reintroduced in 3.1+ timeframe. Thanks, Aleksnadar
On Fri, 9 Nov 2018, Aleksandar Markovic wrote: > > > I think that the best solution that you exclude DDIV, DDIVU, DMULT, DMULTU > > > in a separate patch - there is no document to support their inclusion. > > > > As Maciej noted, the 64-bit MIPS Linux psABI is indivisible, so how could > > your alternative possibly work? > > Since we are rapidly approaching 3.1 release, we don't have time for > prolonged discussions - so please provide the patch that removes > emulation of these instructions that don't belong to R5900 set, and, if > you find a justification document later on, they can be reintroduced in > 3.1+ timeframe. You know well enough that nobody was bothered over the years to actually document the 64-bit MIPS Linux psABI (there is the 64-bit ELF document from SGI, relevant for IRIX, which has been partially implemented by Linux) and even when it comes to the 32-bit psABI the only document is from SGI from mid 1990s, that has several errors and surely was not written with Linux in mind (and FWIW not entirely with IRIX either). The psABI has been set by the architecture back in 1991 and what Linux has implemented on top of that around 2001, along with common sense. You can't question what was done 17 years ago asking for a backing piece of paper (possibly virtual). You can put anything on paper and if it does not match reality, then it is irrelevant. If you question what I state, then ask the MIPS/Linux kernel developers at the relevant mailing list, i.e. <linux-mips@linux-mips.org>. Maciej
> From: Fredrik Noring <noring@nocrew.org> > Subject: [PATCH v2 4/6] target/mips: Fix decoding mechanism of special R5900 opcodes > > MOVN, MOVZ, MFHI, MFLO, MTHI, MTLO, MULT, MULTU, DIV, DIVU, DMULT, > DMULTU, DDIV, DDIVU and JR are decoded in decode_opc_special_tx79 > instead of the generic decode_opc_special_legacy. > > Signed-off-by: Fredrik Noring <noring@nocrew.org> > --- Reviewed-by: Aleksandar Markovic <amarkovic@wavecomp.com> with caveat that this should be resolved in 3.1+.
diff --git a/target/mips/translate.c b/target/mips/translate.c index 19ae7d2f1c..45ad70c097 100644 --- a/target/mips/translate.c +++ b/target/mips/translate.c @@ -23835,6 +23835,53 @@ static void decode_opc_special_r6(CPUMIPSState *env, DisasContext *ctx) } } +static void decode_opc_special_tx79(CPUMIPSState *env, DisasContext *ctx) +{ + int rs = extract32(ctx->opcode, 21, 5); + int rt = extract32(ctx->opcode, 16, 5); + int rd = extract32(ctx->opcode, 11, 5); + uint32_t op1 = MASK_SPECIAL(ctx->opcode); + + switch (op1) { + case OPC_MOVN: /* Conditional move */ + case OPC_MOVZ: + gen_cond_move(ctx, op1, rd, rs, rt); + break; + case OPC_MFHI: /* Move from HI/LO */ + case OPC_MFLO: + gen_HILO(ctx, op1, 0, rd); + break; + case OPC_MTHI: + case OPC_MTLO: /* Move to HI/LO */ + gen_HILO(ctx, op1, 0, rs); + break; + case OPC_MULT: + case OPC_MULTU: + gen_mul_txx9(ctx, op1, rd, rs, rt); + break; + case OPC_DIV: + case OPC_DIVU: + gen_muldiv(ctx, op1, 0, rs, rt); + break; +#if defined(TARGET_MIPS64) + case OPC_DMULT: + case OPC_DMULTU: + case OPC_DDIV: + case OPC_DDIVU: + check_insn_opc_user_only(ctx, INSN_R5900); + gen_muldiv(ctx, op1, 0, rs, rt); + break; +#endif + case OPC_JR: + gen_compute_branch(ctx, op1, 4, rs, 0, 0, 4); + break; + default: /* Invalid */ + MIPS_INVAL("special_tx79"); + generate_exception_end(ctx, EXCP_RI); + break; + } +} + static void decode_opc_special_legacy(CPUMIPSState *env, DisasContext *ctx) { int rs, rt, rd, sa; @@ -23850,7 +23897,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_R5900); + INSN_LOONGSON2E | INSN_LOONGSON2F); gen_cond_move(ctx, op1, rd, rs, rt); break; case OPC_MFHI: /* Move from HI/LO */ @@ -23877,8 +23924,6 @@ 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, rd, rs, rt); } else { gen_muldiv(ctx, op1, rd & 3, rs, rt); } @@ -23893,7 +23938,6 @@ 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; @@ -24120,6 +24164,8 @@ static void decode_opc_special(CPUMIPSState *env, DisasContext *ctx) default: if (ctx->insn_flags & ISA_MIPS32R6) { decode_opc_special_r6(env, ctx); + } else if (ctx->insn_flags & INSN_R5900) { + decode_opc_special_tx79(env, ctx); } else { decode_opc_special_legacy(env, ctx); }
MOVN, MOVZ, MFHI, MFLO, MTHI, MTLO, MULT, MULTU, DIV, DIVU, DMULT, DMULTU, DDIV, DDIVU and JR are decoded in decode_opc_special_tx79 instead of the generic decode_opc_special_legacy. Signed-off-by: Fredrik Noring <noring@nocrew.org> --- target/mips/translate.c | 54 ++++++++++++++++++++++++++++++++++++++--- 1 file changed, 50 insertions(+), 4 deletions(-)