code review 6442109: runtime: arm: abort if hardware floating point missing

runtime: arm: abort if hardware floating point missing

Fixes issue 3911.

Requires CL 6449127.

dfc@qnap:~$ ./runtime.test
runtime: this CPU has no floating point hardware, so it cannot run
this GOARM=7 binary. Recompile using GOARM=5.

[dave_cheney.net, 2012-08-10 12:25:28]

Hello rsc@golang.org, minux.ma@gmail.com (cc: golang-dev@googlegroups.com),

I'd like you to review this change to
https://code.google.com/p/go

[rsc, 2012-08-30 14:46:44]

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c
File src/pkg/runtime/runtime.c (right):

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#new...
src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
Where is armArch being set?

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#new...
src/pkg/runtime/runtime.c:215: runtime·printf("This binary requires ARMv%d, this
host is ARMv%d.\n",
"runtime: cannot run ARMv%d binary on ARMv%d system\n",

[minux1, 2012-08-30 15:12:55]

On 2012/08/30 14:46:44, rsc wrote:
http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#new...
> src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
> Where is armArch being set?
http://tip.golang.org/src/pkg/runtime/signal_linux_arm.c#L178

Russ, could you please take a look at the corresponding golang-dev
discussion?

[dave_cheney.net, 2012-08-31 01:40:05]

Thank you for your comments, PTAL.

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c
File src/pkg/runtime/runtime.c (right):

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#new...
src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
On 2012/08/30 14:46:44, rsc wrote:
> Where is armArch being set?

signal_linux_arm.c +178

I might be able to move them closer together if you would like.

http://codereview.appspot.com/6442109/diff/9001/src/pkg/runtime/runtime.c#new...
src/pkg/runtime/runtime.c:215: runtime·printf("This binary requires ARMv%d, this
host is ARMv%d.\n",
On 2012/08/30 14:46:44, rsc wrote:
> "runtime: cannot run ARMv%d binary on ARMv%d system\n",

Done.

[minux1, 2012-09-01 08:08:35]

sorry, but i tend to oppose this approach now.

as elaborated here:
https://groups.google.com/d/topic/golang-dev/WqJuNnZr8pw/discussion

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).

[dave_cheney.net, 2012-09-01 08:38:14]

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.ma@gmail.com> wrote:

> sorry, but i tend to oppose this approach now.
> 
> as elaborated here:
https://groups.google.com/d/topic/golang-dev/WqJuNnZr8pw/discussion
> 
> 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).

[minux1, 2012-09-01 08:57:40]

On Sat, Sep 1, 2012 at 4:38 PM, Dave Cheney <dave@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.

[dave_cheney.net, 2012-09-01 09:12:58]

SGTM. 

On 01/09/2012, at 18:57, minux <minux.ma@gmail.com> wrote:

> 
> On Sat, Sep 1, 2012 at 4:38 PM, Dave Cheney <dave@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.

[rsc, 2012-09-01 14:00:59]

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.

Russ

[dave_cheney.net, 2012-09-01 14:05:05]

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 <rsc@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.
>
> Russ

[minux1, 2012-09-02 19:19:24]

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.

http://codereview.appspot.com/6442109/diff/16007/src/pkg/runtime/runtime.c
File src/pkg/runtime/runtime.c (right):

http://codereview.appspot.com/6442109/diff/16007/src/pkg/runtime/runtime.c#ne...
src/pkg/runtime/runtime.c:214: if(runtime·armArch < runtime·goarm) {
if we only differentiate GOARM=5 (soft float) and GOARM>5 (VFP),
i think you'd better use runtime.hwcap & HWCAP_VFP instead.

FYI, HWCAP_VFP is defined in /usr/include/asm/hwcap.h.

[minux1, 2012-09-03 16:52:24]

On Mon, Sep 3, 2012 at 3:19 AM, <minux.ma@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.

[dave_cheney.net, 2012-09-04 20:43:30]

Hello rsc@golang.org, minux.ma@gmail.com (cc: golang-dev@googlegroups.com),

Please take another look.

[dave_cheney.net, 2012-09-04 20:45:00]

PTAL. I have updated the test logic to only consider hardware floating point and
added a suggested fix. Thanks to minux for the suggestions.

[dave_cheney.net, 2012-09-04 23:37:04]

I just managed hit this myself while testing this CL.

pkg/go/scanner
pkg/go/ast
pkg/go/parser
pkg/os/exec
pkg/net/url
pkg/text/template/parse
pkg/text/template
pkg/go/doc
pkg/go/build
cmd/go
runtime: this binary requires hardware floating point support. Recompile with
GOARM=5.

Clearly I did not follow my own advice.

[minux1, 2012-09-05 12:02:09]

LGTM.

with this kind of test in place, we can go on to introduce
GOARM=7 for VFPv3 systems (and make GOARM=6 the default).

[dave_cheney.net, 2012-09-07 02:09:23]

ping. Would anyone else like to review this proposal ?

[rsc, 2012-09-07 02:28:26]

LGTM

http://codereview.appspot.com/6442109/diff/19006/src/pkg/runtime/signal_linux...
File src/pkg/runtime/signal_linux_arm.c (right):

http://codereview.appspot.com/6442109/diff/19006/src/pkg/runtime/signal_linux...
src/pkg/runtime/signal_linux_arm.c:160: runtime·printf("runtime: this binary
requires hardware floating point support. Recompile with GOARM=5.\n");
I'd like this not to wrap. It would also be nice to say what the binary is, if
only for debugging. How about this (two lines):

runtime: this CPU has no floating point hardware, so it cannot run
this GOARM=%d binary. Recompile using GOARM=%d.

[dave_cheney.net, 2012-09-07 02:35:41]

Thank you. I'll make that change before submitting.

On Fri, Sep 7, 2012 at 12:28 PM,  <rsc@golang.org> wrote:
> LGTM
>
>
>
http://codereview.appspot.com/6442109/diff/19006/src/pkg/runtime/signal_linux...
> File src/pkg/runtime/signal_linux_arm.c (right):
>
>
http://codereview.appspot.com/6442109/diff/19006/src/pkg/runtime/signal_linux...
> src/pkg/runtime/signal_linux_arm.c:160: runtime·printf("runtime: this
> binary requires hardware floating point support. Recompile with
> GOARM=5.\n");
> I'd like this not to wrap. It would also be nice to say what the binary
> is, if only for debugging. How about this (two lines):
>
> runtime: this CPU has no floating point hardware, so it cannot run
> this GOARM=%d binary. Recompile using GOARM=%d.
>
> http://codereview.appspot.com/6442109/

[dave_cheney.net, 2012-09-07 04:26:55]

*** Submitted as http://code.google.com/p/go/source/detail?r=e4b20018f797 ***

runtime: arm: abort if hardware floating point missing

Fixes issue 3911.

Requires CL 6449127.

dfc@qnap:~$ ./runtime.test
runtime: this CPU has no floating point hardware, so it cannot run
this GOARM=7 binary. Recompile using GOARM=5.

R=rsc, minux.ma
CC=golang-dev
http://codereview.appspot.com/6442109