Re: [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding

[Peter Maydell]

On 25 July 2017 at 14:04, Bastian Koppelmann <address@hidden>
> Right now the RISC-V port for QEMU uses the classic decoding scheme of
> one function decoding the first opcode (and prefixes) and then branches
> to different functions for decoding the rest (as in target/arm or most
> of the other targets). This is all done using switch, case statements.
>
> This is a little bit tricky to extend, especially for third parties. I
> don't think it's too bad, but it can definitely be improved and I really
> like the way target/s390x does it, but I'm not sure about it's drawbacks.

(This is all purely generic QEMU design/coding viewpoint,
I know nothing about the RISC-V ISA.)

I would tend to favour writing the decoder with maintainability
in mind -- experience with the ARM QEMU decoder has been that
the "one function with a ginormous switch statement" that
the 32-bit decoder uses is really hard to maintain and
add new instruction support to. The 64-bit decoder is much
better largely because it splits the code into multiple
functions (in the same way the ISA documentation structures
the decode) and has good comments along the way about
what the current insn pattern is in terms of 0s, 1s and
don't-know-yet bits.

Data driven is nice when you can do it (the A64 decoder
does this a bit for SIMD) but the extent to which you
can do it will depend a lot on the details of the encoding
of the instruction set you're dealing with -- some are
simply not regular enough to make it pay off.

I doubt you're spending enough time in the decoder for it
to be a significant element in performance profiling
(and if you are then probably something else is wrong
like QEMU's TLB is getting flushed too often), but as
always better to measure than guess.

thanks
-- PMM