Chris SiebenmannJan 19, 2023

TIL that the ppc64 (PowerPC 64-bit) architecture overloads 'or r1,r1,r1' (and the same using all r6 or r2) to change the (hardware) priority of your thread. This came up in a Go code generation issue, and Raymond Chen mentioned it in passing in 2018.

https://github.com/golang/go/issues/57741
https://devblogs.microsoft.com/oldnewthing/20180809-00/?p=99455
Also see the discussion in this PDF: https://student.ing-steen.se/unix/aix/redbooks/sg245768.pdf

runtime: performance regression due to bad instruction used in morestack_noctxt for ppc64 in CL 425396 · Issue #57741 · golang/go

What version of Go are you using (go version)? $ go version latest Does this issue reproduce with the latest release? yes What operating system and processor architecture are you using (go env)? go...

GitHub
Show threadBorogoveJan 19, 2023
@cks WHAT.
Show threadBorogoveJan 19, 2023
@cks Does the Go compiler actually generate an ASCII asm file to pass to an assembler these days, or does it write an object file directly? It seems like a footgun for the assembler to accept `or r1,r1,r1` instead of inventing new mnemonics for the priority opcodes.
Show threadChris Siebenmann

@borogove Go writes the object file directly (and actually has its own internal assembler format anyway). I don't know if normal ppc64 assemblers accept the 'or' as written or error out saying 'if you really want to do this, you have to use our special instruction that assembles to the same bytes'.

(It certainly is an *interesting* way to add new instructions to your processor architecture, especially ones that may not be universally implemented since they only matter with hardware threads...)

Jan 19, 2023 at 6:09pmWeb