On 2/9/23 3:36 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)
Thoughts?
If I understand correctly, you proposed something like
insn code(4 bits) source(1 bit) instruction class(3 bit)
EXT 0xe 0/1 BPF_ALU/BPF_ALU64
The insn BPF_EXT means the actual 'code' is in 'off' (16 bits), right?
I think this could work.
But we already have precedence to use off/imm fields for insn encoding,
e.g., newer atomic insns like XCHG using imm for the 'code' and we use
the BPF_ATOMIC to indicate a 'class' of atomic operations.
In this specific case, we use MOD/DIV as the 'code' which implies
a class of mod/div variants and the 'off' is the way to differentiate.
There are pro's and con's for each approach for the above EXT vs.
my proposal. But maybe we could reserve EXT for future use?
