> -----Original Message----- > From: David Vernet <void@xxxxxxxxxxxxx> > Sent: Tuesday, January 23, 2024 1:31 PM > To: dthaler1968@xxxxxxxxxxxxxx > Cc: bpf@xxxxxxxx; bpf@xxxxxxxxxxxxxxx; jose.marchesi@xxxxxxxxxx > Subject: Re: [Bpf] Standardizing BPF assembly language? > > On Tue, Jan 23, 2024 at 08:45:32AM -0800, > dthaler1968=40googlemail.com@xxxxxxxxxxxxxx wrote: > > At LSF/MM/BPF 2023, Jose gave a presentation about BPF assembly > > language (http://vger.kernel.org/bpfconf2023_material/compiled_bpf.txt). > > > > Jose wrote in that link: > > > There are two dialects of BPF assembler in use today: > > > > > > - A "pseudo-c" dialect (originally "BPF verifier format") > > > : r1 = *(u64 *)(r2 + 0x00f0) > > > : if r1 > 2 goto label > > > : lock *(u32 *)(r2 + 10) += r3 > > > > > > - An "assembler-like" dialect > > > : ldxdw %r1, [%r2 + 0x00f0] > > > : jgt %r1, 2, label > > > : xaddw [%r2 + 2], r3 > > > > During Jose's talk, I discovered that uBPF didn't quote match the > > second dialect and submitted a bug report. By the time the conference > > was over, uBPF had been updated to match GCC, so that discussion > > worked to reduce the number of variants. > > > > As more instructions get added and supported by more tools and > > compilers there's the risk of even more variants unless it's standardized. > > > > Hence I'd recommend that BPF assembly language get documented in some > > WG draft. If folks agree with that premise, the first question is > > then: which document? > > > One possible answer would be the ISA document that specifies the > > instructions, since that would the IANA registry could list the > > assembly for each instruction, and any future documents that add > > instructions would necessarily need to specify the assembly for them, > > preventing variants from springing up for new instructions. > > I'm not opposed to this, but would strongly prefer that we do it as an extension > if we go this route to avoid scope creep for the first iteration. If the first iteration does not have it, then presumably the initial IANA registry would not have it either, since this iteration creates the registry and the rules for it. That's doable, but may continue to proliferate more and more variants until it is addressed. If it's in another document, do you agree it would still fall under the existing charter bullet about "defining the instructions" > [PS] the BPF instruction set architecture (ISA) that defines the > instructions and low-level virtual machine for BPF programs, ? > > A second question would be, which dialect(s) to standardize. Jose's > > link above argues that the second dialect should be the one > > standardized (tools are free to support multiple dialects for > > backwards compat if they want). See the link for rationale. > > My recollection was that the outcome of that discussion is that we were going > to continue to support both. If we wanted to standardize, I have a hard time > seeing any other way other than to standardize both dialects unless there's > been a significant change in sentiment since LSFMM. If "standardize both", does that mean neither is mandatory and each tool is free to pick one or the other? And would the IANA registry require a document adding any new instructions to specify the assembly in both dialects? Dave
