runtime: procyield doesn't use yield instruction on ARM, unlike ARM64

[swolchok]

Please answer these questions before submitting your issue. Thanks!

1. What version of Go are you using (go version)?
   Master
2. What operating system and processor architecture are you using (go env)?
   ARM
3. What did you do?
   If possible, provide a recipe for reproducing the error.
   A complete runnable program is good.
   A link on play.golang.org is best.

code inspection:

go/src/runtime/asm_arm.s

Line 971 in 690de51

yieldloop:

I have not had a problem with this myself, just happened to notice it.

1. What did you expect to see?

Use of the YIELD instruction, which exists on ARMv6K and newer per http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dui0204j/Cjafcggi.html Presumably, this would need some kind of architecture gating, because Go supports ARMv5 and ARMv6: https://github.com/golang/go/wiki/GoArm

1. What did you see instead?

Busy-wait with no YIELD, unlike the ARM64 version:

go/src/runtime/asm_arm64.s

Line 473 in 690de51

YIELD

Note that it could be the case that the ARM64 version is in error, since runtime.procyield takes a loop count and (according to the linked ARM documentation) YIELD may cause the thread to be suspended.

[bradfitz]

/cc @cherrymui

[cherrymui]

add @minux, who might know the original idea.
Architecture gating might be a reason. There are not so much code in the runtime that is architecture gated.

[minux]

YIELD is only available in ARMv6K and above. Yet another reason for dropping ARMv6/v5 support in #17082.

[aclements]

@minux, based on my reading of the ARM spec, it sounds like CPUs that don't support YIELD will just interpret it as a NOP. If so, it would be harmless to add to procyield.

[aclements]

Taking another look at this, ARMv7 skirts around clearly stating that YIELD is a NOP on earlier architectures, but I'm pretty sure it is.

Based on the instruction encoding, on ARMv5 it will be interpreted as an MSR instruction with

  R=0
  field_mask=0000
  SBO=1111
  rotate_imm=0000
  8_bit_immediate=00000001

If I'm following the pseudo-code correctly, the ultimate effect of this will be CPSR = CPSR. In other words, a NOP.

[gopherbot]

CL https://golang.org/cl/45250 mentions this issue.