who uses ARM v5?

[Russ Cox]

do you use (or want to use) Go on ARM v5 devices
(i.e. devices where you'd have to export GOARM=5 to
get working binaries)?

which devices?

ARM v5 had only very primitive atomic operations,
which makes it difficult to support efficient synchronization.
we are trying to understand whether we should bother to
support ARM v5 or just assume ARM v>=6.

thanks.
russ

[David Brown]

Are you aware that the Linux kernel puts a compare-and-set and a barrier
routine at a known location that is appropriate for the current
architecture? It would need a wrapper, since the calling convention is
different. I was going to look into doing it at some point, since
up-coming SMP ARM devices are going to need some additional memory
barriers to be able to do proper synchronization.

David

[Ben Leslie]

I definitely use ARM v5 devices (mostly mobile phone devices). It would be nice to be able to run Go on these, but to be honest, it probably isn't worth the engineering costs.

My 2c,

Benno

[Jason J. Gullickson]

I'd love to be able to use Go on Arm...

Sent from my jPhone

[Andrea Fazzi]

Excerpts from Russ Cox's message of ven feb 25 08:05:11 +0100 2011:

I'm using ARMv7 (Cortex-A8) devices (Nokia N900, Beagleboard rev. C4, Open
Pandora). I'd like to see cgo support for this arch ... :)

Thanks,
Andrea

--
Andrea Fazzi @ alcacoop.it
Read my blog at http://freecella.blogspot.com
Follow me on http://twitter.com/remogatto

[Joseph Stewart]

Russ,

I have many fielded devices that are "armv5tejl" that I'd love to keep
the ability to run Go, although our next gen boxes are "armv6l".

-joe

[Corey Thomasson]

I'm using Go on ARM v7 only as well

[Russ Cox]

> Are you aware that the Linux kernel puts a compare-and-set and a barrier
> routine at a known location that is appropriate for the current
> architecture?  It would need a wrapper, since the calling convention is
> different.  I was going to look into doing it at some point, since
> up-coming SMP ARM devices are going to need some additional memory
> barriers to be able to do proper synchronization.

Yeah, vaguely. But it wouldn't help on non-Linux systems.

What does this compare-and-set look like on ARM v5 though?
My understanding is that v5 only had an atomic swap, which
is not enough to implement compare-and-set. If there's some
more powerful instruction I am unaware of on v5, that would
solve the problem nicely. :-)

For our own purposes we can (and do) use swap to implement a tiny
spin lock and then simulate compare-and-set inside the spin lock, but
that isn't a viable strategy if you're coordinating with outside code
that doesn't know about it.

Russ

[Francisco Diaz Trepat - gmail]

I have the Nokia N900 I currently use the 5g 5l compiler linker to do my gocoding.

I understand that it has a 600 MHz ARM Cortex-A8 CPU, that this means I have a v>5?

If it doesn't mean that, and I could only use the 5g 5l tools please please please don't drop it yet.

Since Microsoft Nokia controversial announcement and fight with Adobe we at the group of people who want to

have a linux device have been getting our face kick by bad news.

Go coding is about the nicest thing left for my n900.

f(t)

[Francisco Diaz Trepat - gmail]

For what Andrea said (sorry I missed it) I have an ARM v7 on the Nokia N900

Where does it say the v of the ARM and what it stands for?

Go rocks,

f(t)

[David Brown]

On Fri, Feb 25 2011, Russ Cox wrote:

>> Are you aware that the Linux kernel puts a compare-and-set and a barrier
>> routine at a known location that is appropriate for the current
>> architecture?  It would need a wrapper, since the calling convention is
>> different.  I was going to look into doing it at some point, since
>> up-coming SMP ARM devices are going to need some additional memory
>> barriers to be able to do proper synchronization.
>
> Yeah, vaguely. But it wouldn't help on non-Linux systems.
>
> What does this compare-and-set look like on ARM v5 though?
> My understanding is that v5 only had an atomic swap, which
> is not enough to implement compare-and-set. If there's some
> more powerful instruction I am unaware of on v5, that would
> solve the problem nicely. :-)

