David Vernet <void@xxxxxxxxxxxxx> 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/net > > ronome/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. This sounds fine to me. Dave
