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 runtime: procyield doesn't use yield instruction on ARM, unlike ARM64 #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.

[minux]

/cc @cherrymui @davecheney @josharian

[josharian]

@hasty

[davecheney]

I'm fine with this.

On Tue, Sep 13, 2016 at 10:31 AM, Josh Bleecher Snyder <
[email protected]> wrote:

@hasty https://github.com/hasty

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#17082 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA_pdNkUCP-Uhku-pBXNnA4Z7NqSgks5qpe7ogaJpZM4J7K4x
.

[josharian]

SGTM

[bradfitz]

SGTM, especially if it means I can kill the not-really-ARM5 linux-arm-arm5 builders.

[minux]

To be precise, do you support only removing armv5 support or also requiring armv6k (RPI 1 won't be affected)?

[minux]

Killing the linux-arm5 builder also requires us to drop GOARM=5 support, which is also used (overloaded) to mean FPU-less ARM CPUs (which does not necessarily mean ARMv5. Yes, this is very confusing.)

[bradfitz]

I know close to zero about the dozens of flavors of ARM but if all Raspberry Pis still work I find it hard to object to requiring ARMv6K if that makes things easier.

[hasty]

Thanks, @josharian
No objections here; we've moved on to ARMv7A.

[davecheney]

I understood your request to be "remove GOARM=5", and I agree with that.

On Tue, Sep 13, 2016 at 12:22 PM, Minux Ma [email protected] wrote:

Killing the linux-arm5 builder also requires us to drop GOARM=5 support,
which is also used (overloaded) to mean FPU-less ARM CPUs (which does not
necessarily mean ARMv5. Yes, this is very confusing.)

—
You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub
#17082 (comment), or mute
the thread
https://github.com/notifications/unsubscribe-auth/AAAcA9xGsaStiiuyeGF20NGifk9ZzWm6ks5qpgjKgaJpZM4J7K4x
.

[peteArnt]

The Atmel SAM9G25 SOC looks like it may be a victim of this feature request. It implements the ARM architecture version 5TEJ instruction set. Products like the Arietta G25 from ACME systems (which I use) will become incompatible with future versions of the GO ARM runtime if what I'm reading here is correct.

While I generally agree with what is proposed here for GO 1.8, is there no way for a developer to re-introduce a V5-compatible runtime into his/her own GO development environment?

If the architecture requirement gets bumped to ARMv6 or 6K, how long will that be good for?

-Pete

[minux]

The main goal for this proposal is to bump the minimum ARM requirement to ARMv6K so that we can use native 8-bit/32-bit/64-bit LDREX/STREX instructions and inline them in the program. (As explained in the proposal, we currently use emulated 64-bit atomic operations in the runtime.) Once we drop the support for v5E and v6 (without K), it will be pretty hard to regain the support because it's not a master of re-introduce necessary runtime functions. One difficulty for maintaining ARMv5E and ARMv6 support is that, it's really hard to find systems with enough memory to host a Go builder (we need at least 512MB, preferably 1GB) Dropping support for ARMv5E mainly affect various ARM926 systems, and dropping support for ARMv6 mainly affects various ARM1136 and ARM1156 based SoCs (one notable example iMX3x series, used in earlier Kindle eReaders.) There are only two ARM11-series processors that implements ARMv6K: ARM1176 and ARM11MPCore. The other two ARM1136 and ARM1156 doesn't implement the required 8/64-bit LDREX/STREX instruction. We could consider just dropping ARMv5E support, and then see if we can reduce the use of 64-bit atomic operations in the runtime. @aclements, are 64-bit atomic operations critical for runtime performance on 32-bit systems? If not, I think we can just drop ARMv5E support for Go 1.8 in order to continue support ARM11 processors.

[aclements]

@aclements, are 64-bit atomic operations critical for runtime performance on 32-bit systems?

It's hard to guess, but I don't think so. I took a quick look through all of the 64-bit atomic operations and we're pretty careful to amortize the cost of almost all of them. It might worth turning gcController.dedicatedMarkWorkersNeeded and gcController.fractionalMarkWorkersNeeded into int32s, since those can get hit on every scheduling decision during GC, but those are also perfectly fine as int32s (I think I just made them int64s because we don't have atomic ops on int32).

[adg]

We should probably do some more research to find people who might be using these chips. @minux, do you want to mail golang-nuts? Failing any pushback, this sounds like it's a go.

[rsc]

Minux, did you email golang-nuts?

[rsc]

I see no email to golang-nuts. I am happy to send one. I may ask about OS X 10.8 at the same time.

