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

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

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?"