* [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding
@ 2017-07-25 13:04 Bastian Koppelmann
2017-07-25 14:31 ` [Qemu-devel] [sw-dev] " Samuel Falvo II
` (2 more replies)
0 siblings, 3 replies; 11+ messages in thread
From: Bastian Koppelmann @ 2017-07-25 13:04 UTC (permalink / raw)
To: RISC-V SW Dev, QEMU Developers
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
^ permalink raw reply [flat|nested] 11+ messages in thread* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-25 13:04 [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding Bastian Koppelmann @ 2017-07-25 14:31 ` Samuel Falvo II 2017-07-26 12:00 ` Bastian Koppelmann 2017-07-25 16:37 ` Bruce Hoult 2017-07-26 16:33 ` [Qemu-devel] " Peter Maydell 2 siblings, 1 reply; 11+ messages in thread From: Samuel Falvo II @ 2017-07-25 14:31 UTC (permalink / raw) To: Bastian Koppelmann; +Cc: RISC-V SW Dev, QEMU Developers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-25 14:31 ` [Qemu-devel] [sw-dev] " Samuel Falvo II @ 2017-07-26 12:00 ` Bastian Koppelmann 2017-07-26 17:36 ` Richard W.M. Jones 0 siblings, 1 reply; 11+ messages in thread From: Bastian Koppelmann @ 2017-07-26 12:00 UTC (permalink / raw) To: Samuel Falvo II; +Cc: RISC-V SW Dev, QEMU Developers 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. > > > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-26 12:00 ` Bastian Koppelmann @ 2017-07-26 17:36 ` Richard W.M. Jones 2017-07-26 20:58 ` krste 0 siblings, 1 reply; 11+ messages in thread From: Richard W.M. Jones @ 2017-07-26 17:36 UTC (permalink / raw) To: Bastian Koppelmann; +Cc: Samuel Falvo II, RISC-V SW Dev, QEMU Developers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-26 17:36 ` Richard W.M. Jones @ 2017-07-26 20:58 ` krste 2017-07-26 21:25 ` Michael Clark 0 siblings, 1 reply; 11+ messages in thread From: krste @ 2017-07-26 20:58 UTC (permalink / raw) To: Richard W.M. Jones Cc: Bastian Koppelmann, Samuel Falvo II, RISC-V SW Dev, QEMU Developers 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. ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-26 20:58 ` krste @ 2017-07-26 21:25 ` Michael Clark 0 siblings, 0 replies; 11+ messages in thread From: Michael Clark @ 2017-07-26 21:25 UTC (permalink / raw) To: krste Cc: Richard W.M. Jones, Bastian Koppelmann, Samuel Falvo II, RISC-V SW Dev, QEMU Developers > 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-25 13:04 [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding Bastian Koppelmann 2017-07-25 14:31 ` [Qemu-devel] [sw-dev] " Samuel Falvo II @ 2017-07-25 16:37 ` Bruce Hoult 2017-07-26 6:56 ` Stefan O'Rear 2017-07-26 11:45 ` Bastian Koppelmann 2017-07-26 16:33 ` [Qemu-devel] " Peter Maydell 2 siblings, 2 replies; 11+ messages in thread From: Bruce Hoult @ 2017-07-25 16:37 UTC (permalink / raw) To: Bastian Koppelmann; +Cc: RISC-V SW Dev, QEMU Developers 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. > ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-25 16:37 ` Bruce Hoult @ 2017-07-26 6:56 ` Stefan O'Rear 2017-07-26 11:45 ` Bastian Koppelmann 1 sibling, 0 replies; 11+ messages in thread From: Stefan O'Rear @ 2017-07-26 6:56 UTC (permalink / raw) To: Bruce Hoult; +Cc: Bastian Koppelmann, RISC-V SW Dev, QEMU Developers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-25 16:37 ` Bruce Hoult 2017-07-26 6:56 ` Stefan O'Rear @ 2017-07-26 11:45 ` Bastian Koppelmann 2017-07-27 7:32 ` Markus Armbruster 1 sibling, 1 reply; 11+ messages in thread From: Bastian Koppelmann @ 2017-07-26 11:45 UTC (permalink / raw) To: Bruce Hoult; +Cc: RISC-V SW Dev, QEMU Developers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding 2017-07-26 11:45 ` Bastian Koppelmann @ 2017-07-27 7:32 ` Markus Armbruster 0 siblings, 0 replies; 11+ messages in thread From: Markus Armbruster @ 2017-07-27 7:32 UTC (permalink / raw) To: Bastian Koppelmann; +Cc: Bruce Hoult, RISC-V SW Dev, QEMU Developers 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". ^ permalink raw reply [flat|nested] 11+ messages in thread
* Re: [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding 2017-07-25 13:04 [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding Bastian Koppelmann 2017-07-25 14:31 ` [Qemu-devel] [sw-dev] " Samuel Falvo II 2017-07-25 16:37 ` Bruce Hoult @ 2017-07-26 16:33 ` Peter Maydell 2 siblings, 0 replies; 11+ messages in thread From: Peter Maydell @ 2017-07-26 16:33 UTC (permalink / raw) To: Bastian Koppelmann; +Cc: RISC-V SW Dev, QEMU Developers 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 ^ permalink raw reply [flat|nested] 11+ messages in thread
end of thread, other threads:[~2017-07-27 7:32 UTC | newest] Thread overview: 11+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2017-07-25 13:04 [Qemu-devel] RFC: QEMU RISC-V modular ISA decoding Bastian Koppelmann 2017-07-25 14:31 ` [Qemu-devel] [sw-dev] " Samuel Falvo II 2017-07-26 12:00 ` Bastian Koppelmann 2017-07-26 17:36 ` Richard W.M. Jones 2017-07-26 20:58 ` krste 2017-07-26 21:25 ` Michael Clark 2017-07-25 16:37 ` Bruce Hoult 2017-07-26 6:56 ` Stefan O'Rear 2017-07-26 11:45 ` Bastian Koppelmann 2017-07-27 7:32 ` Markus Armbruster 2017-07-26 16:33 ` [Qemu-devel] " Peter Maydell
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.