Re: [RFC PATCH bpf-next 1/6] bpf: Add UHMUL and SHMUL instructions

["Alexei Starovoitov" <alexei.starovoitov@gmail.com>]

On Tue Sep 15, 2026 at 11:48 AM UTC, Yazhou Tang wrote:
>
>
> On 9/14/26 16:36, Yazhou Tang wrote:
> > 
> > 
> > On 9/12/26 11:40 AM, Alexei Starovoitov wrote:
> >> On Tue Sep 8, 2026 at 1:30 AM PDT, Yazhou Tang wrote:
> >>>
> >>>
> >>> On 9/8/26 3:51 AM, Alexei Starovoitov wrote:
> >>>> On Wed Sep 2, 2026 at 12:05 AM PDT, Yazhou Tang wrote:
> >>>>> From: Tianci Cao <ziye@zju.edu.cn>
> >>>>>
> >>>>> Define UHMUL and SHMUL as BPF_ALU64 BPF_MUL variants selected by insn->off.
> >>>>> UHMUL returns the high 64 bits of an unsigned 64-by-64-bit product, while
> >>>>> SHMUL returns the high 64 bits of a signed product. Keep off == 0 as the
> >>>>> existing low-half multiplication, and assign off == 1 and off == 2 to
> >>>>> UHMUL and SHMUL, respectively.
> >>>>>
> >>>>> These operations are inspired by the UHMUL and SHMUL instructions
> >>>>> introduced as part of the PQR instruction class in Solana sBPF[1].
> >>>>>
> >>>>> The encoding and immediate semantics differ from current sBPF.
> >>>>>
> >>>>> 1. Solana sBPF assigns these operations dedicated opcodes in the BPF_PQR
> >>>>>      class, whereas this implementation selects them through the offset
> >>>>>      field of BPF_MUL.
> >>>>>
> >>>>> 2. Solana sBPF initially sign-extended the immediate operand of UHMUL,
> >>>>>      but later changed unsigned PQR immediates, including UHMUL, to be
> >>>>>      zero-extended[2].
> >>>>
> >>>> Why did you switch to zero-extend ?
> >>>> Sounds odd to do zero extend just for these ops.
> >>>
> >>> Sorry, I wasn't clear. This patch does not zero-extend the UHMUL immediate.
> >>>
> >>> Both UHMUL and SHMUL follow the existing BPF_ALU64 convention and
> >>> sign-extend the 32-bit immediate to 64 bits first. The zero-extension
> >>> I mentioned refers only to current Solana sBPF behavior. I'll clarify
> >>> this in the respin.
> >>
> >> My question was "why in Solana you switched to zero-extend?"
> > 
> > I wasn't involved in that Solana change.
> > 
> > https://github.com/solana-labs/rbpf/pull/642
> > 
> > In Solana BPF, PQR is a separate instruction class for product, quotient,
> > and remainder operations. PR #642 mentioned above changed the treatment of
> > 32-bit immediates for all three 64-bit unsigned PQR operations (UHMUL,
> > UDIV, and UREM) from sign-extension to zero-extension. This appears to
> > have been a broader convention change for unsigned PQR operations, rather
> > than something specific to UHMUL.
> > 
> > I couldn't find the design reason documented in the PR, though. I'll try
> > to ask the author about it.
>
> I asked Alexander Meißner, the author of the Solana BPF change. He confirmed
> that zero-extension was an intentional ISA design choice rather than a fix
> for a particular compatibility issue.
>
> He gave two main reasons.
>
> 1. First, for explicitly unsigned instructions such as UHMUL/UDIV/UREM,
> treating the 32-bit immediate as an unsigned value was considered more
> intuitive. For example, with an encoded immediate of 0xffffffff, zero-
> extension gives 0x00000000ffffffff (2^32 - 1), while sign-extension gives
> 0xffffffffffffffff (2^64 - 1). Similarly, 0x80000000 becomes 2^31 with
> zero-extension, rather than 2^64 - 2^31 with sign-extension.
>
> 2. Second, zero-extension gives the continuous unsigned range [0, 2^32 - 1].
> With sign-extension, the upper half of the immediate encoding instead
> represents values in [2^64 - 2^31, 2^64 - 1], while values in [2^31, 2^32 - 1]
> cannot be represented directly. The Solana BPF design considered the range
> provided by zero-extension more useful for unsigned operations.
>
> For Linux, given that the existing ALU64 UDIV/UMOD instructions with
> immediate operands sign-extend the 32-bit immediate to 64 bits and then
> use the resulting value as an unsigned operand, I'm inclined to do the
> same for UHMUL for consistency.

Agree. I think it's better to be consistent, since inconsistency in
imm32 encoding will cause quite a bit of headache to compilers to special
case these instructions.