Does ARMEL toolchain include NEON support?

classic Classic list List threaded Threaded
16 messages Options
Reply | Threaded
Open this post in threaded view
|

Does ARMEL toolchain include NEON support?

Jeffrey Walton-3
Hi Everyone,

I'm investigating a failed build for ARMEL. I don't have access to the
build machine so I have to study the logs or ask our package
maintainer to run commands for us.

The build log is at
https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B&suite=experimental
(package) and https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=armel&ver=8.1.0-1&stamp=1551251751&raw=0
(ARMEL).

We have tried to use -mfpu=neon and -mfloat-abi=softfp or
-mfloat-abi=hard for the NEON specific files but both produce compile
failures. "NEON specific files" are ones with the name *_simd.cpp,
like aria_simd.cpp.

I test the build locally with about 6 ARM dev-boards and have not
encountered the problem. However, all of the dev-board are hard float
machines.

My question is, is it possible to use the NEON unit when building with
ARMEL? If so, then how do we do it?

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Vagrant Cascadian-4
On 2019-02-27, Jeffrey Walton wrote:

> I'm investigating a failed build for ARMEL. I don't have access to the
> build machine so I have to study the logs or ask our package
> maintainer to run commands for us.
>
> The build log is at
> https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B&suite=experimental
> (package) and https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=armel&ver=8.1.0-1&stamp=1551251751&raw=0
> (ARMEL).
>
> We have tried to use -mfpu=neon and -mfloat-abi=softfp or
> -mfloat-abi=hard for the NEON specific files but both produce compile
> failures. "NEON specific files" are ones with the name *_simd.cpp,
> like aria_simd.cpp.
>
> I test the build locally with about 6 ARM dev-boards and have not
> encountered the problem. However, all of the dev-board are hard float
> machines.
>
> My question is, is it possible to use the NEON unit when building with
> ARMEL? If so, then how do we do it?
My understanding is that neither armhf nor armel assume the presence of
NEON; it's optional, and code must not be built forcing the use of NEON
on those architectures.

NEON support needs to be detected at runtime, and the code handle if
NEON is not present.


live well,
  vagrant

