On 25 July 2017 at 14:04, Bastian Koppelmann <kbast...@mail.uni-paderborn.de> > 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
