[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R59
From: |
Fredrik Noring |
Subject: |
Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900 |
Date: |
Sun, 21 Oct 2018 16:18:06 +0200 |
User-agent: |
Mutt/1.10.1 (2018-07-13) |
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
- [Qemu-devel] [PATCH v7 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU, (continued)
- [Qemu-devel] [PATCH v7 2/7] target/mips: Support R5900 specific three-operand MULT and MULTU, Fredrik Noring, 2018/10/13
- [Qemu-devel] [PATCH v7 4/7] target/mips: R5900 DMULT[U], DDIV[U], LL[D] and SC[D] are user only, Fredrik Noring, 2018/10/13
- [Qemu-devel] [PATCH v7 3/7] target/mips: Support R5900 instructions MOVN, MOVZ and PREF from MIPS IV, Fredrik Noring, 2018/10/13
- [Qemu-devel] [PATCH v7 6/7] linux-user/mips: Recognise the R5900 CPU model, Fredrik Noring, 2018/10/13
- [Qemu-devel] [PATCH v7 7/7] elf: Toshiba/Sony rather than MIPS are the implementors of the R5900, Fredrik Noring, 2018/10/13
- [Qemu-devel] [PATCH v7 5/7] target/mips: Define the R5900 CPU, Fredrik Noring, 2018/10/13
- Re: [Qemu-devel] [PATCH v7 0/7] target/mips: Limited support for the R5900, Aleksandar Markovic, 2018/10/15