On Mon, Aug 14, 2023 at 11:17:59AM -0500, David Vernet wrote: > On Fri, Aug 11, 2023 at 02:36:04PM -0700, Watson Ladd wrote: > > Dear David, > > Hi Watson, Hi everyone, Watson and I discussed this today in more detail over a call. I think we're now on the same page, and I want to update the lists with where we landed so others can weigh in. The TL;DR is that the ISA document as it exists today is trying to toe the line between being two different types of ISA documents: 1. An ARM/x86-esque ISA document that exists somewhat in isolation, and just defines the encodings and high-level semantics of instructions. For example, if you look at the ARM A64 Instruction Set Architecture for Armv8 and Armv8-A document, it literally just jumps straight into encodings and high-level semantics of the instructions. There's literally zero information about the ARM memory model, execution environment, etc. All of that is captured in separate architecture documents. 2. The RISC-V ISA model, which goes into significantly more detail on the architecture of RISC-V, and formalizes not just the instructions, but the execution and memory models, memory consistency model, etc. I am (and I believe Watson is as well following our discussion) of the opinion that our ISA document belongs squarely in the first category, and shouldn't try to also fit into the second. We're defining the instruction encodings, and describing their semantics at a high level without much formality. This is intentional -- our WG charter specifies many more documents that cover all of these details (some of which will likely be contentious and require a lot of thought and discussion) in the proper scopes. For example, our planned documents include but are not limited to: - [I] an architecture and framework document - one or more documents that recommend conventions and guidelines for producing portable BPF program binaries - [PS] cross-platform map types allowing native data structure access from BPF programs - [PS] cross-platform helper functions, e.g., for manipulation of maps - [PS] cross-platform BPF program types that define the higher level execution environment for BPF programs With all that said, I think our ISA document would improve a lot with the following changes: 1. Removing all the ABI-specific stuff from the ISA document. For example, calling conventions need to go. This was discussed at IETF 117, so should hopefully be non-controversial. I'll send a patch later that moves this to a separate abi.rst document that we can then fold into Will's work. 2. This wasn't discussed at IETF 117, but also removing extraneous verbiage such as the "Helper functions" and "Maps" paragraphs, and maybe more such as "Platform Variables". These blurbs are useful for giving some context on the actual instructions in the ISA, but they're insufficient on their own to be of practical use. So the TL;DR is: let's make the ISA document just an ISA document. We're in it for the long haul, and the time to properly introduce, define, and explain all of these concepts is when we write the documents that are meant to capture all of that information. Watson -- please let me know if I've misrepresented anything. It would be great to get others' thoughts as well. Thanks, David
