Skip to content

sync/atomic: 64-bit primitives are not supported on ARMv5 #6134

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.

Sign up for GitHub

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

Jump to bottom
Open
lexprfuncall opened this issue Aug 13, 2013 · 9 comments
Open

sync/atomic: 64-bit primitives are not supported on ARMv5 #6134

lexprfuncall opened this issue Aug 13, 2013 · 9 comments
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Milestone
Unplanned

Comments

@lexprfuncall
Copy link 

The following change introduced the armSwapUint64

https://code.google.com/p/go/source/detail?r=41d393af9bb8

This function, written in assembly, uses newer ARM instructions to perform a double
width LL/SC.  I believe this code is correct.

For older ARM processors, which are supported by Go, these instructions do not exist. 
On Linux, there is a primitive provided by the kernel that cooperates with the scheduler
to provide a the same primitive. However, non-Linux targets do not have similar
functionality.

Since non-Linux ARM targets are not generally well supported, a viable option might be
to discontinue support for ARMv5 CPUs on those systems and require a CPU that supports
at least the ARMv6K instructions.
@rsc
Copy link
Contributor

rsc commented Aug 13, 2013

Comment 1:

armSwapUint64 appears to be dead code: nothing calls it. But what you wrote is true of
armCompareAndSwapUint64, which is where non-Linux ARM systems end up. 
The only supported non-Linux ARM system is FreeBSD 10. Does FreeBSD 10 run on ARMv5?
Maybe the issue is moot.

Labels changed: added priority-later, removed priority-triage.

@lexprfuncall
Copy link
Author

Comment 2:

FreeBSD claims support for ARMv5 and even ARMv4.  We already cannot support ARMv4.

@rsc
Copy link
Contributor

rsc commented Aug 13, 2013

Comment 3:

What we've done for the 386 port is provide atomics that only work on newer chips and
then avoid using them in the standard library. That's probably fine here for ARM too. I
will update the docs in sync/atomic (CL 12880043) and leave this open for the question
of whether to disallow ARMv5 on non-Linux systems.

@rsc
Copy link
Contributor

rsc commented Aug 13, 2013

Comment 4:

This issue was updated by revision 2642c6e.

R=golang-dev, bradfitz
CC=golang-dev
https://golang.org/cl/12880043

@robpike
Copy link
Contributor

robpike commented Aug 20, 2013

Comment 5:

Labels changed: added go1.2, removed go1.2maybe.

@rsc
Copy link
Contributor

rsc commented Sep 9, 2013

Comment 6:

We can decide about FreeBSD ARMv4 for Go 1.3. For now I am not worried.

Labels changed: added go1.3maybe, removed go1.2.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 7:

Labels changed: added release-none, removed go1.3maybe.

@rsc
Copy link
Contributor

rsc commented Dec 4, 2013

Comment 8:

Labels changed: added repo-main.

@minux
Copy link
Member

minux commented Apr 19, 2014

Comment 9:

i think it's possible to add 64-bit atomic op support for freebsd/armv5 using their
restartable atomic sequence with ldrd/strd.

@rsc rsc added this to the Unplanned milestone Apr 10, 2015
@seankhliao seankhliao added the NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one. label Jul 13, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
NeedsInvestigation Someone must examine and confirm this is a valid issue and not a duplicate of an existing one.
Projects
None yet
Milestone
Unplanned
Development

No branches or pull requests
5 participants
@rsc @minux @robpike @lexprfuncall @seankhliao