qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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


From: Bastian Koppelmann
Subject: [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding
Date: Tue, 25 Jul 2017 15:04:18 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.2.1

Hi QEMU devs, hi risc-v-sw devs,

I'm posting this cross mailing list since I'd like to get feedback from
the both sides.

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.

I see three options to proceed from here:

    1) Completely move to a decoding scheme similar to target/s390x in
       QEMU. On the plus side it make it super easy to add new
       instructions and/or new instruction formats, and reduces decoding
       errors. I don't know the major drawbacks to this approach, maybe
       performance. Does anyone know? Other than that it needs a major
       rewrite of the decoder, which will take some time and thus delay
       the development of RISC-V QEMU upstream. (I think RV32/64I can
       be left as is, since everybody has to implement it anyways)

    2) The compromise: Leave the core as is, i.e. RV32GC, and provide a
       nice interface for any other extension similar to target/s390.
       The big plus here is that no code needs to be changed and only
       the interface needs to be added. We don't add any performance
       overhead (if s390x-style decoding adds any), but this might
       result in nobody using it, since they don't know about the
       interface and they just hack their stuff in. Then it was a waste
       of our time to implement the interface.

    3) The status quo. Just leave it as is.

Any comments?

Cheers,
Bastian






reply via email to

[Prev in Thread] Current Thread [Next in Thread]