On Mon, Jan 8, 2024 at 8:00 AM Christoph Hellwig <hch@xxxxxxxxxxxxx> wrote: > > On Fri, Jan 05, 2024 at 04:07:11PM -0600, David Vernet wrote: > > > > So how do we want to move forward here? It sounds like we're leaning > > toward's Alexei's proposal of having: > > > > - Base Integer Instruction Set, 32-bit > > - Base Integer Instruction Set, 64-bit > > - Integer Multiplication and Division > > - Atomic Instructions > > As in the 64-bit integer set would be an add-on to the first one which > is the core set? In that case that's fine with me, but the above > wording is a bit suboptimal. yes. Here is how I was thinking about the grouping: 32-bit set: all 32-bit instructions those with BPF_ALU and BPF_JMP32 and load/store. 64-bit set: above plus BPF_ALU64 and BPF_JMP. The idea is to allow for clean 32-bit HW offloads. We can introduce a compiler flag that will only use such instructions and will error when 64-bit math is needed. Details need to be thought through, of course. Right now I'm not sure whether we need to reduce sizeof(void*) to 4 in such a case or normal 8 will still work, but from ISA perspective everything is ready. 32-bit subregisters fit well. The compiler work plus additional verifier smartness is needed, but the end result should be very nice. Offload of bpf programs into 32-bit embedded devices will be possible. > > And then either having 3 separate groups for the calls, or putting all 3 > > in the basic group? I'd lean towards the latter given that we're > > decoupling ISA compliance from the verifier, but don't feel strongly > > either way. > > What would be the three different groups for the calls? I think just > having the call instruction in the base group should be fine. We'll > need to put in some wording that having support for any kind of call > depends on the program type. +1
