3 ms·

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

• 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