Re: [PATCH v1 1/2] decodetree: Add an optional predicate-function for decoding

[Philipp Tomsich]

On Mon, 10 Jan 2022 at 11:03, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote:

On 1/10/22 10:52, Philipp Tomsich wrote:
> For RISC-V the opcode decode will change between different vendor
> implementations of RISC-V (emulated by the same qemu binary).
> Any two vendors may reuse the same opcode space, e.g., we may end up with:
>
> # *** RV64 Custom-3 Extension ***
> {
>   vt_maskc   0000000  ..... ..... 110 ..... 1111011 @r |has_xventanacondops_p
>   vt_maskcn  0000000  ..... ..... 111 ..... 1111011 @r |has_xventanacondops_p
>   someone_something  ............ ..... 000 ..... 1100111 @i
> |has_xsomeonesomething_p
> }
>
> With extensions being enabled either from the commandline
>     -cpu any,xventanacondops=true
> or possibly even having a AMP in one emulation setup (e.g. application
> cores having one extension and power-mangement cores having a
> different one — or even a conflicting one).

I understand, I think this is what MIPS does, see commit 9d005392390:
("target/mips: Introduce decodetree structure for NEC Vr54xx extension")

The MIPS implementation is functionally equivalent, and I could see us doing something similar for RISC-V (although I would strongly prefer to make everything explicit via the .decode-file instead of relying on people being aware of the logic in decode_op).

With the growing number of optional extensions (as of today, at least the Zb[abcs] and vector comes to mind), we would end up with a large number of decode-files that will then need to be sequentially called from decode_op(). The predicates can then move up into decode_op, predicting the auto-generated decoders from being invoked.

As of today, we have predicates for at least the following:

• Zb[abcs]
• Vectors
  

As long as we are in greenfield territory (i.e. not dealing with HINT-instructions that overlap existing opcode space), this will be fine and provide proper isolation between the .decode-tables.

However, as soon as we need to implement something along the lines (I know this is a bad example, as prefetching will be a no-op on qemu) of:

{

  {

    # *** RV32 Zicbop Sandard Extension (hints in the ori-space) ***

    prefetch_i  ....... 00000 ..... 110 00000 0010011 @cbo_pref

    prefetch_r  ....... 00001 ..... 110 00000 0010011 @cbo_pref

    prefetch_w  ....... 00011 ..... 110 00000 0010011 @cbo_pref

  }

  ori      ............     ..... 110 ..... 0010011 @i

}

we'd need to make sure that the generated decoders are called in the appropriate order (i.e. the decoder for the specialized instructions will need to be called first), which would not be apparent from looking at the individual .decode files.

Let me know what direction we want to take (of course, I have a bias towards the one in the patch).

Philipp.