signature.asc (233 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Jeffrey Walton-3
On Wed, Feb 27, 2019 at 2:59 PM Vagrant Cascadian <[hidden email]> wrote:

>
> On 2019-02-27, Jeffrey Walton wrote:
> > I'm investigating a failed build for ARMEL. I don't have access to the
> > build machine so I have to study the logs or ask our package
> > maintainer to run commands for us.
> >
> > The build log is at
> > https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B&suite=experimental
> > (package) and https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=armel&ver=8.1.0-1&stamp=1551251751&raw=0
> > (ARMEL).
> >
> > We have tried to use -mfpu=neon and -mfloat-abi=softfp or
> > -mfloat-abi=hard for the NEON specific files but both produce compile
> > failures. "NEON specific files" are ones with the name *_simd.cpp,
> > like aria_simd.cpp.
> >
> > I test the build locally with about 6 ARM dev-boards and have not
> > encountered the problem. However, all of the dev-board are hard float
> > machines.
> >
> > My question is, is it possible to use the NEON unit when building with
> > ARMEL? If so, then how do we do it?
>
> My understanding is that neither armhf nor armel assume the presence of
> NEON; it's optional, and code must not be built forcing the use of NEON
> on those architectures.

Got it.

> NEON support needs to be detected at runtime, and the code handle if
> NEON is not present.

Right, that's what we do. At runtime we switch to NEON if available.
Confer (https://github.com/weidai11/cryptopp/blob/master/aria.cpp#L179):

#if CRYPTOPP_ARM_NEON_AVAILABLE
    if (HasNEON())
    {
        ARIA_UncheckedSetKey_Schedule_NEON(rk, m_w, keylen);
    }
    else
#endif
    {
        // C/C++ implementation
        ...
    }

The problem is, we cannot compile modules with NEON support. It is
like the compiler is missing NEON support.

The architectural difference seems to be, some other projects use GAS,
and provide the  ASM in *.s file. We use C/C++ intrinsics in a *.c or
*.cpp file. (This allows us to support more platforms using a single
code base, like Android, Linux, iOS, Windows Mobile and Windows Phone.
The downside is, we are usually a tad bit slower than ASM).

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Steve McIntyre
In reply to this post by Jeffrey Walton-3
On Wed, Feb 27, 2019 at 02:16:46PM -0500, Jeffrey Walton wrote:

>Hi Everyone,
>
>I'm investigating a failed build for ARMEL. I don't have access to the
>build machine so I have to study the logs or ask our package
>maintainer to run commands for us.
>
>The build log is at
>https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B&suite=experimental
>(package) and https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=armel&ver=8.1.0-1&stamp=1551251751&raw=0
>(ARMEL).
>
>We have tried to use -mfpu=neon and -mfloat-abi=softfp or
>-mfloat-abi=hard for the NEON specific files but both produce compile
>failures. "NEON specific files" are ones with the name *_simd.cpp,
>like aria_simd.cpp.
>
>I test the build locally with about 6 ARM dev-boards and have not
>encountered the problem. However, all of the dev-board are hard float
>machines.

OK. In your build log I can see

n file included from aria_simd.cpp:19:
/usr/lib/gcc/arm-linux-gnueabi/8/include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softfp or -mfloat-abi=hard"
 #error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softfp or -mfloat-abi=hard"

What errors do you get if you try -mfloat-abi=softfp (etc.)?

To be able to use NEON support you may also have to specify a CPU/FPU
combination that includes it - the default armel setup it for ARMv5
which is not going to help you.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"I can't ever sleep on planes ... call it irrational if you like, but I'm
 afraid I'll miss my stop" -- Vivek Das Mohapatra

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Jeffrey Walton-3
On Wed, Feb 27, 2019 at 4:01 PM Steve McIntyre <[hidden email]> wrote:

>
> On Wed, Feb 27, 2019 at 02:16:46PM -0500, Jeffrey Walton wrote:
> >
> >I'm investigating a failed build for ARMEL. I don't have access to the
> >build machine so I have to study the logs or ask our package
> >maintainer to run commands for us.
> >
> >The build log is at
> >https://buildd.debian.org/status/package.php?p=libcrypto%2B%2B&suite=experimental
> >(package) and https://buildd.debian.org/status/fetch.php?pkg=libcrypto%2B%2B&arch=armel&ver=8.1.0-1&stamp=1551251751&raw=0
> >(ARMEL).
> > ...
>
> OK. In your build log I can see
>
> n file included from aria_simd.cpp:19:
> /usr/lib/gcc/arm-linux-gnueabi/8/include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softfp or -mfloat-abi=hard"
>  #error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softfp or -mfloat-abi=hard"
>
> What errors do you get if you try -mfloat-abi=softfp (etc.)?

I seem to recall László Böszörményi, who is our package maintainer,
ran that test for us. It also failed. I believe it was roughly the
same error for both hard and soft floats.

> To be able to use NEON support you may also have to specify a CPU/FPU
> combination that includes it - the default armel setup it for ARMv5
> which is not going to help you.

Yeah, the problem is centered around this. When we test for NEON we
include -march=armv7-a. The GNUmakefile does this
(https://github.com/weidai11/cryptopp/blob/master/GNUmakefile):

HOSTX := $(shell $(CXX) $(CXXFLAGS) -dumpmachine 2>/dev/null | cut -f 1 -d '-')
IS_ARM32 := $(shell echo "$(HOSTX)" | $(GREP) -i -c -E 'arm|armhf|arm7l|eabihf')
IS_NEON := $(shell $(CXX) $(CXXFLAGS) -dumpmachine 2>/dev/null |
$(GREP) -i -c -E 'armv7|armhf|arm7l|eabihf|armv8|aarch32|aarch64')

Then, it does this:

ifeq ($(IS_ARM32)$(IS_NEON),11)

  TPROG = TestPrograms/test_arm_neon.cxx
  TOPT = -march=armv7-a -mfloat-abi=$(FP_ABI) -mfpu=neon
  HAVE_OPT = $(shell $(CXX) $(TCXXFLAGS) $(ZOPT) $(TOPT) $(TPROG) -o
$(TOUT) 2>&1 | tr ' ' '\n' | wc -l)
  ifeq ($(strip $(HAVE_OPT)),0)
    NEON_FLAG = -march=armv7-a -mfloat-abi=$(FP_ABI) -mfpu=neon
    ....
endif

When we detect ARM32 and NEON is available using a test compile, then
we enable IS_NEON . I'm thinking IS_ARM32 or IS_NEON is misdetecting.
The feature test works well elsewhere, including x86, x86_64, Aarch32,
Aarch64, MIPS, MIPS64, PPC, PPC64, etc.

The problem is, I don't know what the output of or 'g++ -dumpmachine'
or 'uname -m' are, so I am not sure if we are misdetecting IS_ARM32 or
IS_NEON .

I wrote to the guys who maintain the build system and asked them to
provide the explicit output of the commands with the logs. They told
me the information was there without the need for providing the output
g++ -dumpmachine' or 'uname -m'.

(My hunch is 'g++ -dumpmachine' is returning something other than what
we expect. Maybe something like 'armel'. I won't know for certain
until I see the output of the commands, but which Debian refuses to
provide).

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Steve McIntyre
On Wed, Feb 27, 2019 at 04:59:50PM -0500, Jeffrey Walton wrote:

>On Wed, Feb 27, 2019 at 4:01 PM Steve McIntyre <[hidden email]> wrote:
>>
>> OK. In your build log I can see
>>
>> n file included from aria_simd.cpp:19:
>> /usr/lib/gcc/arm-linux-gnueabi/8/include/arm_neon.h:31:2: error: #error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softfp or -mfloat-abi=hard"
>>  #error "NEON intrinsics not available with the soft-float ABI.  Please use -mfloat-abi=softfp or -mfloat-abi=hard"
>>
>> What errors do you get if you try -mfloat-abi=softfp (etc.)?
>
>I seem to recall László Böszörményi, who is our package maintainer,
>ran that test for us. It also failed. I believe it was roughly the
>same error for both hard and soft floats.

Right, OK. gcc can be infuriating at times like this. :-)

>> To be able to use NEON support you may also have to specify a CPU/FPU
>> combination that includes it - the default armel setup it for ARMv5
>> which is not going to help you.
>
>Yeah, the problem is centered around this. When we test for NEON we
>include -march=armv7-a. The GNUmakefile does this
>(https://github.com/weidai11/cryptopp/blob/master/GNUmakefile):
>
>HOSTX := $(shell $(CXX) $(CXXFLAGS) -dumpmachine 2>/dev/null | cut -f 1 -d '-')
>IS_ARM32 := $(shell echo "$(HOSTX)" | $(GREP) -i -c -E 'arm|armhf|arm7l|eabihf')
>IS_NEON := $(shell $(CXX) $(CXXFLAGS) -dumpmachine 2>/dev/null |
>$(GREP) -i -c -E 'armv7|armhf|arm7l|eabihf|armv8|aarch32|aarch64')
>
>Then, it does this:
>
>ifeq ($(IS_ARM32)$(IS_NEON),11)
>
>  TPROG = TestPrograms/test_arm_neon.cxx
>  TOPT = -march=armv7-a -mfloat-abi=$(FP_ABI) -mfpu=neon
>  HAVE_OPT = $(shell $(CXX) $(TCXXFLAGS) $(ZOPT) $(TOPT) $(TPROG) -o
>$(TOUT) 2>&1 | tr ' ' '\n' | wc -l)
>  ifeq ($(strip $(HAVE_OPT)),0)
>    NEON_FLAG = -march=armv7-a -mfloat-abi=$(FP_ABI) -mfpu=neon
>    ....
>endif
>
>When we detect ARM32 and NEON is available using a test compile, then
>we enable IS_NEON . I'm thinking IS_ARM32 or IS_NEON is misdetecting.
>The feature test works well elsewhere, including x86, x86_64, Aarch32,
>Aarch64, MIPS, MIPS64, PPC, PPC64, etc.
>
>The problem is, I don't know what the output of or 'g++ -dumpmachine'
>or 'uname -m' are, so I am not sure if we are misdetecting IS_ARM32 or
>IS_NEON .

So, I've got to ask - what hardware are you likely targeting here
where it matters to build stuff for armel yet also use NEON if it's
available? Most people with hardware that *can* do NEON should be
using armhf, surely?

>I wrote to the guys who maintain the build system and asked them to
>provide the explicit output of the commands with the logs. They told
>me the information was there without the need for providing the output
>g++ -dumpmachine' or 'uname -m'.

Helpful... :-/

>(My hunch is 'g++ -dumpmachine' is returning something other than what
>we expect. Maybe something like 'armel'. I won't know for certain
>until I see the output of the commands, but which Debian refuses to
>provide).

You can work this out if you have access to a Debian porter box or
similar. But, for the sake of being helpful I see the following in an
armel chroot locally:

(sid-armel)steve@mjolnir:~$ g++ -dumpmachine
arm-linux-gnueabi

But that's not very instructive. More usefully, you can see what's
defined by the compiler if you do the following (LONG output!):

(sid-armel)steve@mjolnir:~$ g++ -dM -E -x c++ - < /dev/null
#define __DBL_MIN_EXP__ (-1021)
#define __HQ_FBIT__ 15
#define __FLT32X_MAX_EXP__ 1024
#define __cpp_attributes 200809
#define __UINT_LEAST16_MAX__ 0xffff
#define __ARM_SIZEOF_WCHAR_T 4
#define __ATOMIC_ACQUIRE 2
#define __SFRACT_IBIT__ 0
#define __FLT_MIN__ 1.1754943508222875e-38F
#define __GCC_IEC_559_COMPLEX 0
#define __cpp_aggregate_nsdmi 201304
#define __UFRACT_MAX__ 0XFFFFP-16UR
#define __UINT_LEAST8_TYPE__ unsigned char
#define __DQ_FBIT__ 63
#define __INTMAX_C(c) c ## LL
#define __ULFRACT_FBIT__ 32
#define __SACCUM_EPSILON__ 0x1P-7HK
#define __CHAR_BIT__ 8
#define __USQ_IBIT__ 0
#define __UINT8_MAX__ 0xff
#define __ACCUM_FBIT__ 15
#define __WINT_MAX__ 0xffffffffU
#define __FLT32_MIN_EXP__ (-125)
#define __cpp_static_assert 200410
#define __USFRACT_FBIT__ 8
#define __ORDER_LITTLE_ENDIAN__ 1234
#define __SIZE_MAX__ 0xffffffffU
#define __ARM_ARCH_ISA_ARM 1
#define __WCHAR_MAX__ 0xffffffffU
#define __LACCUM_IBIT__ 32
#define __DBL_DENORM_MIN__ double(4.9406564584124654e-324L)
#define __GCC_ATOMIC_CHAR_LOCK_FREE 1
#define __GCC_IEC_559 0
#define __FLT32X_DECIMAL_DIG__ 17
#define __FLT_EVAL_METHOD__ 0
#define __unix__ 1
#define __cpp_binary_literals 201304
#define __LLACCUM_MAX__ 0X7FFFFFFFFFFFFFFFP-31LLK
#define __FLT64_DECIMAL_DIG__ 17
#define __GCC_ATOMIC_CHAR32_T_LOCK_FREE 1
#define __FRACT_FBIT__ 15
#define __cpp_variadic_templates 200704
#define __UINT_FAST64_MAX__ 0xffffffffffffffffULL
#define __SIG_ATOMIC_TYPE__ int
#define __UACCUM_FBIT__ 16
#define __DBL_MIN_10_EXP__ (-307)
#define __FINITE_MATH_ONLY__ 0
#define __ARMEL__ 1
#define __cpp_variable_templates 201304
#define __LFRACT_IBIT__ 0
#define __GNUC_PATCHLEVEL__ 0
#define __FLT32_HAS_DENORM__ 1
#define __LFRACT_MAX__ 0X7FFFFFFFP-31LR
#define __UINT_FAST8_MAX__ 0xff
#define __has_include(STR) __has_include__(STR)
#define __DEC64_MAX_EXP__ 385
#define __INT8_C(c) c
#define __INT_LEAST8_WIDTH__ 8
#define __UINT_LEAST64_MAX__ 0xffffffffffffffffULL
#define __SA_FBIT__ 15
#define __SHRT_MAX__ 0x7fff
#define __LDBL_MAX__ 1.7976931348623157e+308L
#define __FRACT_MAX__ 0X7FFFP-15R
#define __ARM_ARCH_5TE__ 1
#define __UFRACT_FBIT__ 16
#define __UFRACT_MIN__ 0.0UR
#define __UINT_LEAST8_MAX__ 0xff
#define __GCC_ATOMIC_BOOL_LOCK_FREE 1
#define __UINTMAX_TYPE__ long long unsigned int
#define __LLFRACT_EPSILON__ 0x1P-63LLR
#define __linux 1
#define __DEC32_EPSILON__ 1E-6DF
#define __FLT_EVAL_METHOD_TS_18661_3__ 0
#define __CHAR_UNSIGNED__ 1
#define __UINT32_MAX__ 0xffffffffU
#define __GXX_EXPERIMENTAL_CXX0X__ 1
#define __ULFRACT_MAX__ 0XFFFFFFFFP-32ULR
#define __TA_IBIT__ 64
#define __LDBL_MAX_EXP__ 1024
#define __WINT_MIN__ 0U
#define __linux__ 1
#define __INT_LEAST16_WIDTH__ 16
#define __ULLFRACT_MIN__ 0.0ULLR
#define __SCHAR_MAX__ 0x7f
#define __WCHAR_MIN__ 0U
#define __INT64_C(c) c ## LL
#define __DBL_DIG__ 15
#define __GCC_ATOMIC_POINTER_LOCK_FREE 1
#define __LLACCUM_MIN__ (-0X1P31LLK-0X1P31LLK)
#define __SIZEOF_INT__ 4
#define __SIZEOF_POINTER__ 4
#define __GCC_ATOMIC_CHAR16_T_LOCK_FREE 1
#define __USACCUM_IBIT__ 8
#define __USER_LABEL_PREFIX__
#define __STDC_HOSTED__ 1
#define __LDBL_HAS_INFINITY__ 1
#define __LFRACT_MIN__ (-0.5LR-0.5LR)
#define __HA_IBIT__ 8
#define __FLT32_DIG__ 6
#define __TQ_IBIT__ 0
#define __FLT_EPSILON__ 1.1920928955078125e-7F
#define __APCS_32__ 1
#define __GXX_WEAK__ 1
#define __SHRT_WIDTH__ 16
#define __USFRACT_IBIT__ 0
#define __LDBL_MIN__ 2.2250738585072014e-308L
#define __FRACT_MIN__ (-0.5R-0.5R)
#define __DEC32_MAX__ 9.999999E96DF
#define __cpp_threadsafe_static_init 200806
#define __DA_IBIT__ 32
#define __ARM_SIZEOF_MINIMAL_ENUM 4
#define __FLT32X_HAS_INFINITY__ 1
#define __INT32_MAX__ 0x7fffffff
#define __UQQ_FBIT__ 8
#define __INT_WIDTH__ 32
#define __SIZEOF_LONG__ 4
#define __UACCUM_MAX__ 0XFFFFFFFFP-16UK
#define __STDC_ISO_10646__ 201706L
#define __UINT16_C(c) c
#define __PTRDIFF_WIDTH__ 32
#define __DECIMAL_DIG__ 17
#define __LFRACT_EPSILON__ 0x1P-31LR
#define __FLT64_EPSILON__ 2.2204460492503131e-16F64
#define __ULFRACT_MIN__ 0.0ULR
#define __gnu_linux__ 1
#define __INTMAX_WIDTH__ 64
#define __FLT64_MIN_EXP__ (-1021)
#define __has_include_next(STR) __has_include_next__(STR)
#define __LDBL_HAS_QUIET_NAN__ 1
#define __ULACCUM_IBIT__ 32
#define __FLT64_MANT_DIG__ 53
#define __UACCUM_EPSILON__ 0x1P-16UK
#define __GNUC__ 8
#define __ULLACCUM_MAX__ 0XFFFFFFFFFFFFFFFFP-32ULLK
#define __GXX_RTTI 1
#define __pie__ 2
#define __cpp_delegating_constructors 200604
#define __HQ_IBIT__ 0
#define __FLT_HAS_DENORM__ 1
#define __SIZEOF_LONG_DOUBLE__ 8
#define __BIGGEST_ALIGNMENT__ 8
#define __STDC_UTF_16__ 1
#define __FLT64_MAX_10_EXP__ 308
#define __GNUC_STDC_INLINE__ 1
#define __DQ_IBIT__ 0
#define __FLT32_HAS_INFINITY__ 1
#define __DBL_MAX__ double(1.7976931348623157e+308L)
#define __ULFRACT_IBIT__ 0
#define __cpp_raw_strings 200710
#define __INT_FAST32_MAX__ 0x7fffffff
#define __DBL_HAS_INFINITY__ 1
#define __ACCUM_IBIT__ 16
#define __DEC32_MIN_EXP__ (-94)
#define __THUMB_INTERWORK__ 1
#define __INTPTR_WIDTH__ 32
#define __LACCUM_MAX__ 0X7FFFFFFFFFFFFFFFP-31LK
#define __FLT32X_HAS_DENORM__ 1
#define __INT_FAST16_TYPE__ int
#define __LDBL_HAS_DENORM__ 1
#define __cplusplus 201402L
#define __cpp_ref_qualifiers 200710
#define __DEC128_MAX__ 9.999999999999999999999999999999999E6144DL
#define __INT_LEAST32_MAX__ 0x7fffffff
#define __ARM_PCS 1
#define __DEC32_MIN__ 1E-95DF
#define __ACCUM_MAX__ 0X7FFFFFFFP-15K
#define __DEPRECATED 1
#define __cpp_rvalue_references 200610
#define __DBL_MAX_EXP__ 1024
#define __USACCUM_EPSILON__ 0x1P-8UHK
#define __WCHAR_WIDTH__ 32
#define __FLT32_MAX__ 3.4028234663852886e+38F32
#define __DEC128_EPSILON__ 1E-33DL
#define __SFRACT_MAX__ 0X7FP-7HR
#define __FRACT_IBIT__ 0
#define __PTRDIFF_MAX__ 0x7fffffff
#define __UACCUM_MIN__ 0.0UK
#define __UACCUM_IBIT__ 16
#define __FLT32_HAS_QUIET_NAN__ 1
#define __GNUG__ 8
#define __LONG_LONG_MAX__ 0x7fffffffffffffffLL
#define __SIZEOF_SIZE_T__ 4
#define __ULACCUM_MAX__ 0XFFFFFFFFFFFFFFFFP-32ULK
#define __cpp_rvalue_reference 200610
#define __cpp_nsdmi 200809
#define __SIZEOF_WINT_T__ 4
#define __LONG_LONG_WIDTH__ 64
#define __cpp_initializer_lists 200806
#define __FLT32_MAX_EXP__ 128
#define __SA_IBIT__ 16
#define __ULLACCUM_MIN__ 0.0ULLK
#define __cpp_hex_float 201603
#define __GXX_ABI_VERSION 1013
#define __UTA_FBIT__ 64
#define __SOFTFP__ 1
#define __FLT_MIN_EXP__ (-125)
#define __USFRACT_MAX__ 0XFFP-8UHR
#define __UFRACT_IBIT__ 0
#define __cpp_lambdas 200907
#define __ARM_FEATURE_QBIT 1
#define __INT_FAST64_TYPE__ long long int
#define __FLT64_DENORM_MIN__ 4.9406564584124654e-324F64
#define __DBL_MIN__ double(2.2250738585072014e-308L)
#define __PIE__ 2
#define __FLT32X_EPSILON__ 2.2204460492503131e-16F32x
#define __LACCUM_MIN__ (-0X1P31LK-0X1P31LK)
#define __ULLACCUM_FBIT__ 32
#define __GXX_TYPEINFO_EQUALITY_INLINE 0
#define __FLT64_MIN_10_EXP__ (-307)
#define __ULLFRACT_EPSILON__ 0x1P-64ULLR
#define __DEC128_MIN__ 1E-6143DL
#define __REGISTER_PREFIX__
#define __UINT16_MAX__ 0xffff
#define __DBL_HAS_DENORM__ 1
#define __ACCUM_MIN__ (-0X1P15K-0X1P15K)
#define __SQ_IBIT__ 0
#define __FLT32_MIN__ 1.1754943508222875e-38F32
#define __UINT8_TYPE__ unsigned char
#define __UHA_FBIT__ 8
#define __NO_INLINE__ 1
#define __SFRACT_MIN__ (-0.5HR-0.5HR)
#define __UTQ_FBIT__ 128
#define __FLT_MANT_DIG__ 24
#define __LDBL_DECIMAL_DIG__ 17
#define __VERSION__ "8.2.0"
#define __UINT64_C(c) c ## ULL
#define __ULLFRACT_FBIT__ 64
#define __cpp_unicode_characters 200704
#define __FRACT_EPSILON__ 0x1P-15R
#define __ULACCUM_MIN__ 0.0ULK
#define _STDC_PREDEF_H 1
#define __UDA_FBIT__ 32
#define __cpp_decltype_auto 201304
#define __LLACCUM_EPSILON__ 0x1P-31LLK
#define __GCC_ATOMIC_INT_LOCK_FREE 1
#define __FLT32_MANT_DIG__ 24
#define __FLOAT_WORD_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __USFRACT_MIN__ 0.0UHR
#define __ULLACCUM_IBIT__ 32
#define __UQQ_IBIT__ 0
#define __SCHAR_WIDTH__ 8
#define __INT32_C(c) c
#define __DEC64_EPSILON__ 1E-15DD
#define __ORDER_PDP_ENDIAN__ 3412
#define __DEC128_MIN_EXP__ (-6142)
#define __UHQ_FBIT__ 16
#define __LLACCUM_FBIT__ 31
#define __FLT32_MAX_10_EXP__ 38
#define __INT_FAST32_TYPE__ int
#define __UINT_LEAST16_TYPE__ short unsigned int
#define unix 1
#define __INT16_MAX__ 0x7fff
#define __cpp_rtti 199711
#define __SIZE_TYPE__ unsigned int
#define __UINT64_MAX__ 0xffffffffffffffffULL
#define __UDQ_FBIT__ 64
#define __INT8_TYPE__ signed char
#define __cpp_digit_separators 201309
#define __ELF__ 1
#define __ULFRACT_EPSILON__ 0x1P-32ULR
#define __LLFRACT_FBIT__ 63
#define __FLT_RADIX__ 2
#define __INT_LEAST16_TYPE__ short int
#define __LDBL_EPSILON__ 2.2204460492503131e-16L
#define __UINTMAX_C(c) c ## ULL
#define __SACCUM_MAX__ 0X7FFFP-7HK
#define __SIG_ATOMIC_MAX__ 0x7fffffff
#define __GCC_ATOMIC_WCHAR_T_LOCK_FREE 1
#define __VFP_FP__ 1
#define __SIZEOF_PTRDIFF_T__ 4
#define __FLT32X_MANT_DIG__ 53
#define __LACCUM_EPSILON__ 0x1P-31LK
#define __FLT32X_MIN_EXP__ (-1021)
#define __DEC32_SUBNORMAL_MIN__ 0.000001E-95DF
#define __INT_FAST16_MAX__ 0x7fffffff
#define __FLT64_DIG__ 15
#define __UINT_FAST32_MAX__ 0xffffffffU
#define __UINT_LEAST64_TYPE__ long long unsigned int
#define __USACCUM_MAX__ 0XFFFFP-8UHK
#define __SFRACT_EPSILON__ 0x1P-7HR
#define __FLT_HAS_QUIET_NAN__ 1
#define __FLT_MAX_10_EXP__ 38
#define __LONG_MAX__ 0x7fffffffL
#define __DEC128_SUBNORMAL_MIN__ 0.000000000000000000000000000000001E-6143DL
#define __FLT_HAS_INFINITY__ 1
#define __unix 1
#define __cpp_unicode_literals 200710
#define __USA_FBIT__ 16
#define __UINT_FAST16_TYPE__ unsigned int
#define __DEC64_MAX__ 9.999999999999999E384DD
#define __ARM_32BIT_STATE 1
#define __INT_FAST32_WIDTH__ 32
#define __CHAR16_TYPE__ short unsigned int
#define __PRAGMA_REDEFINE_EXTNAME 1
#define __SIZE_WIDTH__ 32
#define __INT_LEAST16_MAX__ 0x7fff
#define __DEC64_MANT_DIG__ 16
#define __INT64_MAX__ 0x7fffffffffffffffLL
#define __UINT_LEAST32_MAX__ 0xffffffffU
#define __SACCUM_FBIT__ 7
#define __FLT32_DENORM_MIN__ 1.4012984643248171e-45F32
#define __GCC_ATOMIC_LONG_LOCK_FREE 1
#define __SIG_ATOMIC_WIDTH__ 32
#define __INT_LEAST64_TYPE__ long long int
#define __ARM_FEATURE_CLZ 1
#define __INT16_TYPE__ short int
#define __INT_LEAST8_TYPE__ signed char
#define __SQ_FBIT__ 31
#define __DEC32_MAX_EXP__ 97
#define __ARM_ARCH_ISA_THUMB 1
#define __INT_FAST8_MAX__ 0x7f
#define __ARM_ARCH 5
#define __INTPTR_MAX__ 0x7fffffff
#define __cpp_sized_deallocation 201309
#define __QQ_FBIT__ 7
#define linux 1
#define __cpp_range_based_for 200907
#define __UTA_IBIT__ 64
#define __FLT64_HAS_QUIET_NAN__ 1
#define __FLT32_MIN_10_EXP__ (-37)
#define __EXCEPTIONS 1
#define __LDBL_MANT_DIG__ 53
#define __SFRACT_FBIT__ 7
#define __SACCUM_MIN__ (-0X1P7HK-0X1P7HK)
#define __DBL_HAS_QUIET_NAN__ 1
#define __FLT64_HAS_INFINITY__ 1
#define __SIG_ATOMIC_MIN__ (-__SIG_ATOMIC_MAX__ - 1)
#define __cpp_return_type_deduction 201304
#define __INTPTR_TYPE__ int
#define __UINT16_TYPE__ short unsigned int
#define __WCHAR_TYPE__ unsigned int
#define __SIZEOF_FLOAT__ 4
#define __USQ_FBIT__ 32
#define __pic__ 2
#define __UINTPTR_MAX__ 0xffffffffU
#define __INT_FAST64_WIDTH__ 64
#define __DEC64_MIN_EXP__ (-382)
#define __cpp_decltype 200707
#define __FLT32_DECIMAL_DIG__ 9
#define __INT_FAST64_MAX__ 0x7fffffffffffffffLL
#define __GCC_ATOMIC_TEST_AND_SET_TRUEVAL 1
#define __FLT_DIG__ 6
#define __UINT_FAST64_TYPE__ long long unsigned int
#define __INT_MAX__ 0x7fffffff
#define __LACCUM_FBIT__ 31
#define __USACCUM_MIN__ 0.0UHK
#define __UHA_IBIT__ 8
#define __INT64_TYPE__ long long int
#define __FLT_MAX_EXP__ 128
#define __UTQ_IBIT__ 0
#define __DBL_MANT_DIG__ 53
#define __cpp_inheriting_constructors 201511
#define __INT_LEAST64_MAX__ 0x7fffffffffffffffLL
#define __DEC64_MIN__ 1E-383DD
#define __WINT_TYPE__ unsigned int
#define __UINT_LEAST32_TYPE__ unsigned int
#define __SIZEOF_SHORT__ 2
#define __ULLFRACT_IBIT__ 0
#define __LDBL_MIN_EXP__ (-1021)
#define __arm__ 1
#define __FLT64_MAX__ 1.7976931348623157e+308F64
#define __UDA_IBIT__ 32
#define __WINT_WIDTH__ 32
#define __INT_LEAST8_MAX__ 0x7f
#define __FLT32X_MAX_10_EXP__ 308
#define __LFRACT_FBIT__ 31
#define __WCHAR_UNSIGNED__ 1
#define __LDBL_MAX_10_EXP__ 308
#define __ATOMIC_RELAXED 0
#define __DBL_EPSILON__ double(2.2204460492503131e-16L)
#define __UINT8_C(c) c
#define __FLT64_MAX_EXP__ 1024
#define __INT_LEAST32_TYPE__ int
#define __SIZEOF_WCHAR_T__ 4
#define __LLFRACT_MAX__ 0X7FFFFFFFFFFFFFFFP-63LLR
#define __TQ_FBIT__ 127
#define __INT_FAST8_TYPE__ signed char
#define __ULLACCUM_EPSILON__ 0x1P-32ULLK
#define __UHQ_IBIT__ 0
#define __ARM_FEATURE_COPROC 7
#define __LLACCUM_IBIT__ 32
#define __FLT64_HAS_DENORM__ 1
#define __FLT32_EPSILON__ 1.1920928955078125e-7F32
#define __DBL_DECIMAL_DIG__ 17
#define __STDC_UTF_32__ 1
#define __INT_FAST8_WIDTH__ 8
#define __DEC_EVAL_METHOD__ 2
#define __FLT32X_MAX__ 1.7976931348623157e+308F32x
#define __TA_FBIT__ 63
#define __UDQ_IBIT__ 0
#define __ORDER_BIG_ENDIAN__ 4321
#define __cpp_runtime_arrays 198712
#define __UINT64_TYPE__ long long unsigned int
#define __ACCUM_EPSILON__ 0x1P-15K
#define __UINT32_C(c) c ## U
#define __INTMAX_MAX__ 0x7fffffffffffffffLL
#define __cpp_alias_templates 200704
#define __BYTE_ORDER__ __ORDER_LITTLE_ENDIAN__
#define __FLT_DENORM_MIN__ 1.4012984643248171e-45F
#define __LLFRACT_IBIT__ 0
#define __INT8_MAX__ 0x7f
#define __LONG_WIDTH__ 32
#define __PIC__ 2
#define __UINT_FAST32_TYPE__ unsigned int
#define __CHAR32_TYPE__ unsigned int
#define __FLT_MAX__ 3.4028234663852886e+38F
#define __cpp_constexpr 201304
#define __USACCUM_FBIT__ 8
#define __INT32_TYPE__ int
#define __SIZEOF_DOUBLE__ 8
#define __cpp_exceptions 199711
#define __FLT_MIN_10_EXP__ (-37)
#define __UFRACT_EPSILON__ 0x1P-16UR
#define __FLT64_MIN__ 2.2250738585072014e-308F64
#define __INT_LEAST32_WIDTH__ 32
#define __INTMAX_TYPE__ long long int
#define __DEC128_MAX_EXP__ 6145
#define __FLT32X_HAS_QUIET_NAN__ 1
#define __ATOMIC_CONSUME 1
#define __GNUC_MINOR__ 2
#define __INT_FAST16_WIDTH__ 32
#define __UINTMAX_MAX__ 0xffffffffffffffffULL
#define __DEC32_MANT_DIG__ 7
#define __FLT32X_DENORM_MIN__ 4.9406564584124654e-324F32x
#define __HA_FBIT__ 7
#define __DBL_MAX_10_EXP__ 308
#define __LDBL_DENORM_MIN__ 4.9406564584124654e-324L
#define __INT16_C(c) c
#define __cpp_generic_lambdas 201304
#define __STDC__ 1
#define __FLT32X_DIG__ 15
#define __PTRDIFF_TYPE__ int
#define __LLFRACT_MIN__ (-0.5LLR-0.5LLR)
#define __ATOMIC_SEQ_CST 5
#define __DA_FBIT__ 31
#define __UINT32_TYPE__ unsigned int
#define __FLT32X_MIN_10_EXP__ (-307)
#define __UINTPTR_TYPE__ unsigned int
#define __USA_IBIT__ 16
#define __DEC64_SUBNORMAL_MIN__ 0.000000000000001E-383DD
#define __ARM_EABI__ 1
#define __DEC128_MANT_DIG__ 34
#define __LDBL_MIN_10_EXP__ (-307)
#define __SIZEOF_LONG_LONG__ 8
#define __ULACCUM_EPSILON__ 0x1P-32ULK
#define __cpp_user_defined_literals 200809
#define __SACCUM_IBIT__ 8
#define __GCC_ATOMIC_LLONG_LOCK_FREE 1
#define __FLT32X_MIN__ 2.2250738585072014e-308F32x
#define __LDBL_DIG__ 15
#define __FLT_DECIMAL_DIG__ 9
#define __UINT_FAST16_MAX__ 0xffffffffU
#define __GCC_ATOMIC_SHORT_LOCK_FREE 1
#define __INT_LEAST64_WIDTH__ 64
#define __ULLFRACT_MAX__ 0XFFFFFFFFFFFFFFFFP-64ULLR
#define __UINT_FAST8_TYPE__ unsigned char
#define _GNU_SOURCE 1
#define __USFRACT_EPSILON__ 0x1P-8UHR
#define __ULACCUM_FBIT__ 32
#define __ARM_FEATURE_DSP 1
#define __QQ_IBIT__ 0
#define __cpp_init_captures 201304
#define __ATOMIC_ACQ_REL 4
#define __ATOMIC_RELEASE 3

*phew*

Does that help you?

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Arguing that you don't care about the right to privacy because you have
 nothing to hide is no different than saying you don't care about free
 speech because you have nothing to say."
   -- Edward Snowden

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Jeffrey Walton-3
On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre <[hidden email]> wrote:

>
> ...
> >The problem is, I don't know what the output of or 'g++ -dumpmachine'
> >or 'uname -m' are, so I am not sure if we are misdetecting IS_ARM32 or
> >IS_NEON .
>
> So, I've got to ask - what hardware are you likely targeting here
> where it matters to build stuff for armel yet also use NEON if it's
> available? Most people with hardware that *can* do NEON should be
> using armhf, surely?

Yeah, I know what you are saying.

The problem in practice with mainstream compilers is (1) ARM and the
ACLE defines are a mess, (2) -march=native does not work like on i686
or x86_64, and (3) RTFM does not work.

For a regular user who wants to use Debian on ARM we need to figure
out how to build to the least capable machine (like ARMv5 or ARMv6)
while making more capable features (like NEON) available.

User's don't want to RTFM to figure out what compiler switches to use.
They just want things to work. The compilers don't make it any easier
because -march=native does not work on ARM.

So the use case we target is, user want the most from their hardware
without reading the manual to configure properly. That means we have
to go through extra gyrations when building.

(I know we bring it on ourselves. We could easily say fuck it - the
user did not bother to read a man page so its the user's problem. But
I'm in the camp that common cases should just work for folks. Folks
should not need to read a manual to make the common case work).

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Steve McIntyre
On Wed, Feb 27, 2019 at 06:30:36PM -0500, Jeffrey Walton wrote:

>On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre <[hidden email]> wrote:
>>
>> So, I've got to ask - what hardware are you likely targeting here
>> where it matters to build stuff for armel yet also use NEON if it's
>> available? Most people with hardware that *can* do NEON should be
>> using armhf, surely?
>
>Yeah, I know what you are saying.
>
>The problem in practice with mainstream compilers is (1) ARM and the
>ACLE defines are a mess, (2) -march=native does not work like on i686
>or x86_64, and (3) RTFM does not work.
>
>For a regular user who wants to use Debian on ARM we need to figure
>out how to build to the least capable machine (like ARMv5 or ARMv6)
>while making more capable features (like NEON) available.

So this is a place where the world is just *different* compared to x86
- the different versions of the ARM architectures have signficantly
different capabilities. If you're looking to build something that
performs well on a modern v7 CPU, compilling for v5 is a
mistake. You'll be using the wrong locking primitives, barriers,
etc. Equally, the features you're going to be looking for (like SMP,
NEON) just don't make sense / don't exist on v5 CPUs.

>User's don't want to RTFM to figure out what compiler switches to use.
>They just want things to work. The compilers don't make it any easier
>because -march=native does not work on ARM.

It's a much wider world out there. :-/

>So the use case we target is, user want the most from their hardware
>without reading the manual to configure properly. That means we have
>to go through extra gyrations when building.
>
>(I know we bring it on ourselves. We could easily say fuck it - the
>user did not bother to read a man page so its the user's problem. But
>I'm in the camp that common cases should just work for folks. Folks
>should not need to read a manual to make the common case work).

Agreed. But it might not actually be *possible* to do some of the
optimisation stuff you're looking at, depending on the CPUs
involved. This is basically one of the reasons we started the armhf
port - it's a higher baseline that makes more sense for modern ARMv7
CPUs, while still making it possible for people to use the older ARMv5
cores out there.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"Yes, of course duct tape works in a near-vacuum. Duct tape works
 anywhere. Duct tape is magic and should be worshipped."
   -― Andy Weir, "The Martian"

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Alan Corey
I ran into something similar once.  Don't use the -neon switch for
AARCH64 because it's built in.

On 2/27/19, Steve McIntyre <[hidden email]> wrote:

> On Wed, Feb 27, 2019 at 06:30:36PM -0500, Jeffrey Walton wrote:
>>On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre <[hidden email]> wrote:
>>>
>>> So, I've got to ask - what hardware are you likely targeting here
>>> where it matters to build stuff for armel yet also use NEON if it's
>>> available? Most people with hardware that *can* do NEON should be
>>> using armhf, surely?
>>
>>Yeah, I know what you are saying.
>>
>>The problem in practice with mainstream compilers is (1) ARM and the
>>ACLE defines are a mess, (2) -march=native does not work like on i686
>>or x86_64, and (3) RTFM does not work.
>>
>>For a regular user who wants to use Debian on ARM we need to figure
>>out how to build to the least capable machine (like ARMv5 or ARMv6)
>>while making more capable features (like NEON) available.
>
> So this is a place where the world is just *different* compared to x86
> - the different versions of the ARM architectures have signficantly
> different capabilities. If you're looking to build something that
> performs well on a modern v7 CPU, compilling for v5 is a
> mistake. You'll be using the wrong locking primitives, barriers,
> etc. Equally, the features you're going to be looking for (like SMP,
> NEON) just don't make sense / don't exist on v5 CPUs.
>
>>User's don't want to RTFM to figure out what compiler switches to use.
>>They just want things to work. The compilers don't make it any easier
>>because -march=native does not work on ARM.
>
> It's a much wider world out there. :-/
>
>>So the use case we target is, user want the most from their hardware
>>without reading the manual to configure properly. That means we have
>>to go through extra gyrations when building.
>>
>>(I know we bring it on ourselves. We could easily say fuck it - the
>>user did not bother to read a man page so its the user's problem. But
>>I'm in the camp that common cases should just work for folks. Folks
>>should not need to read a manual to make the common case work).
>
> Agreed. But it might not actually be *possible* to do some of the
> optimisation stuff you're looking at, depending on the CPUs
> involved. This is basically one of the reasons we started the armhf
> port - it's a higher baseline that makes more sense for modern ARMv7
> CPUs, while still making it possible for people to use the older ARMv5
> cores out there.
>
> --
> Steve McIntyre, Cambridge, UK.
> [hidden email]
> "Yes, of course duct tape works in a near-vacuum. Duct tape works
>  anywhere. Duct tape is magic and should be worshipped."
>    -― Andy Weir, "The Martian"
>
>


--
-------------
No, I won't  call it "climate change", do you have a "reality problem"? - AB1JX
Cities are cages built to contain excess people and keep them from
cluttering up nature.
Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach  Impeach

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Ian Campbell-5
In reply to this post by Steve McIntyre
On Wed, 2019-02-27 at 23:45 +0000, Steve McIntyre wrote:

> On Wed, Feb 27, 2019 at 06:30:36PM -0500, Jeffrey Walton wrote:
> > On Wed, Feb 27, 2019 at 5:46 PM Steve McIntyre <[hidden email]> wrote:
> > > So, I've got to ask - what hardware are you likely targeting here
> > > where it matters to build stuff for armel yet also use NEON if it's
> > > available? Most people with hardware that *can* do NEON should be
> > > using armhf, surely?
> >
> > Yeah, I know what you are saying.
> >
> > The problem in practice with mainstream compilers is (1) ARM and the
> > ACLE defines are a mess, (2) -march=native does not work like on i686
> > or x86_64, and (3) RTFM does not work.
> >
> > For a regular user who wants to use Debian on ARM we need to figure
> > out how to build to the least capable machine (like ARMv5 or ARMv6)
> > while making more capable features (like NEON) available.
>
> So this is a place where the world is just *different* compared to x86
> - the different versions of the ARM architectures have signficantly
> different capabilities. If you're looking to build something that
> performs well on a modern v7 CPU, compilling for v5 is a
> mistake. You'll be using the wrong locking primitives, barriers,
> etc. Equally, the features you're going to be looking for (like SMP,
> NEON) just don't make sense / don't exist on v5 CPUs.

