On Wed, Jan 24, 2024 at 06:51:16PM -0800, Alexei Starovoitov wrote: > 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. Well, it will depend on how widely it's used. Or if it's used widely :-) > > 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. Ok, fair enough. Another thought that occurred to me after thinking about this more -- even if we want source code compatibility (which is still an open question), that doesn't necessarily imply or require assembly dialect compatibility. Let's table this for now, and revisit another day, should we ever find that it makes sense to do so. Thanks, David
Attachment:
signature.asc
Description: PGP signature
