i think this approach unnecessarily limit the scope of our binaries. this
will make it
difficult for our developers to distribute pre-built binaries (either he
must provide ARMv5
version and sacrifice floating point performance or he provide at least
ARMv5 and ARMv6
versions, but user with VFP-less ARMv6 will have to use the ARMv5 version,
which is
counter-intuitive at least);
we've spend quite some effort in the runtime to auto detect architecture
and use
the best available instructions for synchronization. I think we can do
better for this case.
our Go binary really only need two flavors, one with software floating
point (undoubtedly could
be run on all supported machines), and one with VFPv1 hardware floating
point.
to sum up, i'd rather disable VFPv3-only vmov (imm) instruction entirely
than this approach.
ps:
$GOARM is somewhat misnamed, i think GOVFP would be much better.
if we can introduce GOVFP (or something similar), we can use this approach
for it, because
it is less confusing to the users (our GOARM isn't really related to ARM
Architecture).
In the spirit of supporting the Pi by Go 1.1, I would support removing vmov imm at this point and revisiting it later. I have a benchmark that shows in the micro there is a significant cost on arm7 without vmov imm for the math package, but it is hard to find a serious impact in the macro go1 benchmarks.
On 01/09/2012, at 18:08, minux <minux...@gmail.com> wrote:
> i think this approach unnecessarily limit the scope of our binaries. this will make it
> difficult for our developers to distribute pre-built binaries (either he must provide ARMv5
> version and sacrifice floating point performance or he provide at least ARMv5 and ARMv6
> versions, but user with VFP-less ARMv6 will have to use the ARMv5 version, which is
> counter-intuitive at least);
> we've spend quite some effort in the runtime to auto detect architecture and use
> the best available instructions for synchronization. I think we can do better for this case.
> our Go binary really only need two flavors, one with software floating point (undoubtedly could
> be run on all supported machines), and one with VFPv1 hardware floating point.
> to sum up, i'd rather disable VFPv3-only vmov (imm) instruction entirely than this approach.
> ps:
> $GOARM is somewhat misnamed, i think GOVFP would be much better.
> if we can introduce GOVFP (or something similar), we can use this approach for it, because
> it is less confusing to the users (our GOARM isn't really related to ARM Architecture).
On Sat, Sep 1, 2012 at 4:38 PM, Dave Cheney <d...@cheney.net> wrote:
> In the spirit of supporting the Pi by Go 1.1, I would support removing
> vmov imm at this point and revisiting it later. I have a benchmark that
> shows in the micro there is a significant cost on arm7 without vmov imm
> for the math package, but it is hard to find a serious impact in the macro
> go1 benchmarks.
vmov imm doesn't do much (it can only load a specific class of constant
floating
point numbers), i think maybe we can rewrite some code in the math package
to
solve the performance issue.
> On Sat, Sep 1, 2012 at 4:38 PM, Dave Cheney <d...@cheney.net> wrote:
> In the spirit of supporting the Pi by Go 1.1, I would support removing vmov imm at this point and revisiting it later. I have a benchmark that shows in the micro there is a significant cost on arm7 without vmov imm for the math package, but it is hard to find a serious impact in the macro go1 benchmarks. > vmov imm doesn't do much (it can only load a specific class of constant floating
> point numbers), i think maybe we can rewrite some code in the math package to
> solve the performance issue.
I would still like to see a runtime check that can print:
runtime: cannot run GOARM=%d binary on this system; need GOARM=%d
because it is a common source of problems for people. Don't make any
reference to the "ARM version", just to the GOARM setting. That
definition is purely under our control.
rsc: I have updated the error message in runtime.c, PTAL
all: I think we can do both, print an error message on GOARM mismatch,
and also stop using vmov imm (which restricts the range of GOARM
values to 5 and 6) for the moment.
On Sun, Sep 2, 2012 at 12:00 AM, Russ Cox <r...@golang.org> wrote:
> I would still like to see a runtime check that can print:
> runtime: cannot run GOARM=%d binary on this system; need GOARM=%d
> because it is a common source of problems for people. Don't make any
> reference to the "ARM version", just to the GOARM setting. That
> definition is purely under our control.
i need to do some experiments regarding hard floating point
and kernel software floating point emulation.
maybe we can make both GOARM=5 and GOARM=6 runnable
on most systems.
(GOARM=5 obviously can be run on VFP systems, only slower.
i think GOARM=6 might be able to run VFP-less systems, provided
kernel softfp is enabled [it should be enabled by default on
most systems])
if it's the case, our job is more difficult, but the life will be much
easier for user:
we need to detect whether the kernel can actually run this binary
correctly (maybe slow), and if it's, let it run. if it's not, give error
and exit.
On Mon, Sep 3, 2012 at 3:19 AM, <minux...@gmail.com> wrote:
> i need to do some experiments regarding hard floating point
> and kernel software floating point emulation.
unfortunately, the nwfpe software floating point facility in kernel is
only capable of emulating fpa (not vfp) instructions, so universal
arm binary is still not possible.
