> On 21 May 2019, at 18:06, Jose E. Marchesi <jose.marchesi@xxxxxxxxxx> wrote: > > > Hi Jiong. > >> Despite using a different syntax for the assembler (the llvm assembler >> uses a C-ish expression-based syntax while the GNU assembler opts for >> a more classic assembly-language syntax) this implementation tries to >> provide inter-operability with clang/llvm generated objects. > > I also noticed your implementation doesn’t seem to use the same sub-register > syntax as what LLVM assembler is doing. > > x register for 64-bit, and w register for 32-bit sub-register. > > So: > add r0, r1, r2 means BPF_ALU64 | BPF_ADD | BFF_X > add w0, w1, w1 means BPF_ALU | BPF_ADD | BPF_X > > ASAICT, different register prefix for different register width is also adopted > by quite a few other GNU assembler targets like AArch64, X86_64. > > Right. I opted for using different mnemonics for alu and alu64 > instructions, as it seemed to be simpler. > > What was your rationale for using sub-register notation? It is the same instruction operating on different register classes, sub-register is a new register class, so define separate notation for them. This also simplifies compiler back-end when generating sub-register instructions, at least for LLVM, and is likely for GCC as well. LLVM eBPF backend has full support for generating sub-register ISA, > Are you > planning to support instructions (or pseudo-instructions) mixing w and x > registers in the future? > >> In particular, the numbers of the relocations used for instruction >> fields are the same. These are R_BPF_INSN_64 and R_BPF_INSN_DISP32. >> The later is resolved at load-time by bpf_load.c. > > I think you missed the latest JMP32 instructions. > > https://github.com/torvalds/linux/blob/master/Documentation/networking/filter.txt#L870 > > Oh thanks for spotting that. > Adding support for it :)