To spell it out: the gist of this is that it isn't possible to provide
a single arm binary which works well for both armel and armhf (which I
think is what Jeff is trying/wants to do?).

The advice here is to instead ship[0] two binaries -- one targetting v5
(no neon etc, aka armel in Debian) and another targetting v7 (w/
possible(? I forget what is optional) neon and other stuff aka armhf in
Debian and other distros).

Ian.

[0] and/or have the build system detect between.

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Steve McIntyre
On Thu, Feb 28, 2019 at 09:05:04AM +0000, Ian Campbell wrote:

>On Wed, 2019-02-27 at 23:45 +0000, Steve McIntyre wrote:
>>
>> So this is a place where the world is just *different* compared to x86
>> - the different versions of the ARM architectures have signficantly
>> different capabilities. If you're looking to build something that
>> performs well on a modern v7 CPU, compilling for v5 is a
>> mistake. You'll be using the wrong locking primitives, barriers,
>> etc. Equally, the features you're going to be looking for (like SMP,
>> NEON) just don't make sense / don't exist on v5 CPUs.
>
>To spell it out: the gist of this is that it isn't possible to provide
>a single arm binary which works well for both armel and armhf (which I
>think is what Jeff is trying/wants to do?).
>
>The advice here is to instead ship[0] two binaries -- one targetting v5
>(no neon etc, aka armel in Debian) and another targetting v7 (w/
>possible(? I forget what is optional) neon and other stuff aka armhf in
>Debian and other distros).