@minux, is there an easy command to run on Linux systems to find out whether they'd be affected?

Thanks.

[bradfitz]

Ping @minux. Do you want this to happen for Go 1.8? If so, time is running out.

[minux]

I think we can revisit this in the next cycle because the tree is frozen so there won't be any change that would benefit from this. The test, at least on glibc linux/arm system, is this: LD_SHOW_AUXV=1 ls | grep AT_PLATFORM (the ls command can be replaced with any dynamic linked program) And if the output says: AT_PLATFORM: v6l or v7l, then the system won't be affected. If its v5l, then it will be affected.

[bradfitz]

I think deleting code & updating docs is okay for the freeze if you want to proceed for Go 1.8.

[minux]

The real benefit of removing armv5e support is intrinsicify 32-bit atomics. removing the support itself won't delete much code though. (we still need the softfloat implementation for mips.)

[minux]

I just verified that rpi1 supports the yield instruction in the ARM mode, therefore, if we raise the minimum arm architecture requirement to armv6k, then we can address #16663 as well.

[bradfitz]

Fixing #16663 is probably Go 1.9 material.

But I'd be happy with Go 1.8 breaking armv5 enough what we could remove the fake builders, add some docs to the Go 1.8 release notes, and simplify our lives going forward in Go 1.9.

[janflyborg]

So this means that Go 1.8 will receive security patches up until August 1 2018? That is still far away from the five years that @ThomasKurz needs to be able to support his customers and the company I work for has exactly the same problem.

[bradfitz]

That is still far away from the five years that @ThomasKurz needs to be able to support his customers and the company I work for has exactly the same problem.

Fortunately you have customers paying you money, so you can use that money to pay people to support Go 1.8 longer than we're supporting it for free. We just don't have the resources to support all old branches for years.

[rsc]

Tentatively tossing back into the proposal pile for further discussion. It would be nice to figure out the general policy for architectures; see also the thread on golang-dev about big-endian power5 ppc64.

[janflyborg]

Fortunately you have customers paying you money, so you can use that money to pay people to support Go 1.8 longer than we're supporting it for free. We just don't have the resources to support all old branches for years.

@bradfitz Has anyone talked about "supporting all old branches for years"? My remark was only about Go 1.8, which will be the last release that supports a very commonly used CPU (if this proposal is accepted).

The purpose of my posting was just to emphasize that if you are having an existing solution based on ARMv5, it is not an alternative to just freeze your code base at Go 1.8 (since it will not receive any security updates 1.5 year from now).

If it could only be arranged for Go 1.8 to receive crucial updates for a longer time period than normal, then I don't think anyone would have any problems with this proposal at all.

[bradfitz]

@janflyborg, we are going to support Go 1.8 for one year. We will support no branch for more than that. Certainly not five.

Like I said before, if you have revenue and are promising support to users, you need to budget in the cost of paying somebody to do security updates for all your dependencies which includes but is not limited to your OS and Go. Maybe a bunch of companies with similar needs can get together and collectively maintain a long-term stable branch of Go. Or maybe you just need to use a version of Go that comes with Ubuntu LTS and rely on Ubuntu or your OS of choice's maintenance team to do the security backports for you.

But the answer is not upstream (us) doing security maintenance for five years. We can definitely answer questions on the mailing list about backports with conflicts, to the extent we remember, but we're not in the business of maintaining old software.

[ThomasKurz]

I should apologize for having pushed this discussion into a somewhat off-topic direction yesterday by mentioning the option of "sticking with 1.8" (but with the restriction "not worth the risk").
Go's value is so much more than the compiler. Many of the awesome (standard) libs have grown and got new features with each version. Think of the "legacy-limited + current-full" hardware platform scenario I mentioned above, and imagine you couldn't use the same import "context" in your application, and no third-party libs relying on it, only because one of the platforms sticks with pre-1.7 ...
I do not want to keep 1.8 alive for years, as this would completely cut innovation for the non-legacy platforms (besides the fact that there is no direct profit from legacy platform support, which makes it hard to budget).

What's imho much more interesting is the question of an ARM "backend split", as this touches Go's no.1 rule of simplicity.
As I understood it, Go currently supports only one single ARM code generation target, with the option to select different modes of FPU support.
For me professionally developing code for ARM CPUs since >16 yrs and having seen their core capabilities grow and change so much over time, this seems to be overly simplistic.
I certainly admit that it's a necessary tradeoff if "ease of use" is your primary concern.
But you will regularly have to "cut the old pigtails" then, as development won't stop with ARMv8.
I think there are many markets where hardware half-life time is short enough for this approach, ours isn't.