They implement it as a regular load and store, and the scheduler checks
if the PC is in between and backs it up on return back to the code.
It's actually the only way to do a compare and exchange on ARM v5.

Also, the compare-and-exchange does the proper memory barrier.

There's actually three routines, a memory barrier, the
compare-and-exchange, and a call to get the tls.

The comments state that userspace is free to do these operations itself,
but doesn't recommend it if that is the only reason for the code to be
specific to that CPU.

I suspect that other platforms on ARM have some way of handling the
compare and exchange on ARMv5, if they support it.

David

[Skip Tavakkolian]

I use SheevaPlugs and GuruPlugs (Server and Display). I would echo the
sentiment that if it takes away from other important work it is
probably not worth the effort; but it sure would be nice to be able to
use Go on those.

Thanks,
-Skip

[Russ Cox]

Thanks for the feedback. I think we can try this
"consider compare-and-swap as OS-provided functionality"
mindset and see how well that works. It should have
the benefit that you won't have to set $GOARM to get
the right synchronization primitives.

Russ

[pascal bertrand]

http://www.arm.com/products/processors/cortex-a/cortex-a8.php?tab=Specifications+On Fri, Feb 25, 2011 at 4:46 PM, Francisco Diaz Trepat - gmail <francisco....@gmail.com> wrote:

For what Andrea said (sorry I missed it) I have an ARM v7 on the Nokia N900

Where does it say the v of the ARM and what it stands for?

The ARM architecture tends to be energy efficient. It has different parts that 

manufacturer can compose together and add on. This way, they put only 

what's necessary for intended usage (and save transistors and energy) 

Each version adds something to the core architecture. I am no specialist, but 

for instance ARMv5 seems to have no built-in support for concurrency. Of 

course, new instructions are added as a result.

You need to get information on your specific processor for the architecture 

version and additional goodies (man google)

Let's take the Beagleboard for instance. It has a TI OMAP3530 processor,

which core is a Cortex-A8. From the ARM specifications you can see it is an 

ARMv7. It support NEON SIMD instructions, Thumb-2 instructions, etc. out of 

the box. You also get graphic facilities compatible with TI's DaVinci technology.

I encourage you to look at your n900's processor to try it yourself.

Pascal BERTRAND

[ron minnich]

That's what makes the ARM so enjoyable. Any given implementation has a
set of numbers to apply to it. It's hard to figure out which is which,
and then we get started on THUMBs and other digits.

I've been trying to figure out if any of the ARMs I use nowadays are
v5. I'm almost certain none of my current ARMs -- marvell, TI, etc. --
are v5. I believe, for example, that sheeva and guru plugs are much >
v5, since they are the same as the openrd I have.

One source of confusion I note in this thread is the distinction
between 5{g,l} and the ARM version 5. Unless I misread I've seen at
least one message indicating such confusion ... i.e. people identify
ARM v5 with the 5g compiler.

So, my recommendation FWIW is not to worry about v5 but instead make
the modern arms work wonderfully well -- and, of course, get
cross-compilation back in the picture :-)

thanks

ron

[Russ Cox]

Recent changes (after the last release) have changed
the synchronization routines on the ARM to be OS-specific,
following David Brown's suggestion. The result is that you
shouldn't need to care about ARM version nearly as much,
and it is now trivial to keep supporting the various older
ARM chipsets.

The only effect of the $GOARM variable now is that
if you set it to a value < 6, 5l will assume the -F flag
and arrange to use the software floating point routines.
So if your ARM has hardware floating point, do nothing.
If it needs software floating point, export GOARM=5 or
invoke 5l with the -F flag.

Russ

[Skip Tavakkolian]

According to this, Marvell Kirkwood 88F8261 is ARMv5 compliant:

http://www.marvell.com/products/processors/embedded/kirkwood/HW_88F6281_OpenSource.pdf