Yep.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"I've only once written 'SQL is my bitch' in a comment. But that code
 is in use on a military site..." -- Simon Booth

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Adrian Bunk-3
In reply to this post by Ian Campbell-5
On Thu, Feb 28, 2019 at 09:05:04AM +0000, Ian Campbell wrote:
>
> To spell it out: the gist of this is that it isn't possible to provide
> a single arm binary which works well for both armel and armhf (which I
> think is what Jeff is trying/wants to do?).

It is not even possible to provide a single arm binary that runs on
both armel and armhf.[1] It is a different ABI.

> The advice here is to instead ship[0] two binaries -- one targetting v5
> (no neon etc, aka armel in Debian) and another targetting v7 (w/
> possible(? I forget what is optional) neon and other stuff aka armhf in
> Debian and other distros).

The main difference between armel and armhf is not the baseline
(at some point Ubuntu had bumped the armel baseline to v7), the
main difference is that there is no FPU in the armel baseline.
Which also means that floating-point parameters must get passed
in integer registers since there are no floating-point registers
in the ABI.

And if you specify an FPU and use softfp, floating-point parameters
still get passed in integer registers since this is part of the ABI.

-mfloat-abi=hard is the incompatible armhf ABI that passes
floating-point parameters in floating-point registers.

> Ian.
>...

