[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Qemu-devel] RISC-V: insn32.decode: Confusing encodings
From: |
Richard Henderson |
Subject: |
Re: [Qemu-devel] RISC-V: insn32.decode: Confusing encodings |
Date: |
Wed, 7 Aug 2019 11:40:58 -0700 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 |
On 8/6/19 5:48 AM, Maxim Blinov wrote:
> slli 00.... ...... ..... 001 ..... 0010011 @sh
> srli 00.... ...... ..... 101 ..... 0010011 @sh
> srai 01.... ...... ..... 101 ..... 0010011 @sh
>
> First question: Why does the %sh10 field exist? There are no 10-bit
> shamt fields anywhere in the spec.
>
> Second question: For rv32i, "SLLI" is defined as follows in the spec:
>
> 0000000 shamt[4:0] rs1[4:0] 001 rd[4:0] 0010011 | SLLI
Bits [9:5] of the field are checked against zero later, with
if (a->shamt >= TARGET_LONG_BITS) {
return false;
}
It was done this way to be compatible between rv32, rv64, and a future rv128.
Which I admit would only need 7 bits not 10, but it didn't seem to matter
either way.
> Consider the case that we have a 32 bit cpu and we wanted to have a
> custom instruction encoded like so:
>
> |This bit set
> v
> 0000001 shamt[4:0] rs1[4:0] 001 rd[4:0] 0010011 | MY_INSN
>
> In 64 bit risc-v, we can't have that instruction because that bit is
> used in the shift field for the SLLI instruction. But it should be
> fine to use in 32-bit risc-v.
Ah, well, for that you would in fact need to adjust the decode files.
I do question why you'd want to define MY_INSN in such a way as to be
incompatible with an rv64 implementation. Why not place your new bit higher in
the field?
> Why not have two separate insn32.decode and insn64.decode files?
To avoid unnecessary duplication, of course.
r~