On Mon, 10 Jan 2022 at 11:03, Philippe Mathieu-Daudé <f4...@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.
