4 ms·

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 spa

• 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).