4 ms·

It's older than POWER8. The same thing exists on Cell, Xenon, and I think PPC970/POWER4 too IIRC. And it's actually pretty common for CPUs to encode hints in

It's older than POWER8. The same thing exists on Cell, Xenon, and I think PPC970/POWER4 too IIRC. And it's actually pretty common for CPUs to encode hints in unused nop equivalents. RISC-V does that too. X86 does it too with Intel's Control-Flow Enforcement Technology being an example.

082349872349872 4y ago
Thanks; that also explains why x86 would bother to champion specific NOP sequences specifically for NOP purposes.
- userbinator 4y ago
  The official x86 NOP is at 90h (and actually originally meant "xchg ax, ax" --- https://news.ycombinator.com/item?id=10437070 https://news.ycombinator.com/item?id=10437070). All the other new sequences meant to be NOPs on older processors were allocated from the reserved space (e.g. segment override prefixes on intrasegment conditional jumps becoming branch hints on the P4.)
  - monocasa 4y ago
    There's actually several official nops on x86, each of different instruction length. To be fair, I think they back ported this behavior to the official arch after Microsoft relied on it. AMD defines up to 11 byte sequeces, Intel defines up to 9 byte sequences. 90 NOP 6690 66 NOP 0f1f00 NOP DWORD ptr [EAX] 0f1f4000 NOP DWORD ptr [EAX + 00H] 0f1f440000 NOP DWORD ptr [EAX + EAX*1 + 00H] 660f1f440000 66 NOP DWORD ptr [EAX + EAX*1 + 00H] 0f1f8000000000 NOP DWORD ptr [EAX + 00000000H] 0f1f840000000000 NOP DWORD ptr [EAX + EAX*1 + 00000000H] 660f1f840000000000 66 NOP DWORD ptr [EAX + EAX*1 + 00000000H] 66660f1f840000000000 66 66 NOP DWORD ptr [EAX + EAX*1 + 00000000H] 6666660f1f840000000000 66 66 66 NOP DWORD ptr [EAX + EAX*1 + 00000000H] https://stackoverflow.com/questions/25545470/long-multi-byte-nops-commonly-understood-macros-or-other-notation https://stackoverflow.com/questions/25545470/long-multi-byte...
    - userbinator 4y ago
      That's basically combinations of "regular NOP", "NOP with an ignored prefix", and "NOP with a ModRM". The regular one has been there since the 8086, the prefixed NOPs are 386+ (I believe on 8086 the 6x row aliases to 7x conditional jumps, and the 186 and 286 will cause a #UD exception), and the latter is P6+ but has a very interesting history: https://www.jookia.org/wiki/Nopl https://www.jookia.org/wiki/Nopl
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.

082349872349872 4y ago

Thanks; that also explains why x86 would bother to champion specific NOP sequences specifically for NOP purposes.

userbinator 4y ago
The official x86 NOP is at 90h (and actually originally meant "xchg ax, ax" --- https://news.ycombinator.com/item?id=10437070 https://news.ycombinator.com/item?id=10437070). All the other new sequences meant to be NOPs on older processors were allocated from the reserved space (e.g. segment override prefixes on intrasegment conditional jumps becoming branch hints on the P4.)
- monocasa 4y ago
  There's actually several official nops on x86, each of different instruction length. To be fair, I think they back ported this behavior to the official arch after Microsoft relied on it. AMD defines up to 11 byte sequeces, Intel defines up to 9 byte sequences. 90 NOP 6690 66 NOP 0f1f00 NOP DWORD ptr [EAX] 0f1f4000 NOP DWORD ptr [EAX + 00H] 0f1f440000 NOP DWORD ptr [EAX + EAX*1 + 00H] 660f1f440000 66 NOP DWORD ptr [EAX + EAX*1 + 00H] 0f1f8000000000 NOP DWORD ptr [EAX + 00000000H] 0f1f840000000000 NOP DWORD ptr [EAX + EAX*1 + 00000000H] 660f1f840000000000 66 NOP DWORD ptr [EAX + EAX*1 + 00000000H] 66660f1f840000000000 66 66 NOP DWORD ptr [EAX + EAX*1 + 00000000H] 6666660f1f840000000000 66 66 66 NOP DWORD ptr [EAX + EAX*1 + 00000000H] https://stackoverflow.com/questions/25545470/long-multi-byte-nops-commonly-understood-macros-or-other-notation https://stackoverflow.com/questions/25545470/long-multi-byte...
  - userbinator 4y ago
    That's basically combinations of "regular NOP", "NOP with an ignored prefix", and "NOP with a ModRM". The regular one has been there since the 8086, the prefixed NOPs are 386+ (I believe on 8086 the 6x row aliases to 7x conditional jumps, and the 186 and 286 will cause a #UD exception), and the latter is P6+ but has a very interesting history: https://www.jookia.org/wiki/Nopl https://www.jookia.org/wiki/Nopl

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.