In reply to a long conversation: <snip> > > Could you please be specific which instruction in table 4 is not obvious? The question isn't obvious, the question is unambigious, and C is not great for this. Maybe with a reference and some text it would get better. > > > > > > > > > The good news is I think this is very fixable although tedious. > > > > > > > > > > The other thornier issues are memory model etc. But the overall structure seems good > > > > > and the document overall makes sense. > > > > > > What do you mean by "memory model" ? > > > Do you see a reference to it ? Please be specific. > > > > No, and that's the problem. Section 5.2 talks about atomic operations. > > I'd expect that to be paired with a description of barriers so that > > these work, or a big warning about when you need to use them. > > That's a good suggestion. > A warning paragraph that BPF ISA does not have barrier instructions > is necessary. > > > For > > clarity I'm pretty unfamiliar with bpf as a technology, and it's > > possible that with more knowledge this would make sense. On looking > > back on that I don't even know if the memory space is flat, or > > segmented: can I access maps through a value set to dst+offset, or > > must I always used index? I'm just very confused. > > flat vs segmented is an orthogonal topic. > We definitely need to cover it in the architecture doc. > BPF WG charter requires us to produce it as Informational doc eventually. Huh? If you access memory through specialized descriptors+offsets that's very different from arbitrary computations with addresses, even if they do trap. A little explanation might orient the reader to understand what is going on. As is I thought "ok, it's flat" and then saw the maps and really got thrown for a loop. > > As far as memory model BPF adopts LKMM (Linux Kernel Memory Model). > https://www.open-std.org/jtc1/sc22/wg21/docs/papers/2020/p0124r7.html > > We can add a reference to it from BPF ISA doc, but since > there are no barrier instructions at the moment the memory model > statement would be premature. > The work on "BPF Memory Model" have been ongoing for quite some time. > For example see: > https://lpc.events/event/11/contributions/941/attachments/859/1667/bpf-memory-model.2020.09.22a.pdf > > BPF Memory Model is certainly an important topic, but out of scope for ISA. I expect that an ISA defines the semantics of the instructions. Which absolutely includes the memory model. Now maybe we're envisioning a different splitting of this information, but I don't see how it can't be at a different level if you want to give the instructions semantics. Sincerely, Watson Ladd -- Astra mortemque praestare gradatim
