Standardizing BPF assembly language?

[dthaler1968@googlemail.com]

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.

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.

Thoughts?

Dave