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

Comments

Projects
None yet
@minux
Copy link
Member

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 #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

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2016

@josharian

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

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

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

SGTM

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 13, 2016

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

@minux

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2016

@minux

This comment has been minimized.

Copy link
Member Author

commented Sep 13, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

commented Sep 13, 2016

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

This comment has been minimized.

Copy link

commented Sep 13, 2016

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

@davecheney

This comment has been minimized.

Copy link
Contributor

commented Sep 13, 2016

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

This comment has been minimized.

Copy link

commented Sep 14, 2016

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

This comment has been minimized.

Copy link
Member Author

commented Sep 14, 2016

@aclements

This comment has been minimized.

Copy link
Member

commented Sep 14, 2016

@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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link
Member

commented Nov 7, 2016

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

@minux

This comment has been minimized.

Copy link
Member Author

commented Nov 7, 2016

@bradfitz

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Member Author

commented Nov 7, 2016

@minux

This comment has been minimized.

Copy link
Member Author

commented Nov 7, 2016

@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

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link

commented Feb 13, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 13, 2017

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 rsc removed the Proposal-Accepted label Feb 13, 2017

@rsc

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Feb 14, 2017

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

This comment has been minimized.

Copy link
Member

commented Feb 14, 2017

@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

This comment has been minimized.

Copy link

commented Feb 14, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2017

@ThomasKurz

This comment has been minimized.

Copy link

commented Feb 14, 2017

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

This comment has been minimized.

Copy link
Contributor

commented Feb 14, 2017

@janflyborg

This comment has been minimized.

Copy link

commented Feb 14, 2017

@bradfitz OK I see. Thanks for the answer.

@4ad

This comment has been minimized.

Copy link
Member

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

This comment has been minimized.

Copy link
Contributor

commented Feb 16, 2017

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

ARM926EJ-S (TI AM1808).

@aajtodd

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2017

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

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

commented Mar 7, 2017

@aajtodd

This comment has been minimized.

Copy link

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

This comment has been minimized.

Copy link
Contributor

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

This comment has been minimized.

Copy link

commented Mar 22, 2017

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

gopherbot pushed a commit to golang/build that referenced this issue Mar 22, 2017

cmd/buildlet, dashboard: add linux-arm-arm5 buildlet
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

This comment has been minimized.

Copy link
Contributor

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 Mar 27, 2017

@bamarni bamarni referenced this issue Apr 10, 2017

Open

ARM release #211

@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.
You can’t perform that action at this time.