|
From: | Philipp Tomsich |
Subject: | Re: [PATCH v1 1/2] decodetree: Add an optional predicate-function for decoding |
Date: | Wed, 12 Jan 2022 16:21:04 +0100 |
On 1/10/22 12:11, Philipp Tomsich wrote:
> On Mon, 10 Jan 2022 at 11:03, Philippe Mathieu-Daudé <f4bug@amsat.org
> <mailto: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).
I can't say for RISCV performance, I am myself biased toward maintenance
where having one compilation unit per (vendor) extension.
ARM and MIPS seems to go in this direction, while PPC and RISCV in the
other one.
[Prev in Thread] | Current Thread | [Next in Thread] |