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

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

[Bastian Koppelmann]

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

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

[Samuel Falvo II]

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
<kbastian@mail.uni-paderborn.de> 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 sw-dev+unsubscribe@groups.riscv.org.
> To post to this group, send email to sw-dev@groups.riscv.org.
> 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]

Do you have any good estimates for how much of the execution time is
typically spent in instruction decode?

RISC-V qemu is twice as fast as ARM or Aarch64 qemu, so it's doing
something right!

(I suspect it's probably mostly the lack of needing to emulate condition
codes)


On Tue, Jul 25, 2017 at 4:04 PM, Bastian Koppelmann <
kbastian@mail.uni-paderborn.de> 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 sw-dev+unsubscribe@groups.riscv.org.
> To post to this group, send email to sw-dev@groups.riscv.org.
> 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.
>

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

[Stefan O'Rear]

On Tue, Jul 25, 2017 at 9:37 AM, Bruce Hoult <bruce@hoult.org> wrote:
> Do you have any good estimates for how much of the execution time is
> typically spent in instruction decode?
>
> RISC-V qemu is twice as fast as ARM or Aarch64 qemu, so it's doing something
> right!
>
> (I suspect it's probably mostly the lack of needing to emulate condition
> codes)

The last time I tried to profile qemu (system mode, running the Go
bootstrap, I think), I didn't get very far because no jit-map and I
wasn't able to get frame pointers working, but as far as I got none of
the translate functions showed up.

Most time spent in translated code, trampolines for entering and
exiting translated code, TLB maintenance, and the code to choose which
basic block to run next.

Making the instruction decoder a bit slower is not likely to have much
effect (but do do before and after measurements to be sure).

Significant wins would come from reducing the number of switches
between translations (e.g. by translating larger units, all code on a
page at once, functions, traces), by making switches between
translations cheaper (e.g. with inline caches), or by reducing the
cost of access translation (e.g. two accesses relative to the same
base register in the same translation often hit the same virtual page
and can share translation effort, or more speculatively by using host
translation hardware.  (I am willing to discuss any of these further
OFF-LIST ONLY.)

-s

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

[Bastian Koppelmann]

On 07/25/2017 06:37 PM, Bruce Hoult wrote:
> Do you have any good estimates for how much of the execution time is
> typically spent in instruction decode?
> 
> RISC-V qemu is twice as fast as ARM or Aarch64 qemu, so it's doing
> something right!
> 
> (I suspect it's probably mostly the lack of needing to emulate condition
> codes)

And most likely du to no overflow calculations. I don't expect
performance to be too big of an issue (I don't have hard data on that),
this was just the first thing that came to mind. I was rather hoping to
get some feedback from the s390x maintainers/qemu devs on other problems
I'm not seeing.

The important question to me: Is it worth it to refactor the code to
allow easy extensibility or not?

Cheers,
Bastian

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

[Bastian Koppelmann]

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.

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
> <kbastian@mail.uni-paderborn.de> 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 sw-dev+unsubscribe@groups.riscv.org.
>> To post to this group, send email to sw-dev@groups.riscv.org.
>> 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.
> 
> 
> 

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

[Peter Maydell]

On 25 July 2017 at 14:04, Bastian Koppelmann <kbastian@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

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
> > <kbastian@mail.uni-paderborn.de> 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 sw-dev+unsubscribe@groups.riscv.org.
> >> To post to this group, send email to sw-dev@groups.riscv.org.
> >> 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 sw-dev+unsubscribe@groups.riscv.org.
> To post to this group, send email to sw-dev@groups.riscv.org.
> 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

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

[krste]

Given that one of the goals of RISC-V is extensibility, it would be
nice if the QEMU port was done in a way to make it easier to extend by
third parties, including other automated tools.  I'm sure that, over
time, the preprocessor can be improved to automatically incorporate
optimizations for better performance.

Krste

>>>>> On Wed, 26 Jul 2017 18:36:28 +0100, "Richard W.M. Jones" <rjones@redhat.com> said:

| 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
|| > <kbastian@mail.uni-paderborn.de> 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 sw-dev+unsubscribe@groups.riscv.org.
|| >> To post to this group, send email to sw-dev@groups.riscv.org.
|| >> 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 sw-dev+unsubscribe@groups.riscv.org.
|| To post to this group, send email to sw-dev@groups.riscv.org.
|| 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

| -- 
| 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 sw-dev+unsubscribe@groups.riscv.org.
| To post to this group, send email to sw-dev@groups.riscv.org.
| 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/20170726173628.GF30459%40redhat.com.

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

[Michael Clark]

> On 27 Jul 2017, at 8:58 AM, krste@berkeley.edu wrote:
> 
> 
> Given that one of the goals of RISC-V is extensibility, it would be
> nice if the QEMU port was done in a way to make it easier to extend by
> third parties, including other automated tools.  I'm sure that, over
> time, the preprocessor can be improved to automatically incorporate
> optimizations for better performance.

I had a look at the s390x code in more detail.

It essentially does some length and major opcode unpacking to construct/linearise the opcode space, and would be equivalent to constructing a 15-bit opcode for RISC-V. It does some pre-decoding to find length, majors, and has a switch on majors to find instruction type, and then append minors, if any.

- https://hastebin.com/taceyuyore.cpp <https://hastebin.com/taceyuyore.cpp>

It would be akin to something list this (at a high-level):

len = inst_len(inst)		/* bits[1:0] */
op = major_opcode(inst)	/* bits[6:2] */

switch op
	- rvc
		/* hairy bit */
	- r-type
		op2 = funct7 << 3 | funct3
	- i-type
	- s-type
		op2 = funct3
	- u-type
		op2 = 0

op = op | op2 << 5

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

[Markus Armbruster]

Bastian Koppelmann <kbastian@mail.uni-paderborn.de> writes:

> On 07/25/2017 06:37 PM, Bruce Hoult wrote:
>> Do you have any good estimates for how much of the execution time is
>> typically spent in instruction decode?
>> 
>> RISC-V qemu is twice as fast as ARM or Aarch64 qemu, so it's doing
>> something right!
>> 
>> (I suspect it's probably mostly the lack of needing to emulate condition
>> codes)
>
> And most likely du to no overflow calculations. I don't expect
> performance to be too big of an issue (I don't have hard data on that),
> this was just the first thing that came to mind. I was rather hoping to
> get some feedback from the s390x maintainers/qemu devs on other problems
> I'm not seeing.
>
> The important question to me: Is it worth it to refactor the code to
> allow easy extensibility or not?

A common answer to "is it worth it?" is "someone showing up with the
work is a pretty strong indicator it is to him".