On Mon, Jan 29, 2024 at 03:04:23PM -0600, David Vernet wrote: [...] > > + as being in the base64 conformance group. > > +* atom32: includes 32-bit atomic operation instructions (see `Atomic operations`_). > > +* atom64: includes atom32, plus 64-bit atomic operation instructions. > > +* div32: includes 32-bit division and modulo instructions. > > Did we want to separate division and modulo? It looks like Netronome > doesn't support modulo [0], presumably because it's not as useful as in > tracing. > > Jakub -- can you confirm? If so, how difficult would it have been to add > modulo support, and do you think it would have provided any value? > > [0]: https://github.com/torvalds/linux/blob/master/drivers/net/ethernet/netronome/nfp/bpf/jit.c#L3421 I spoke about this offline with Jakub. It turns out that there was actually neither division nor modulo in the silicon. They only supported division by the kernel's reciprocal division library. We could choose to apply Netronome's choice to the standard, but I really don't think we should. Kuba pointed out that Netronome is old silicon, and that most vendors today would likely start with RISC-V. To that point, I believe the most prudent thing is to just mirror the smallest riscv32 instruction-set granularity for our conformance groups. For the case of multiplication, division, and modulo, this would be the "M" standard extension for Integer Multiplication and Division, which provides signed and unsigned multiplication, division, and modulo instructions. My suggestion is for us to mirror this exactly, here. I think the contours set by RISC-V are much stronger data points for what will make sense for vendors than what Netronome did on what at this point is rather old silicon. How do we feel about having divmul32/64 conformance groups? Thus removing multiplication from the base32/64 groups. This would leave us with: - base{32/64} (reflecting RV32I and RV64I plus our call instructions, which logically fit here given that RISC-V control flow instructions are in RV{32,64}I as well) - divmul{32/64} (the "M" instruction set provides both 32 and 64 bit versions of MUL(W), DIV{U}(W), and REM{U}(W) instructions respectively) - atom{32/64} (the "A" extension provides 32 and 64 bit instructions for R32 and R64 respectively, just like with div/mod) - legacy This to me seems like both the most logical layout of instructions, as well as the least likely to cause pain for vendors given the precedence that's already been set by RISC-V. [...] Thanks, David
Attachment:
signature.asc
Description: PGP signature
