On Tue, Oct 4, 2022 at 10:09 AM Dave Thaler <dthaler@xxxxxxxxxxxxx> wrote: > > Regarding the tables: > > Such tables are seen as invaluable for determining correctness of other > > implementations. So the feedback is that it's important to have such if we > > want everyone else to do the right thing. > > > > > These people should speak up then. > > > > I agree. > > Here's two public examples... > > Christoph Hellwig, said on May 17 at https://lore.kernel.org/bpf/20220517091011.GA18723@xxxxxx/: > > One useful thing for this would be an opcode table with all the > > optional field usage in machine readable format. > > > > Jim who is on CC has already built a nice table off all opcodes based > > on existing material that might be a good starting point. > > Jim Harris responded on that thread with a strawman which was > used as the basis for the table in the appendix. > > Jim then commented in the github version on August 30: > > In my opinion, this table is the biggest thing that has been missing, > > and will be most essential for a more "formal" specification. I think an opcode table is a huge help for developing alternate eBPF implementations - anything that makes it more explicit which opcodes are valid (and which ones are not). For example, the section for BPF_ALU and BPF_ALU64 classes lists the operation codes. BPF_END is in that list. Description says "see separate section below". The "Byte swap instructions" section then says that byte swap instructions always use BPF_ALU, even for 64-bit widths. So an implementer can synthesize all of this to determine that opcodes 0xD7 and 0xDF (which have BPF_ALU64 | BPF_END) are not valid. It would be more clear if somewhere there was a list that explicitly showed that 0xD4 and 0xDC (BPF_ALU | BPF_END) were valid, but 0xD7 and 0xDF were not. If there's concern that an appendix gets out of sync with the code and the primary sections of the instruction set doc, maybe these opcodes can be added to the existing per-class-code tables in the instruction set doc. A full opcode table could probably be generated from those tables instead of the hand-written one that Dave and I worked on in his patch. -Jim > I will encourage them and others to comment on this thread.
