[RFC] RISC-V Decoder generator

[Bastian Koppelmann]

Hi QEMU and RISC-V folks,

I asked you for feedback some while ago regarding a modular RISC-V QEMU
target (see discussion [1]). I tried getting it to work with the good
old C preprocessor and quickly realized that it is too limiting. Instead
I created a data-driven decoder generator written in python (see the
code on github [2]) using YAML as a description language.

I'd like to get some feedback whether this is acceptable to be
upstreamed to QEMU or if you have any suggestions for improvements.
Right now only RV32I instruction are implemented in this scheme.

For this I will roughly sketch how the data format for RISC-V
instructions works and then how the result after processing looks like.
You can find the full tree on github [2] with all the relevant files in
'target-riscv/decode-gen/'.

The RISC-V data in YAML consists of:

1) prefixes
2) instruction formats
3) instruction specification using the data of 1) and 2)

1) prefixes have:
- name
- bitmask that identifies instructions belonging to it
- length that specifies the length in bits for all instructions with
this prefix

Example prefix description for 16 bit instructions:

16Bit: {
bitmask: ~0b11,
len: 16
}

2) instruction formats have:
- name
- list of immediate fields
- list of 'normal' fields (e.g. register identifier)

The immediate fields are specified separately in the same file with:
- name
- data: in order list of the individual fields + possible sign i

extension
- fill: how is the immediate filled from the LSB (for now only
'0' fills are allowed)

Example for B-type immediate:
B: {data: [31s, 7, 30..25, 11..8], fill: '0'}
Note here that bit 31 is used for sign extension as indicated by
the 's'.

The 'normal' fields are similar to immediate fields but only have:
- name
- single field description

Example for 'rs1' field:
- rs1: 19..15

Example for a full instruction format 'SB':
- SB: {
fields: [rs1,rs2],
immediates: [B]
}

3) instruction specification have:
- name
- instruction format from 2)
- prefix from 1)
- keymap of opcode fields and the value they take for this
instruction
- func for binary translation

The opcode fields are specified separately in the same file in the
same manner as 'normal' opcode fields.
Example for FUNC3:
- FUNC3_32: 14..12

Example for the 'BEQ' instruction:
BEQ: {format: SB, prefix: 32Bit, opcodes: {OP1_32: 99, FUNC3_32: 0},
func: gen_beq}

'OP1_32: 99' means that field OP1_32 defined by bits 6 until 0 have
to have the value 99


The python script then converts these instructions into a tree of
switch-case statements depending on the specified opcodes and generates
at each case for one instruction two function calls:

1) decode_format_* depending on the instruction format used by this
instruction.
The decode_format_* functions are also generated by the script and
take of decoding the 'normal' fields and the immediate fields. This
data is stored in a data structure 'DisasFormats' which needs to be
passed to any translation function used by instructions.

2) A call to the translation function defined by 'func' in 3)
These need to be defined by the developer in translate.c. For example
for LUI this looks like:

static void gen_lui(CPURISCVState *env, DisasContext *ctx)
{
if (ctx->fmt.field_rd == 0) {
return; /* NOP */
}
tcg_gen_movi_tl(cpu_gpr[ctx->fmt.field_rd], ctx->fmt.immediate_U);
}

Thanks for any comments,
Bastian

[1] https://lists.gnu.org/archive/html/qemu-devel/2017-07/msg07735.html
[2] https://github.com/bkoppelmann/riscv-qemu/tree/decoder

[Richard W.M. Jones]

On Fri, Oct 20, 2017 at 03:46:54PM +0200, Bastian Koppelmann wrote:
> I asked you for feedback some while ago regarding a modular RISC-V QEMU
> target (see discussion [1]). I tried getting it to work with the good
> old C preprocessor and quickly realized that it is too limiting. Instead
> I created a data-driven decoder generator written in python (see the
> code on github [2]) using YAML as a description language.
>
> I'd like to get some feedback whether this is acceptable to be
> upstreamed to QEMU or if you have any suggestions for improvements.
> Right now only RV32I instruction are implemented in this scheme.

My suggestion would be to reimplement (part of) the s390x decoder
using this scheme. That would give us a direct comparison of how your
scheme is better or worse than the existing macros.

Will you be at the KVM Forum next week?

Rich.

--
Richard Jones, Virtualization Group, Red Hat http://people.redhat.com/~rjones
Read my programming and virtualization blog: http://rwmj.wordpress.com
libguestfs lets you edit virtual machines. Supports shell scripting,
bindings from many languages. http://libguestfs.org

[Bastian Koppelmann]

On 10/20/2017 06:57 PM, Richard Henderson wrote:
> All that said, this looks very readable. Thank you.
>

Thanks for your great feedback. I think most of them are not hard to
implement. However I might need some time for that :)

Cheers,
Bastian

[Bastian Koppelmann]

Hi Richard,

On 10/21/2017 08:44 AM, Richard W.M. Jones wrote:
> On Fri, Oct 20, 2017 at 03:46:54PM +0200, Bastian Koppelmann wrote:
>> I asked you for feedback some while ago regarding a modular RISC-V QEMU
>> target (see discussion [1]). I tried getting it to work with the good
>> old C preprocessor and quickly realized that it is too limiting. Instead
>> I created a data-driven decoder generator written in python (see the
>> code on github [2]) using YAML as a description language.
>>
>> I'd like to get some feedback whether this is acceptable to be
>> upstreamed to QEMU or if you have any suggestions for improvements.
>> Right now only RV32I instruction are implemented in this scheme.
>
> My suggestion would be to reimplement (part of) the s390x decoder
> using this scheme. That would give us a direct comparison of how your
> scheme is better or worse than the existing macros.

Yeah that would be a great test. However I'm not sure if it's worth the
effort. AFAIK s390x will not be extended with new instructions, so there
is no need for a new scheme unless it helps making the code better
maintainable. But that's up to the s390x maintainers.

>
> Will you be at the KVM Forum next week?

No, sorry. I'm at the verge of graduating from University, so my time is
very limited right now :(

Cheers,
Bastian