Re: bpf: Propose some new instructions for -mcpu=v4

["Jose E. Marchesi" <jose.marchesi@oracle.com>]

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?