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

[Richard W.M. Jones]

On Wed, Jul 26, 2017 at 02:00:14PM +0200, Bastian Koppelmann wrote:
> Hi Samuel,
> 
> On 07/25/2017 04:31 PM, Samuel Falvo II wrote:
> > For those of us who are not in the know, how does target/s390 decoding work?
> 
> sorry about that. I was going into this with a QEMU-dev mindset :)
> 
> The basic idea of s390x is to have every instruction + instruction
> formats specified in files that are parsed by the preprocessor and then
> used through preprocessor magic to generate switch-case statements for
> insn selection and data structures filled with the decoded data.
> 
> s390x has two files:
>     - insn-data.def -> contains all the instructions, including opcodes,
>                        name, ref to insn specific translate function,
>                        ref to insn format, and some more
>     - insn-format.def -> contains all the instruction formats
> 
> these are then used to automatically generate the switch-case statements
> and decoding code.

I looked at the s390x TCG code for the first time now and this is a
far more sensible way of doing it.  We should do it for all the arches :-)
I wonder if there's a performance penalty?

Rich.

> If you want to extend this, you add your own insn format to the
> insn-format.def files add functions for decoding parameters in
> translate.c. And then add your insn referencing the new format to
> insn-def.data and add translation functions for each of them.
> 
> The main benefit here is that you don't have to bother with writing all
> that boring glue code.
> 
> I hope that helped :)
> 
> Cheers,
> Bastian
> 
> > 
> > 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.
> > 
> > 
> > 
> 
> -- 
> 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/58da690d-03d4-2c96-469a-35ff8c25ef1d%40mail.uni-paderborn.de.

-- 
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
Fedora Windows cross-compiler. Compile Windows programs, test, and
build Windows installers. Over 100 libraries supported.
http://fedoraproject.org/wiki/MinGW