Alistair, Do you (and the other RISC-V custodians of target/riscv) have any opinion on this? We can go either way — and it boils down to a style and process question.
Thanks, Philipp. On Mon, 10 Jan 2022 at 12:30, Philippe Mathieu-Daudé <f4...@amsat.org> wrote: > On 1/10/22 12:11, Philipp Tomsich wrote: > > On Mon, 10 Jan 2022 at 11:03, Philippe Mathieu-Daudé <f4...@amsat.org > > <mailto: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). > > 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. >
