Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

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

Closed
minux opened this issue Sep 13, 2016 · 108 comments
Closed

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

minux opened this issue Sep 13, 2016 · 108 comments

Comments

@minux
Copy link
Member

minux commented Sep 13, 2016

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 minux added the Proposal label Sep 13, 2016
@minux minux added this to the Go1.8 milestone Sep 13, 2016
@minux
Copy link
Member Author

minux commented Sep 13, 2016

/cc @cherrymui @davecheney @josharian

@josharian
Copy link
Contributor

@hasty

@davecheney
Copy link
Contributor

I'm fine with this.

On Tue, Sep 13, 2016 at 10:31 AM, Josh Bleecher Snyder <
notifications@github.com> 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
Copy link
Contributor

SGTM

@bradfitz
Copy link
Contributor

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

@minux
Copy link
Member Author

minux commented Sep 13, 2016 via email

@minux
Copy link
Member Author

minux commented Sep 13, 2016 via email

@bradfitz
Copy link
Contributor

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
Copy link

hasty commented Sep 13, 2016

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

@davecheney
Copy link
Contributor

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 notifications@github.com 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
Copy link

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
Copy link
Member Author

minux commented Sep 14, 2016 via email

@aclements
Copy link
Member

@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
Copy link
Contributor

adg commented Sep 26, 2016

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
Copy link
Contributor

rsc commented Oct 18, 2016

Minux, did you email golang-nuts?

@rsc rsc modified the milestones: Proposal, Go1.8 Oct 18, 2016
@rsc rsc changed the title Proposal: runtime: drop support for linux/armv5E? proposal: runtime: drop support for linux/armv5E? Oct 18, 2016
@rsc
Copy link
Contributor

rsc commented Oct 18, 2016

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
Copy link
Contributor

bradfitz commented Nov 7, 2016

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

@bradfitz bradfitz added the WaitingForInfo Issue is not actionable because of missing required information, which needs to be provided. label Nov 7, 2016
@minux
Copy link
Member Author

minux commented Nov 7, 2016 via email

@bradfitz
Copy link
Contributor

bradfitz commented Nov 7, 2016

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

@minux
Copy link
Member Author

minux commented Nov 7, 2016 via email

@minux
Copy link
Member Author

minux commented Nov 7, 2016 via email

@minux minux changed the title proposal: runtime: drop support for linux/armv5E? proposal: runtime: drop support for linux/armv5E and linux/armv6? Nov 7, 2016
@bradfitz
Copy link
Contributor

bradfitz commented Nov 8, 2016

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
Copy link

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
Copy link
Contributor

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 rsc changed the title runtime: drop support for linux/armv5E and linux/armv6 proposal: runtime: drop support for linux/armv5E and linux/armv6 Feb 13, 2017
@rsc
Copy link
Contributor

rsc commented Feb 13, 2017

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
Copy link

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
Copy link
Contributor

@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
Copy link

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
Copy link
Contributor

davecheney commented Feb 14, 2017 via email

@ThomasKurz
Copy link

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
Copy link
Contributor

davecheney commented Feb 14, 2017 via email

@janflyborg
Copy link

@bradfitz OK I see. Thanks for the answer.

@4ad
Copy link
Member

4ad commented Feb 15, 2017

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
Copy link
Contributor

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

ARM926EJ-S (TI AM1808).

@aajtodd
Copy link

aajtodd commented Mar 7, 2017

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).

  1. Would this affect gccgo as well?

@davecheney
Copy link
Contributor

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
Copy link

aajtodd commented Mar 7, 2017

@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
Copy link
Contributor

davecheney commented Mar 7, 2017 via email

@aajtodd
Copy link

aajtodd commented Mar 7, 2017

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
Copy link
Contributor

rsc commented Mar 8, 2017

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
Copy link

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

gopherbot pushed a commit to golang/build that referenced this issue Mar 22, 2017
Updates golang/go#17082
Updates golang/go#19662

Change-Id: I2b8294f9a8d9144033f8a3479a64186b0f5143a2
Reviewed-on: https://go-review.googlesource.com/38453
Reviewed-by: Brad Fitzpatrick <bradfitz@golang.org>
@rsc
Copy link
Contributor

rsc commented Mar 27, 2017

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.

@rsc rsc closed this as completed Mar 27, 2017
@golang golang locked and limited conversation to collaborators Mar 27, 2018
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

No branches or pull requests