cu
Adrian

[1] but multiarch allows installing both armel and armhf at the
    same time

--

       "Is there not promise of rain?" Ling Tan asked suddenly out
        of the darkness. There had been need of rain for many days.
       "Only a promise," Lao Er said.
                                       Pearl S. Buck - Dragon Seed

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Steve McIntyre
On Thu, Feb 28, 2019 at 06:47:30PM +0200, Adrian Bunk wrote:
>On Thu, Feb 28, 2019 at 09:05:04AM +0000, Ian Campbell wrote:
>>
>> To spell it out: the gist of this is that it isn't possible to provide
>> a single arm binary which works well for both armel and armhf (which I
>> think is what Jeff is trying/wants to do?).
>
>It is not even possible to provide a single arm binary that runs on
>both armel and armhf.[1] It is a different ABI.

It's *technically* possible for binaries that don't ever pass FP
values as function arguments, but it's really not recommended and
you'd have to fight with the toolchain a lot to do it.

>> The advice here is to instead ship[0] two binaries -- one targetting v5
>> (no neon etc, aka armel in Debian) and another targetting v7 (w/
>> possible(? I forget what is optional) neon and other stuff aka armhf in
>> Debian and other distros).
>
>The main difference between armel and armhf is not the baseline
>(at some point Ubuntu had bumped the armel baseline to v7), the
>main difference is that there is no FPU in the armel baseline.
>Which also means that floating-point parameters must get passed
>in integer registers since there are no floating-point registers
>in the ABI.

