Android with Hardware Float

2,206 views
Skip to first unread message

Vik

unread,
Apr 27, 2012, 6:24:47 PM4/27/12
to Android Building
Hi,

Has anyone built Android from source with hardware floating point
support enabled?
If so then what about the kernel. I know that it is built with the
-msoft-float gcc flag and thats how it is supposed to be. So I am a
little confused about how this would work.

Any help from experts will be appreciated.

Thanks,
V

Jean-Baptiste Queru

unread,
Apr 27, 2012, 6:29:00 PM4/27/12
to android-...@googlegroups.com
See e.g. device/samsung/tuna:

TARGET_CPU_ABI := armeabi-v7a
TARGET_CPU_ABI2 := armeabi
TARGET_ARCH_VARIANT := armv7-a-neon

JBQ
> --
> You received this message because you are subscribed to the "Android Building" mailing list.
> To post to this group, send email to android-...@googlegroups.com
> To unsubscribe from this group, send email to
> android-buildi...@googlegroups.com
> For more options, visit this group at
> http://groups.google.com/group/android-building?hl=en



--
Jean-Baptiste M. "JBQ" Queru
Software Engineer, Android Open-Source Project, Google.

Questions sent directly to me that have no reason for being private
will likely get ignored or forwarded to a public forum with no further
warning.

Jean-Baptiste Queru

unread,
Apr 27, 2012, 6:29:18 PM4/27/12
to android-...@googlegroups.com
I meant, device/samsung/tuna/BoardConfig.mk

JBQ

Vik

unread,
Apr 28, 2012, 2:20:43 PM4/28/12
to Android Building
Thanks JBQ. But will it work with the emulator?
Also, isn't NEON the SIMD extension and vfp3 the floating point
extension for v7?

Thanks,
V

On Apr 27, 3:29 pm, Jean-Baptiste Queru <j...@android.com> wrote:
> I meant, device/samsung/tuna/BoardConfig.mk
>
> JBQ
>
>
>
>
>
>
>
>
>
> On Fri, Apr 27, 2012 at 3:29 PM, Jean-Baptiste Queru <j...@android.com> wrote:
> > See e.g. device/samsung/tuna:
>
> > TARGET_CPU_ABI := armeabi-v7a
> > TARGET_CPU_ABI2 := armeabi
> > TARGET_ARCH_VARIANT := armv7-a-neon
>
> > JBQ
>

Jean-Baptiste Queru

unread,
Apr 28, 2012, 3:04:16 PM4/28/12
to android-...@googlegroups.com
Yes, the emulator supports ARMv7-A, VFPv3-D32 and NEON.

Note: in the emulator, NEON code is sometimes slower than non-NEON code.

JBQ

Mathew Says IdareYou

unread,
Apr 30, 2012, 2:54:52 AM4/30/12
to android-...@googlegroups.com

Also with custom source files from Cyanogenmod, even ARMv6-VFP is possible.

Jean-Baptiste Queru

unread,
Apr 30, 2012, 11:44:38 AM4/30/12
to android-...@googlegroups.com
Yes, I expect that'd be possible. We've never had that combo in a
flagship device, so there's no direct AOSP support for it.

JBQ

Vik

unread,
Apr 30, 2012, 2:38:20 PM4/30/12
to Android Building
Thanks!I have a few questions though.
I see that the armv7-a.mk has:
arch_variant_cflags := \
-march=armv7-a \
-mfloat-abi=softfp \
-mfpu=vfpv3-d16

And the armv7-a-neon.mk has:
arch_variant_cflags := \
-march=armv7-a \
-mfloat-abi=softfp \
-mfpu=neon

Does this mean the default build (armv7-a) has the FPU enabled? And
TARGET_ARCH_VARIANT with neon will just enable the
SIMD extension?
Also, I could not find any detailed information
on difference between -mfloat-abi=softfp and -mfloat-abi=hard except
that it says "soft fp calling conventions
will be used in case of softfp" with no further description.

Thanks,
V
On Apr 30, 8:44 am, Jean-Baptiste Queru <j...@android.com> wrote:
> Yes, I expect that'd be possible. We've never had that combo in a
> flagship device, so there's no direct AOSP support for it.
>
> JBQ
>
> On Sun, Apr 29, 2012 at 11:54 PM, Mathew Says IdareYou
>
>
>
>
>
>
>
>
>
> <iamthegodk...@gmail.com> wrote:
> > Also with custom source files from Cyanogenmod, even ARMv6-VFP is possible.
>
> > On Apr 29, 2012 3:04 AM, "Jean-Baptiste Queru" <j...@android.com> wrote:
>
> >> Yes, the emulator supports ARMv7-A, VFPv3-D32 and NEON.
>
> >> Note: in the emulator, NEON code is sometimes slower than non-NEON code.
>
> >> JBQ
>

Jean-Baptiste Queru

unread,
Apr 30, 2012, 3:33:38 PM4/30/12
to android-...@googlegroups.com
Android standardized on 2 ARM ABIs as visible to NDK applications:

-ARMv5TE
-ARMv7-A with VFPv3-D16.

In addition, we've had enough devices shipping with ARMv7-A, VFPv3-D32
and NEON that we build system software specifically for that
combination as it makes a measurable difference.

JBQ

Vik

unread,
May 1, 2012, 6:06:43 AM5/1/12
to Android Building
Thanks JBQ!
Is -mfoat-abi=hard option supported with vfpuv3-16 or neon ? I tried
to build it, but got linker errors
which said something like: input uses FP registers but output does
not.

Thanks,
V

Jean-Baptiste Queru

