On Tue, Jan 09, 2024 at 12:35:39PM +0100, Jose E. Marchesi wrote: > > > 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. > > This is very interesting. > > Sounds like, on one hand, introducing ilp32 and lp64 C data models for > BPF: > > ilp32 > > int, long, pointers -> 32 bit > short -> 16 bit > char -> 8 bit > > lp64 > > long, pointers -> 64 bit > int -> 32 bit > short -> 16 bit > char -> 8 bit > > On the other hand, compiler flags -m32 and -m64 could determine what > instruction groups are generated and what C data model is used: > > -m32 > > Use ilp32 data model for C. > Use 32-bit instruction set. > > -m64 > > Use lp64 data model for C. > Use both 32-bit (if/when alu32) and 64-bit instruction sets. This all seems reasonable to me. > And perhaps introducing a bit in the ELF flags section identifying a > 32-bit binary. Something like EF_BPF_32. > > Would 64-bit ELF be used also in cases where BPF is offloaded to 32-bit > devices? I expect it would be preferable to not use ELF-64 here, but I also don't think this is necessarily something we need to figure out now. Hopefully this is all stuff we can iron out once we start to really sink our teeth into the ABI doc.
Attachment:
signature.asc
Description: PGP signature