Nod.

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
We don't need no education.
We don't need no thought control.

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

wookey-4
In reply to this post by Ian Campbell-5
On 2019-02-28 09:05 +0000, Ian Campbell wrote:
>
> To spell it out: the gist of this is that it isn't possible to provide
> a single arm binary which works well for both armel and armhf (which I
> think is what Jeff is trying/wants to do?).

Just to clarify: it's not possible to built a binary which works at
all on both armel and armhf. They are different ABIs ('architectures'
in Debian terminaology). Modulo things like qemu emulation or other
very carefully constructed binaries a binary is one ABI or the other,
working together with others on that basis. There are then separate
questions of what base ISA (instruction set) it is built to (v5, v7),
and to what degree it requires/supports optional features of the
hardware/ABI (neon, fpu, maverick etc).

> The advice here is to instead ship[0] two binaries -- one targetting v5
> (no neon etc, aka armel in Debian) and another targetting v7 (w/
> possible(? I forget what is optional) neon and other stuff aka armhf in
> Debian and other distros).

Right. And neon is optional on armhf. i.e software needs to work
without it (because it's not present on all v7 hardware), but should
also support it if it improves performance significantly for that
software.

Wookey
--
Principal hats:  Linaro, Debian, Wookware, ARM
http://wookware.org/

signature.asc (849 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Jeffrey Walton-3
On Thu, Feb 28, 2019 at 1:18 PM Wookey <[hidden email]> wrote:

>
> On 2019-02-28 09:05 +0000, Ian Campbell wrote:
> >
> > To spell it out: the gist of this is that it isn't possible to provide
> > a single arm binary which works well for both armel and armhf (which I
> > think is what Jeff is trying/wants to do?).
>
> Just to clarify: it's not possible to built a binary which works at
> all on both armel and armhf. They are different ABIs ('architectures'
> in Debian terminaology). Modulo things like qemu emulation or other
> very carefully constructed binaries a binary is one ABI or the other,
> working together with others on that basis. There are then separate
> questions of what base ISA (instruction set) it is built to (v5, v7),
> and to what degree it requires/supports optional features of the
> hardware/ABI (neon, fpu, maverick etc).

Forgive my ignorance...

Is it possible to support both at a project's ABI level in C/C++ by
avoiding floats and doubles in function signatures?

The reason I ask is, the library has a few (very few) functions like
this (as a simplified example):

    int AddEntropy(byte* data, size_t size, double estimate)
    {
        // Do something with the entropy
    }

I would be happy to change to something like:

    int AddEntropy(byte* data, size_t size, size_t num, size_t denom)
    {
        double estimate = num/ denom;
        ...
    }

But I need to ensure the compiler does not get clever and and do
something like hoist the calculation of estimate out of the function.

(I know OpenSSL also suffers this problem. They have a similar
function [1] but they don't specify -mfloat-abi. It may not be a
problem on Debian, but I believe it is a problem on Android where
CFLAGS should include a float ABI).

[1] https://www.openssl.org/docs/man1.0.2/man3/RAND_add.html

Jeff

Reply | Threaded
Open this post in threaded view
|

Re: Does ARMEL toolchain include NEON support?

Steve McIntyre
On Thu, Feb 28, 2019 at 01:36:33PM -0500, Jeffrey Walton wrote:

>On Thu, Feb 28, 2019 at 1:18 PM Wookey <[hidden email]> wrote:
>>
>> On 2019-02-28 09:05 +0000, Ian Campbell wrote:
>> >
>> > To spell it out: the gist of this is that it isn't possible to provide
>> > a single arm binary which works well for both armel and armhf (which I
>> > think is what Jeff is trying/wants to do?).
>>
>> Just to clarify: it's not possible to built a binary which works at
>> all on both armel and armhf. They are different ABIs ('architectures'
>> in Debian terminaology). Modulo things like qemu emulation or other
>> very carefully constructed binaries a binary is one ABI or the other,
>> working together with others on that basis. There are then separate
>> questions of what base ISA (instruction set) it is built to (v5, v7),
>> and to what degree it requires/supports optional features of the
>> hardware/ABI (neon, fpu, maverick etc).
>
>Forgive my ignorance...
>
>Is it possible to support both at a project's ABI level in C/C++ by
>avoiding floats and doubles in function signatures?

Basically, no. The toolchains are set up to explicitly set flags to
state which ABI a binary is targeting. It's not possible to say
"both".

--
Steve McIntyre, Cambridge, UK.                                [hidden email]
"This dress doesn't reverse." -- Alden Spiess