In the email discussion below, we concluded it wasn't relevant at the time because there were no signed modulo instructions. However, now there is and I believe the ambiguity in the current spec needs to be addressed. > -----Original Message----- > From: Dave Thaler > Sent: Friday, September 30, 2022 3:42 PM > To: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > Cc: dthaler1968@xxxxxxxxxxxxxx; bpf@xxxxxxxxxxxxxxx > Subject: RE: [PATCH 07/15] ebpf-docs: Fix modulo zero, division by zero, > overflow, and underflow > > > -----Original Message----- > > From: Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> > > Sent: Friday, September 30, 2022 2:59 PM > > To: Dave Thaler <dthaler@xxxxxxxxxxxxx> > > Cc: dthaler1968@xxxxxxxxxxxxxx; bpf@xxxxxxxxxxxxxxx > > Subject: Re: [PATCH 07/15] ebpf-docs: Fix modulo zero, division by > > zero, overflow, and underflow > > > > On Fri, Sep 30, 2022 at 09:54:17PM +0000, Dave Thaler wrote: > > > [...] > > > > > +Also note that the modulo operation often varies by language > > > > > +when the dividend or divisor are negative, where Python, Ruby, etc. > > > > > +differ from C, Go, Java, etc. This specification requires that > > > > > +modulo use truncated division (where -13 % 3 == -1) as > > > > > +implemented in C, Go, > > > > > +etc.: > > > > > + > > > > > + a % n = a - n * trunc(a / n) > > > > > + > > > > > > > > Interesting bit of info, but I'm not sure how it relates to the ISA doc. > > > > > > It's because there's multiple definitions of modulo out there as the > > > paragraph notes, which differ in what they do with negative numbers. > > > The ISA defines the modulo operation as being the specific version above. > > > If you tried to implement the ISA in say Python and didn't know > > > that, you'd have a non-compliant implementation. > > > > Is it because the languages have weird rules to pick between signed vs > > unsigned mod? > > At least from llvm pov the smod and umod have fixed behavior. > > It's because there's different mathematical definitions and different languages > have chosen different definitions. E.g., languages/libraries that follow Knuth > use a different mathematical definition than C uses. For details see: > > https://en.wikipedia.org/wiki/Modulo_operation#Variants_of_the_definition > > https://torstencurdt.com/tech/posts/modulo-of-negative-numbers/ > > Dave Perhaps text like the proposed snippet quoted in the exchange above should be added around the new text that now appears in the doc, i.e. the ambiguous text is currently: > For signed operations (``BPF_SDIV`` and ``BPF_SMOD``), for ``BPF_ALU``, > 'imm' is interpreted as a 32-bit signed value. For ``BPF_ALU64``, 'imm' > is first :term:`sign extended<Sign Extend>` from 32 to 64 bits, and then > interpreted as a 64-bit signed value. Dave