unread,
May 1, 2012, 7:37:54 AM5/1/12
to android-...@googlegroups.com
Unfortunately, I don't know the details of gcc flags for the ARM
variants, so I'm not going to be able to help you at that level of
detail. Most probably, someone else on the list will know those
details.

JBQ

Mathew Says IdareYou

unread,
May 1, 2012, 8:11:31 AM5/1/12
to android-...@googlegroups.com

That's what I thought.....you don't accept official support for other devices than the ones stated in the Android Source webpage, right?

Jean-Baptiste Queru

unread,
May 1, 2012, 8:18:14 AM5/1/12
to android-...@googlegroups.com
Well, it's hard to officially support something that you can't test.

JBQ

On Tue, May 1, 2012 at 5:11 AM, Mathew Says IdareYou

Mathew Says IdareYou

unread,
May 1, 2012, 9:44:15 AM5/1/12
to android-...@googlegroups.com

I see, so the devices in the webpage are the ones that you own + have open sources?

Jean-Baptiste Queru

unread,
May 1, 2012, 9:58:39 AM5/1/12
to android-...@googlegroups.com
Technically, there are a few other devices that Google has had some
involvement in that weren't ever supported in AOSP (most notably,
"sholes", i.e. the original VZW Droid).

We don't have full sources to any device, there are always some
hardware-specific or customer-specific binaries that we don't have
source access to.

With the exception of dream/sapphire (which were ARMv6 but which we
considered as ARMv5TE), every device we've worked on over the last 3
years has been compatible with ARMv7-A, with at least VFPv3-D16.

JBQ

On Tue, May 1, 2012 at 6:44 AM, Mathew Says IdareYou

Mathew Says IdareYou

unread,
May 1, 2012, 10:44:21 AM5/1/12
to android-...@googlegroups.com

Hmm....I see.
Thanks for the info.
By the way do you manage any pull requests on Android @ GitHub?

Jean-Baptiste Queru

unread,
May 1, 2012, 11:01:34 AM5/1/12
to android-...@googlegroups.com
We don't use GitHub for Android, and all contributions to Android must
go through Gerrit.

JBQ

On Tue, May 1, 2012 at 7:44 AM, Mathew Says IdareYou

Mathew Says IdareYou

unread,
May 1, 2012, 12:36:43 PM5/1/12
to android-...@googlegroups.com

Well, I do see http://github.com/android having their sources mirrored from http://android.googlesource.com.....
You guys place it there for backup, or?

Jean-Baptiste Queru

unread,
May 1, 2012, 12:47:50 PM5/1/12
to android-...@googlegroups.com
We don't maintain that.

JBQ

On Tue, May 1, 2012 at 9:36 AM, Mathew Says IdareYou

Mathew Says IdareYou

unread,
May 2, 2012, 12:47:56 AM5/2/12
to android-...@googlegroups.com

Ahh, I see.

Atte Peltomaki

unread,
May 2, 2012, 7:51:17 AM5/2/12
to android-...@googlegroups.com
On Tue, May 01, 2012 at 12:06:43PM +0200, Vik wrote:
> Is -mfoat-abi=hard option supported with vfpuv3-16 or neon ?

Both. (But neither in Android).

> I tried to build it, but got linker errors which said something like:
> input uses FP registers but output does not.

This means you're trying to link together soft/softfp and hard-float
compiled code. Most likely you've tried to use -mfloat-abi=hard with the
stock toolchain, where all the support libraries are soft-float.

If you want to attempt pure hard-float build, you'll need to build a
dedicated toolchain for it first. I spent a few hours with this and
managed to build a working toolchain, but that's as far as I got.

Here's a good introduction to the different ARM ABI models:
http://wiki.debian.org/ArmHardFloatPort#Background_information

--
Atte Peltomäki
NVIDIA Corporation
nvpublic

Vik

unread,
May 5, 2012, 9:38:57 PM5/5/12
to Android Building
Thanks Atte! I was able to figure most of this and finally gave up
compiling with 'hard' :).
Wrote a small program with floating point operations and checked its
asm code. Just as expected
it followed soft calling conventions for functions with floating point
parameters, and
generated floating point instructions for computation. I am live with
that for now.

Thanks,
Vik

Atte Peltomaki

unread,
May 7, 2012, 4:34:29 AM5/7/12
to android-...@googlegroups.com
Using hardfloat mode only affects floating point operations anyway, so
the performance boost is mainly seen with applications that make heavy
use of floating-point ops. I don't think there's that much in Android to
benefit from it, but on Linux there are many 3rd party applications not
specifically written for ARM that really do benefit a lot. Moreover, if
you did compile Android entirely as hardfloat, you'd lose binary
compatibility with all existing software with native (C/C++) code.

Linaro project has a TODO-item for compiling parts of Android as
hardfloat without breaking binary compatibility, but so far I haven't
seen any action on it.

On Sun, May 06, 2012 at 03:38:57AM +0200, Vik wrote:
> Thanks Atte! I was able to figure most of this and finally gave up
> compiling with 'hard' :).
> Wrote a small program with floating point operations and checked its
> asm code. Just as expected
> it followed soft calling conventions for functions with floating point
> parameters, and
> generated floating point instructions for computation. I am live with
> that for now.
>

hjp7...@gmail.com

unread,
Aug 22, 2013, 11:09:33 AM8/22/13
to android-...@googlegroups.com
Would you mind telling me how to build a dedicated toolchain for pure hard float build?

在 2012年5月2日星期三UTC+8下午7时51分17秒,Atte写道:
Reply all
Reply to author
Forward
0 new messages