On Tue, Jan 23, 2024 at 1:52 PM David Vernet <void@xxxxxxxxxxxxx> wrote: > > > > 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? > > Well, if we're standardizing on both, then yes I think it would be > mandatory for a tool to support both, and I think instructions would > require assembly for both dialects. I think it's obvious that there is no way we will add gcc's flavor of asm to kernel and llvm. > Practically speaking that's already > what's happening, no? Both dialects are already pervasive, They are not. There are thousands of lines of asm written in pseudo-c used in production applications and probably only ubpf/tests and gcc/tests in that other asm, since gcc bpf support is not yet in the released gcc version. There is also this asm flavor: https://github.com/Xilinx-CNS/ebpf_asm Which is different from pseudo-c and ubpf asm. I don't think asm syntax should be an IETF draft. -- Bpf mailing list Bpf@xxxxxxxx https://www.ietf.org/mailman/listinfo/bpf
