Alexei Starovoitov <alexei.starovoitov@xxxxxxxxx> wrote: > On Tue, Aug 1, 2023 at 6:55 PM Dave Thaler <dthaler@xxxxxxxxxxxxx> > wrote: [...] > I interpreted this as saying no one cared about having the IANA > considerations section in a separate file there. But we confirm consensus on > the list, so it's fine to revisit now if there are good reasons to do so. > > I think IANA consideration section is orthogonal to giant opcode table. It's not orthogonal, such a table is a required part of the IANA Considerations section. See https://www.rfc-editor.org/rfc/rfc8126#section-2.2 (specifically the "Initial assignments and reservations"). > They're related, but don't have to be together in one .rst file. True. > I think it's cleaner to have separate instruction-set-opcode.rst Sure. > We also went back and forth during the meeting whether hierarchy of tables > is prefered or one table. During the meeting, no one argued for one table (other than me saying if no one has a preference, I'll leave it the way it is), and several people argued for multiple tables so I took that as potential consensus for multiple tables. But again, we confirm consensus on the list so if anyone here has a reason why one table or multiple tables are technically better, please speak up. > Currently you have one table and it actually looks > very readable. My preference would be to keep it this way and carry over to > IANA eventually as one table. Personally, I agree that I find one table more readable. But it sounded like others in the meeting found multiple tables more readable. Comparing slides 8 and 9 from the meeting, at https://datatracker.ietf.org/meeting/117/materials/slides-117-bpf-isa-extension-policy-03 folks will notice that on slide 9 in the multiple tables example, I omitted columns from the opcode table other than the single key field (opcode, src, or whatever depending on the table) and the description. Thus for say opcode 0x17 (dst -= imm) the one table version shows src 0x0 and imm any, whereas the multiple tables one doesn't. Perhaps it could, but one thing I like about the single table version is that as currently depicted, opcode 0x17 with src != 0x0 is currently undefined (i.e., available for later use), whereas the multiple table version with a single key field depicts it as defined as "dst -= imm" with English text in the body of the doc that says src must be zero. Thus the single table version that presents src as a key field unless it contains "any" means there's plenty of instruction space left unallocated. Anyone who actually wants to disallow any future instructions from ever using opcode 0x17 with src != 0x0 might prefer the multiple tables (i.e., without src as a key field). But to me, this could potentially be a technical argument for keeping one table. Dave
