2 ms·

> like, i think if that were possible then we wouldn't need new linker relocation types for risc-v? how are you going to patch an auipc or st instruction to hav

> like, i think if that were possible then we wouldn't need new linker relocation types for risc-v? how are you going to patch an auipc or st instruction to have the right stack offsets and memory addresses without knowing about the weird platform-specific details like how you have to increment the auipc immediate field to compensate for the sign-extension of the associated addi or jump field in the case where its high bit is set? That knowledge is encoded into the relocation type (e.g. R_X86_64_64) for given ABI. So the system does know about relocations, and some relocation types will be specific to a single architecture (R_RISCV_CALL_PLT in this example, I think?). But that's all you need to know about those architectures.

kragen 3y ago
sure, you don't need to know the opcodes, just the encodings, but the claim in the paper seems to be stronger than that
- lifthrasiir 3y ago
  Given only a small subset of relocations will be actually used, I think the claim itself is correct but could have been explained better. For x86-64 it only has to recognize R_X86_64_64 (or equivalents in other formats) for example.
  - kragen 3y ago
    the claim is 'the system does not need any knowledge of platform-specific machine instruction encoding', but things like incrementing the upper 20 bits iff bit 11 is set seem uncontroversially 'platform-specific machine instruction encoding' usually, and certainly to get the performance numbers they claim, things like scrambling the immediate bits and putting 20 bits of the immediate in one instruction and 12 bits in another are also considered platform-specific machine-instruction encoding, but you could imagine a system which supports sticking arbitrary bitfields in arbitrary places
    - lifthrasiir 3y ago
      > you could imagine a system which supports sticking arbitrary bitfields in arbitrary places If there is such an architecture, yeah the system may have to support them, or more accurately: relocations would be defined for them which have to be implemented by the system. But that's still a tiny portion of the actual instruction coding. I believe most people including authors would imagine something like an assembler or disassembler as a comparison, so pedantry aside, the claim is almost true.
      - kragen 3y ago
        no, i mean, you could support things like sparc and arm set-low/set-high instructions just by having a relocation type with arguments, say, 16, 31, and 9, meaning 'bits 16:31 of the constant should be stored in the bitfield starting at bit 9', and that almost works for risc-v auipc, lui, addi, and jr, too, even though the bit fields are split into tiny scrambled pieces in whatever position was most convenient for the chip they were working on at the time. but that means that your stencil linker has to interpret those 16, 31, and 9 numbers as it's generating the code, which is slow. but it doesn't help with the problem of risc-v's sign-extension of the 12-bit immediate in addi. also, now that i think about it, it isn't really sufficient for pc-relative addressing, because for that you need to propagate borrow bits through the scrambled bit fields i don't think the distinction is pedantic between a compiler that needs custom code for each new machine instruction encoding and one which can support a new architecture just by giving it a data file (for some reasonable set of new architectures, anyway). the paper claims that their system is the latter, and i don't believe it

kragen 3y ago

sure, you don't need to know the opcodes, just the encodings, but the claim in the paper seems to be stronger than that

lifthrasiir 3y ago
Given only a small subset of relocations will be actually used, I think the claim itself is correct but could have been explained better. For x86-64 it only has to recognize R_X86_64_64 (or equivalents in other formats) for example.
- kragen 3y ago
  the claim is 'the system does not need any knowledge of platform-specific machine instruction encoding', but things like incrementing the upper 20 bits iff bit 11 is set seem uncontroversially 'platform-specific machine instruction encoding' usually, and certainly to get the performance numbers they claim, things like scrambling the immediate bits and putting 20 bits of the immediate in one instruction and 12 bits in another are also considered platform-specific machine-instruction encoding, but you could imagine a system which supports sticking arbitrary bitfields in arbitrary places
  - lifthrasiir 3y ago
    > you could imagine a system which supports sticking arbitrary bitfields in arbitrary places If there is such an architecture, yeah the system may have to support them, or more accurately: relocations would be defined for them which have to be implemented by the system. But that's still a tiny portion of the actual instruction coding. I believe most people including authors would imagine something like an assembler or disassembler as a comparison, so pedantry aside, the claim is almost true.
    - kragen 3y ago
      no, i mean, you could support things like sparc and arm set-low/set-high instructions just by having a relocation type with arguments, say, 16, 31, and 9, meaning 'bits 16:31 of the constant should be stored in the bitfield starting at bit 9', and that almost works for risc-v auipc, lui, addi, and jr, too, even though the bit fields are split into tiny scrambled pieces in whatever position was most convenient for the chip they were working on at the time. but that means that your stencil linker has to interpret those 16, 31, and 9 numbers as it's generating the code, which is slow. but it doesn't help with the problem of risc-v's sign-extension of the 12-bit immediate in addi. also, now that i think about it, it isn't really sufficient for pc-relative addressing, because for that you need to propagate borrow bits through the scrambled bit fields i don't think the distinction is pedantic between a compiler that needs custom code for each new machine instruction encoding and one which can support a new architecture just by giving it a data file (for some reasonable set of new architectures, anyway). the paper claims that their system is the latter, and i don't believe it