proposal: runtime: drop support for linux/armv5E and linux/armv6

[minux]

Since the introduction of Linux/ARM support, the minimum required hardware to run Go with Linux was ARMv5E, e.g.ARM926.

At that time, this choice makes sense because ARM9 systems are still around, and we even had an ARMv5E builder for some time.

However, ARMv5E lacks some important atomic instruction support. LDREX/STREX is introduced in ARMv6 (ARM11), and LDREXB/STREXB, LDREXH/STREXH, LDREXD/STREXD are introduced in ARMv6K. Without these instructions, we resort to emulating the required 64-bit atomic operation using 57 spinlocks selected by address (which uses mod and is a slow operation on ARM) [see https://tip.golang.org/src/runtime/internal/atomic/atomic_arm.go]

I don't know how many projects out there that still uses ARMv5E and Go, but I don't expect many. I propose to increase the minimum architectural requirement to ARMv6 (and possibly ARMv6K), so that at least we can use LDREX/STREX, which should help a lot with the new atomic-heavy runtime.

To summarize the benefits,

1. if we raise requirement to ARMv6, then we can intrinsicify 32-bit atomics.
2. if we raise requirement to ARMv6K, then in addition to 1, we no long can remove the emulated 64-bit atomics from runtime by using the native LDREXD/STREXD instructions, but also intrinsicify them in the compiler like other ports. We can also use YIELD instruction to address #16663.

If you still use Go on ARMv5E systems, please help by listing the processor model used. Thanks.

PS: other supported OSes do require ARMv6K as only Linux provides required 64-bit cas kernel helper for sync/atomic. Another way to go is to modify the runtime/internal/atomic package to:

1. use LDREXD/STREXD on non-linux,
2. use kernel cas64 on linux. But this solution will complicate maintaining the code and as we don't have a real ARMv5E builder, I think the support is certainly going to bitrot.

PS2: The core used by Raspberry Pi 1, ARM1176JZF-S, is ARMv6K, so this proposal won't affect Raspberry Pi 1, the most popular ARMv6 systems.

[aajtodd]

Couple of questions:

1. If ARM v5/6 support is dropped will there still be a way to target ARM v7 with no FPU / VFP support?

It appears to be a rare case but there are some v7 processors without VFP support is my current understanding (which admittedly is limited).

2. Would this affect gccgo as well?

[davecheney]

If ARM v5/6 support is dropped will there still be a way to target ARM v7 with no FPU / VFP support?

No. They would have to use the kernel provided soft fpu.

Would this affect gccgo as well?

No.

[aajtodd]

@davecheney Thanks for the follow up.

I'm not sure I follow regarding using kernel provided soft fpu.

Today when I build and target GOARM=7 it generates an executable with e.g. vmov.f32 instructions. Is there a way to force ARMv7 to use soft fpu today and not generate those instructions? I basically hit the same issue as #18483 except I have no workaround.

It seems from the comments in this thread that vfp support is directly tied to the GOARM env variable so I was trying to ascertain how or if soft fpu will be supported for ARMv7 if ARMv5/6 is dropped.

[davecheney]

On Wed, 8 Mar 2017, 10:05 Aaron Todd notifications@github.com wrote:

@davecheney https://github.com/davecheney Thanks for the follow up.

I'm not sure I follow regarding using kernel provided soft fpu.

Today when I build and target GOARM=7 it generates an executable with e.g. vmov.f32 instructions. Is there a way to force ARMv7 to use soft fpu today and not generate those instructions? I basically hit the same issue as #18483 https://github.com/golang/go/issues/18483 except I have no workaround.

What SoC are you using?

It seems from the comments in this thread that vfp support is directly tied

to the GOARM env variable so I was trying to ascertain how or if soft fpu will be supported for ARMv7 if ARMv5/6 is dropped.

Yes, soft to support will be dropped.

—

You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/golang/go/issues/17082#issuecomment-284889908, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAcA261rulIZhJP5720ZscsJ7ZDBkglks5rjeKygaJpZM4J7K4x .

[aajtodd]

Ok thank you for clearing that up for me.

What SoC are you using?

It's an ARM Cortex A9 but vfp is not supported (hi3535 I believe). I inquired today about it and the response was essentially "vfp is not supported, yes it's rare for ARMv7, and yes it is unfortunate"

[rsc]

I don't know that it's a sure thing we will expire ARMv5. We said we would in the Go 1.8 release notes, so we could do so in Go 1.9, but a number of people above have requested continuing support. We moved over to #19075 to figure out the general policy, and once that's settled (it looks mostly settled) we'll need to return here.

[gopherbot]

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

[rsc]

Based on the considerations listed at the end of #19075 (hardware is still available, users still want it, upkeep has minimal costs), we will keep GOARM=5 going for a while longer.

Therefore declining proposal.