3 ms·

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

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

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