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 <kbast...@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+unsubscr...@groups.riscv.org. > To post to this group, send email to sw-...@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
