All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bastian Koppelmann <kbastian@mail.uni-paderborn.de>
To: Samuel Falvo II <sam.falvo@gmail.com>
Cc: RISC-V SW Dev <sw-dev@groups.riscv.org>,
	QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] [sw-dev] RFC: QEMU RISC-V modular ISA decoding
Date: Wed, 26 Jul 2017 14:00:14 +0200	[thread overview]
Message-ID: <58da690d-03d4-2c96-469a-35ff8c25ef1d@mail.uni-paderborn.de> (raw)
In-Reply-To: <CAEz=sonvfDHymUBec0Xw3RqhiANmUvrCjqMvn2eQ4zuOu1rH5A@mail.gmail.com>

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

  reply	other threads:[~2017-07-26 12:01 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
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 [this message]
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

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=58da690d-03d4-2c96-469a-35ff8c25ef1d@mail.uni-paderborn.de \
    --to=kbastian@mail.uni-paderborn.de \
    --cc=qemu-devel@nongnu.org \
    --cc=sam.falvo@gmail.com \
    --cc=sw-dev@groups.riscv.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
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.