Hi gophers,
Due to the liblink changes, the ARM compiler in Go 1.3 will use the GOARM variable at the compiler stage instead only at the linker stage.
Can we introduce arm5, arm6 and arm7 (or, more technically correctly, armv5, armv6 and armv7) build tags so that we can have separate implementations for each variant?
I want to optimize the atomic ops. used in the runtime, but I don't like the performance penalty of runtime dispatch.
Also, we can have NEON (only in armv7) optimized math, math/big and crypto, which will speed up things a lot.
What do you think? The only drawback I can think of is collision with existing user defined build tags, but I didn't know any people do that yet. Examples welcome.
Sincerely,
minux
On Feb 14, 2014 3:19 AM, "Nick Craig-Wood" <ni...@craig-wood.com> wrote:
>
> On 14/02/14 05:16, minux wrote:
> > Due to the liblink changes, the ARM compiler in Go 1.3 will use the
> > GOARM variable at the compiler stage instead only at the linker stage.
> >
> > Can we introduce arm5, arm6 and arm7 (or, more technically correctly,
> > armv5, armv6 and armv7) build tags so that we can have separate
> > implementations for each variant?
> >
> > I want to optimize the atomic ops. used in the runtime, but I don't like
> > the performance penalty of runtime dispatch.
> >
> > Also, we can have NEON (only in armv7) optimized math, math/big and
> > crypto, which will speed up things a lot.
> >
> > What do you think? The only drawback I can think of is collision with
> > existing user defined build tags, but I didn't know any people do that
> > yet. Examples welcome.
>
> There are certainly some ARM features it would be very useful to know
> about a compile time.
>
> In particular when writing assembler for the crypto functions I would
> have like to know whether an unaligned load was allowed or not - this
> would have speeded up the code significantly on newer architectures.
> This depends more on the OS though than the arm version.
>
> The NEON instructions are definitely available in armv7, might be
> available in armv6 and definitely not in armv5. so those categories are
> a little broad in ARM terms.
yes, our GOARM is perhaps misnamed, basically it has the following meaning:
5 ARM(v5) without VFP
6 ARM(v6) with VFPv1 or 2
7 ARM(v7) with VFPv3 (and NEON).
i've suggested in the past to decouple the architecture version with VFP version, but that deemed unnecessary and complex.
so if your ARMv5 has VFP, Go can't use it. (perhaps you can set GOARM=6, but the compiler might as well use ARMv6 specific instructions, such as LDREX)
> Perhaps we should define exactly what we mean by each of those tags in
> terms of ARM features Go code can use
>
> armv7
> NEON
> FPv4-SP
that will be overly complex, IMO.
in my proposal, the build tag has directly relationship to the already known GOARM variable.
> armv6
Before (and currently), we don't generate architecture specific instructions (except FP) in the compiler, but i expect it will be changed soon.
for example, Dmitry proposed that we have atomic op. intrinsic in cc, and in that case, using LDREX if allowed by GOARM seems the correct way to go as SWP is not recommended in newer architectures.
On Feb 14, 2014 4:11 AM, "Nick Craig-Wood" <ni...@craig-wood.com> wrote:
> Did you have any thoughts on unaligned loads? That is a feature it would
> be really nice to rely on.
i also think it's a OS-dependent feature so Go can't do anything about it.
for example on linux you can select how the Kernel deals with (un)aligned access, by writing to /proc/cpu/alignment.
Hi gophers,
Due to the liblink changes, the ARM compiler in Go 1.3 will use the GOARM variable at the compiler stage instead only at the linker stage.
Can we introduce arm5, arm6 and arm7 (or, more technically correctly, armv5, armv6 and armv7) build tags so that we can have separate implementations for each variant?
I want to optimize the atomic ops. used in the runtime, but I don't like the performance penalty of runtime dispatch.
Also, we can have NEON (only in armv7) optimized math, math/big and crypto, which will speed up things a lot.
What do you think? The only drawback I can think of is collision with existing user defined build tags, but I didn't know any people do that yet. Examples welcome.
Sincerely,
minux
--
---
You received this message because you are subscribed to the Google Groups "golang-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to golang-dev+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
On Feb 24, 2014 10:52 AM, "Russ Cox" <r...@golang.org> wrote:
>
> Let's discuss this again when we start talking about 1.4. It's too late to do this for Go 1.3.
>
> The analogy with GO386 is what bothers me the most. There are tons of varieties of x86 if we start enumerating all the different feature sets, and I am not sure we want to have such conditional builds.
The situation is different for ARM here.
on x86, you can do cpuid checks easily,
but ARM generally doesn't have such facility, and runtime code dispatch will also be slower on ARM than on x86.
--
On Feb 25, 2014 12:57 PM, "Keith Randall" <k...@google.com> wrote:
> On x86 we call CPUID once on startup and store the result in a global variable. We could/should do the same thing on arm. Then dispatch is just a load & test.
the problem is such facility is OS dependent as ARM architecture version registers are not readable in user space, and earlier ARMs even don't have one.
On linux, we have auxv. But what about *BSDs?
For x86, even if we don't export cpuid, packages could do that themselves, however, for the linuc/arm case, we must export the auxv from runtime (or the program must read from /proc/self/auxv, and that's still not portable to other OSes)
Can you just try different instructions and check expected output, catching faults as needed to prevent crashing?
(Clueless)
--
Can you just try different instructions and check expected output, catching faults as needed to prevent crashing?
On Feb 25, 2014 6:38 PM, "Brad Fitzpatrick" <brad...@golang.org> wrote:
> Can you just try different instructions and check expected output, catching faults as needed to prevent crashing?
but isn't SIGILL will crash the whole program? I haven't thought about extending SetPanicOnFault, probably that's the answer.
For builder coverage we can have some environment variables or build options that only package runtime needs to know about (and the people running the builders) that forces feature bits off for some builders. (Advantage of environment variable is we can do the build once on a good ARM builder and re-run the tests with different environment variables to select different ARM code paths...)
I really don't want to see a dozen build tags in addition to GOARM which is already kinda gross.
Once they're in go/build.Context.FooTags, we're stuck with them forever. People use anything you make available."working with the pattern we have today" is an answer, but it might not be the best answer. We have the ability to change things.
On 2/26/14, Dave Cheney <da...@cheney.net> wrote:It's a fallacy that reserving a keyword or prefix or anything else
>
> Oh no argument there. One suggestion, probably crap, would be to add a
> second set of build style tags, ones that are explicitly not available for
> people to redefine.
>
> // +arch armv7, neon
>
> ^
> strawman
>
> Basically // +arch is a reserved namespace, we reserve the right to change
> it at will.
>
actually works. You need an official registry to ensure consistent
use across the public body of use. Think RFC-822's X- prefix. And
you're still stuck with historical usage.
It seems to me, unschooled as I am, that this particular issue is a
point in favour of run-time linkage, or dynamic link objects. I
really fear the day when I need to install different applications on
my (old) Xperia and my Galaxy phones. If the runtime could ensure
that the same application can run correctly and optimally in either
context, I would trade efficiency for that.
I see how others may prefer the opposite and I submit that the choice
should be with the user, while the developer needs all the help she
can get to deliver the best.
After all, what happens to Go's touted portable development if we make
compilation dependent on the platform context?
Lucio.