qemu-devel
[Top][All Lists]
Advanced

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

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


From: Samuel Falvo II
Subject: Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding
Date: Tue, 25 Jul 2017 07:31:43 -0700

For those of us who are not in the know, how does target/s390 decoding work?

I've maintained a 65816 emulator
(https://bitbucket.org/kc5tja/lib65816/src) which also uses a giant
case construct.  This method is used because it's fast.  Any
alternative approaches you decide to take might well work and satisfy
extensibility requirements, but it'll likely take a performance hit as
well.

On Tue, Jul 25, 2017 at 6:04 AM, Bastian Koppelmann
<address@hidden> wrote:
> 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
>
>
>
> --
> You received this message because you are subscribed to the Google Groups 
> "RISC-V SW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to address@hidden
> To post to this group, send email to address@hidden
> Visit this group at 
> https://groups.google.com/a/groups.riscv.org/group/sw-dev/.
> To view this discussion on the web visit 
> https://groups.google.com/a/groups.riscv.org/d/msgid/sw-dev/e071dd23-8d19-93ba-7962-b2e2df69a6ee%40mail.uni-paderborn.de.



-- 
Samuel A. Falvo II



reply via email to

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