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

[Fredrik Noring <noring@nocrew.org>]

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