[PATCH 0/9] eBPF support for GNU binutils

[Jose E. Marchesi]

    >> 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,

Well, the way I read the spec, these look like different instructions
operating on the same registers, only with different semantics :)

But yeah, it is basically two different ways to look at the same thing,
at the ISA level.

Given that both llvm and ebpf_asm use some kind of sub-registers (using
different register names, or suffixes) I guess I could do the same... In
principle I don't have a strong preference, but I have to think about
it, and determine what would be the impact in my on-going GCC backend.

Thanks for the info.  Much appreciated.