On 2/9/23 5:45 PM, Jose E. Marchesi wrote:
Hi Yonghong.
Thanks for the proposal!
SDIV/SMOD (signed div and mod)
==============================
bpf already has unsigned DIV and MOD. They are encoded as
insn code(4 bits) source(1 bit) instruction class(3 bit)
off(16 bits)
DIV 0x3 0/1 BPF_ALU/BPF_ALU64 0
MOD 0x9 0/1 BPF_ALU/BPF_ALU64 0
The current 'code' field only has two value left, 0xe and 0xf.
gcc used these two values (0xe and 0xf) for SDIV and SMOD.
But using these two values takes up all 'code' space and makes
future extension hard.
Here, I propose to encode SDIV/SMOD like below:
insn code(4 bits) source(1 bit) instruction class(3 bit)
off(16 bits)
DIV 0x3 0/1 BPF_ALU/BPF_ALU64 1
MOD 0x9 0/1 BPF_ALU/BPF_ALU64 1
Basically, we reuse the same 'code' value but changing 'off' from 0 to 1
to indicate signed div/mod.
I have a general concern about using instruction operands to encode
opcodes (in this case, 'off').
At the moment we have two BPF instruction formats:
- The 64-bit instructions:
code:8 regs:8 offset:16 imm:32
- The 128-bit instructions:
code:8 regs:8 offset:16 imm:32 unused:32 imm:32
Of these, `code', `regs' and `unused' are what is commonly known as
instruction fields. These are typically used for register numbers,
flags, and opcodes.
On the other hand, offset, imm32 and imm:32:::imm:32 are instruction
operands (the later is non-contiguous and conforms the 64-bit operand in
the 128-bit instruction).
The main difference between these is that the bytes conforming
instruction operands are themselves impacted by endianness, on top on
the endianness effect on the whole instruction. (The weird endian-flip
in the two nibbles of `regs' is unfortunate, but I guess there is
nothing we can do about it at this point and I count them as
non-operands.)
If you use an instruction operand (such as `offset') in order to act as
an opcode, you incur in two inconveniences:
1) In effect you have "moving" opcodes that depend on the endianness.
The opcode for signed-operation will be 0x1 in big-endian BPF, but
0x8000 in little-endian bpf.
2) You lose the ability of easily adding more complementary opcodes in
these 16 bits in the future, in case you ever need them.
As far as I have seen in other architectures, the usual way of doing
this is to add an additional instruction format, in this case for the
class of arithmetic instructions, where the bits dedicated to the unused
operand (offset) becomes a new opcodes field:
- 32-bit arithmetic instructions:
code:8 regs:8 code2:16 imm:32
Where code2 is now an additional field (not an operand) that provides
extra additional opcode space for this particular class of instructions.
This can be divided in a 1-bit field to signify "signed" and the rest
reserved for future use:
opcode2 ::= unused(15) signed(1)
Actually this would be just for DIV/MOD instructions, so the new format
should only apply to them. The new format would be something like:
- 64-bit ALU/ALU64 div/mod instructions (code=3,9):
code:8 regs:8 unused:15 signed:1 imm:32
And for the rest of the ALU and ALU64 instructions
(code=0,1,2,4,5,6,7,8,a,b,c,d):
- 64-bit ALU/ALU64 instructions:
code:8 regs:8 unused:16 imm:32
That is correct. My design can be interpreted this way.