I would thus strongly opt for a more flexible, perhaps feature-based code generation strategy without the need to decide between "target split" and "cut off" with each new, but incompatible architectural feature.

Would it be hard to make ARMv6k the default target, but keep code for ARMv5 around (in the compiler) for those who really need it, and at the same time become open for new optimizations on not-yet mainstream CPU variants?

P.S.: Since I first learned to know Go I am dreaming of using it for bare-metal/RTOS development on Cortex-M CPUs - how could that ever come true with the current "there is but one" paradigm?

[davecheney]

Would it be hard to make ARMv6k the default target, but keep code for

ARMv5 around (in the compiler) for those who really need it, and at the same time become open for new optimizations on not-yet mainstream CPU variants? This is sort of true and sort of not true. Ben Shi has submitted a number of CLs that add support in the arm backend for new ARMv6 and v7 instructions. However those instructions are only better ways to expressing the same operation, so if the chip doesn't support it, we don't generate the instructions. The problem with ARMv5 is there is no support for atomic operations like LDREX which significantly complicate papering over the lack of this instruction in the backend.

P.S.: Since I first learned to know Go I am *dreaming* of using it for

bare-metal/RTOS development on Cortex-M CPUs - how could that ever come true with the current "there is but one" paradigm? Thumb2 support is an entirely different kettle of fish, it would probably be a different backend target, perhaps linux/thumb2. Thats how it was done on plan9

…

On Tue, Feb 14, 2017 at 8:24 PM, Thomas Kurz ***@***.***> wrote: I should apologize for having pushed this discussion into a somewhat off-topic direction yesterday by mentioning the option of "sticking with 1.8" (but with the restriction "not worth the risk"). Go's value is so much more than the compiler. Many of the awesome (standard) libs have grown and got new features with each version. Think of the "legacy-limited + current-full" hardware platform scenario I mentioned above, and imagine you couldn't use the same *import "context"* in your application, and no third-party libs relying on it, only because one of the platforms sticks with pre-1.7 ... I do *not* want to keep 1.8 alive for years, as this would completely cut innovation for the non-legacy platforms (besides the fact that there is no direct profit from legacy platform support, which makes it hard to budget). What's imho much more interesting is the question of an ARM "backend split", as this touches Go's no.1 rule of simplicity. As I understood it, Go currently supports only *one single* ARM code generation target, with the option to select different modes of FPU support. For me professionally developing code for ARM CPUs since >16 yrs and having seen their core capabilities grow and change so much over time, this seems to be overly simplistic. I certainly admit that it's a necessary tradeoff if "ease of use" is your primary concern. But you will regularly have to "cut the old pigtails" then, as development won't stop with ARMv8. I think there are many markets where hardware half-life time is short enough for this approach, ours isn't. I would thus strongly opt for a more flexible, perhaps feature-based code generation strategy without the need to decide between "target split" and "cut off" with each new, but incompatible architectural feature. Would it be hard to make ARMv6k the default target, but keep code for ARMv5 around (in the compiler) for those who really need it, and at the same time become open for new optimizations on not-yet mainstream CPU variants? P.S.: Since I first learned to know Go I am *dreaming* of using it for bare-metal/RTOS development on Cortex-M CPUs - how could that ever come true with the current "there is but one" paradigm? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17082 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA5_MFNRJCir9xTgaSSorwgrFL4A8ks5rcXLIgaJpZM4J7K4x> .

[ThomasKurz]

Thanks a lot for clarification, @davecheney !
Can you point me to a document about Go's current backend architecture to help me get better understanding?

[davecheney]

I'm afraid it's "use the source, Luke"

…

On Tue, 14 Feb 2017, 21:33 Thomas Kurz ***@***.***> wrote: Thanks a lot for clarification, @davecheney <https://github.com/davecheney> ! Can you point me to a document about Go's current backend architecture to help me get better understanding? — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#17082 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAAcA37Uu30L7X1zGCmgPk2ARgJuTWjHks5rcYMLgaJpZM4J7K4x> .

[janflyborg]

@bradfitz OK I see. Thanks for the answer.

[4ad]

Thumb2 support is an entirely different kettle of fish, it would probably
be a different backend target, perhaps linux/thumb2. Thats how it was done
on plan9

Thumb support in Go would definitely be a new target, but Plan 9 never had a thumb port. There are thumb compilers for Inferno though.

[kortschak]

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

ARM926EJ-S (TI AM1808).

[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 ***@***.***> 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 <#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 <#17082 (comment)>, 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.