On Wed, Dec 20, 2023 at 11:00:59PM -0800, Christoph Hellwig wrote: > On Tue, Dec 19, 2023 at 07:28:10PM -0800, Alexei Starovoitov wrote: > > Right, but bringing the verifier into the "compliance picture" > > makes the ISA standard incomplete. > > Same can be said about nfp compliance. It's compliant with an ISA, > > but the verifier will reject things it doesn't support. > > Yes, that's a good point. Especially for anything call related I think > it's fine to say they are a mandatory part of the basic some coarse > group, but a given program type might not support it, but that is > enforced by the verifier as the compiler should not have to known about > the program type. Agreed as well. > > > All ld_imm64 and call insns look the same. The compiler emits > > them the same way. > > The src_reg encoding is what libbpf does based on compiler relocations. > > > > Then the verifier checks them differently and later JIT sees > > _all_ ld_imm64 as one type of instruction. > > Same with call insn. To x86/arm64/riscv JITs there is only one BPF CALL insn. > > Yup. Another case for ISA supported vs program type supported (and > enforced by the verifier). +1 So how do we want to move forward here? It sounds like we're leaning toward's Alexei's proposal of having: - Base Integer Instruction Set, 32-bit - Base Integer Instruction Set, 64-bit - Integer Multiplication and Division - Atomic Instructions And then either having 3 separate groups for the calls, or putting all 3 in the basic group? I'd lean towards the latter given that we're decoupling ISA compliance from the verifier, but don't feel strongly either way.
Attachment:
signature.asc
Description: PGP signature
