On Tue, Jul 25, 2023 at 11:37 AM Watson Ladd <watsonbladd@xxxxxxxxx> wrote: > > On Tue, Jul 25, 2023 at 9:15 AM Alexei Starovoitov > <alexei.starovoitov@xxxxxxxxx> wrote: > > > > On Tue, Jul 25, 2023 at 7:03 AM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > > > > > I am forwarding the email below (after converting HTML to plain text) > > > to the mailto:bpf@xxxxxxxxxxxxxxx list so replies can go to both lists. > > > > > > Please use this one for any replies. > > > > > > Thanks, > > > Dave > > > > > > > From: Bpf <bpf-bounces@xxxxxxxx> On Behalf Of Watson Ladd > > > > Sent: Monday, July 24, 2023 10:05 PM > > > > To: bpf@xxxxxxxx > > > > Subject: [Bpf] Review of draft-thaler-bpf-isa-01 > > > > > > > > Dear BPF wg, > > > > > > > > I took a look at the draft and think it has some issues, unsurprisingly at this stage. One is > > > > the specification seems to use an underspecified C pseudo code for operations vs > > > > defining them mathematically. > > > > Hi Watson, > > > > This is not "underspecified C" pseudo code. > > This is assembly syntax parsed and emitted by GCC, LLVM, gas, Linux Kernel, etc. > > I don't see a reference to any description of that in section 4.1. > It's possible I've overlooked this, and if people think this style of > definition is good enough that works for me. But I found table 4 > pretty scanty on what exactly happens. Could you please be specific which instruction in table 4 is not obvious? > > > > > > 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. 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.
