3 ms·

Ideally the architecture has the foresight to carve out a specific 'hint' space as "is a NOP today, may do something magical on tomorrow's CPU" rather than havi

by pm215 4y ago

Ideally the architecture has the foresight to carve out a specific 'hint' space as "is a NOP today, may do something magical on tomorrow's CPU" rather than having to retrospectively borrow encodings that theoretically did something nop-like. Sometimes "specified but useless" encoding space gets taken back for other reasons -- Arm originally blew 1/16th of the entire encoding space on NOPs by allowing and documenting the instruction condition code 0xF to mean "never execute" because it happened to fall neatly out of the original design. That later got taken back somewhere around Armv4 or v5 to be used for new instructions...

monocasa 4y ago
I'd argue that PowerPC and most modern archs have done this. For a couple decades all of the major archs have documented 'preferred NOPs'. They then document that other NOPs will give them same results but hint that this might cause your code to run very slow, on the order of worst case of code not optimized for newer uarchs.
- pm215 4y ago
  That's not quite the same as a true hint space, though, because it documents that code can rely on the NOP behaviour even if not the performance. Arm's HINT space is specifically "must NOP now, must not be used by software": https://developer.arm.com/documentation/ddi0602/2022-06/Base-Instructions/HINT--Hint-instruction- https://developer.arm.com/documentation/ddi0602/2022-06/Base...
  - monocasa 4y ago
    > That's not quite the same as a true hint space, though, because it documents that code can rely on the NOP behaviour even if not the performance. But that's what a hint is. By definition a hint can't affect execution results, only performance. And or r0, r0, r0 has been defined as the one true Power NOP for decades now, with these semantics documented in the main Power ISA doc (including or r1,r1,r1 being a hint for SMT priority). Whoever was being cute in the golang compiler simply didn't read the relevant docs in the first place.
    - pm215 4y ago
      Some of the insns later defined in the Arm hint space are definitely not NOPs, though -- the pointer-authentication ones will write results to registers, for instance. The requirement is "if code that knows about the newly architected instruction uses it correctly but runs on a CPU where it's a NOP the behaviour is acceptable", not "code written before the insn in hint space is allocated can use this assuming it is always going to be a pure NOP and will never alter registers, undef, etc". The contract between the code and the ISA is subtly different. I agree that in this specific case the software side was in the wrong (though if the official disassembly had been "hint insn 1" rather than "or r1,r1,r1" I suspect the bug wouldn't have got into the code in the first place).

by pm215 4y ago

monocasa 4y ago

I'd argue that PowerPC and most modern archs have done this. For a couple decades all of the major archs have documented 'preferred NOPs'. They then document that other NOPs will give them same results but hint that this might cause your code to run very slow, on the order of worst case of code not optimized for newer uarchs.

pm215 4y ago
That's not quite the same as a true hint space, though, because it documents that code can rely on the NOP behaviour even if not the performance. Arm's HINT space is specifically "must NOP now, must not be used by software": https://developer.arm.com/documentation/ddi0602/2022-06/Base-Instructions/HINT--Hint-instruction- https://developer.arm.com/documentation/ddi0602/2022-06/Base...
- monocasa 4y ago
  > That's not quite the same as a true hint space, though, because it documents that code can rely on the NOP behaviour even if not the performance. But that's what a hint is. By definition a hint can't affect execution results, only performance. And or r0, r0, r0 has been defined as the one true Power NOP for decades now, with these semantics documented in the main Power ISA doc (including or r1,r1,r1 being a hint for SMT priority). Whoever was being cute in the golang compiler simply didn't read the relevant docs in the first place.
  - pm215 4y ago
    Some of the insns later defined in the Arm hint space are definitely not NOPs, though -- the pointer-authentication ones will write results to registers, for instance. The requirement is "if code that knows about the newly architected instruction uses it correctly but runs on a CPU where it's a NOP the behaviour is acceptable", not "code written before the insn in hint space is allocated can use this assuming it is always going to be a pure NOP and will never alter registers, undef, etc". The contract between the code and the ISA is subtly different. I agree that in this specific case the software side was in the wrong (though if the official disassembly had been "hint insn 1" rather than "or r1,r1,r1" I suspect the bug wouldn't have got into the code in the first place).