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
> <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.
>
>
>
