Re: Does ARMEL toolchain include NEON support?
On Thu, Feb 28, 2019 at 1:18 PM Wookey <wookey@wookware.org> 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 to: