[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
Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding, Bruce Hoult, 2017/07/25
Re: [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding, Peter Maydell, 2017/07/26