This many be a daft comment, but shouldn't high performance math be implemented via DSP or GPU hardware or some other co-pro on an embedded system?
Joel
On Tue, Jul 13, 2010 at 6:05 AM, Dave Martin dave.martin@linaro.org wrote:
On Tue, Jul 13, 2010 at 11:50 AM, Richard Earnshaw rearnsha@arm.com wrote:
On Mon, 2010-07-12 at 10:28 +0100, Dave Martin wrote:
- Use ABI tagging (high effort, involving modifications to affected
projects - permits hardvfp ABI for explicitly selected functions)
While this might sound attractive at first, I'm not sure it will fly.
Consider tagging all the functions in libm() to use hard float.
Firstly, many people 'know' that sinf()'s prototype is
float sinf (float);
and will declare it directly rather than including math.h. That's going to quietly break. Autoconf-like tools are notorious for making assumptions like this.
Possibly dumb questions:
Why would anyone (including autoconf) do this instead of including math.h? Is this for working around "broken" headers etc.? Do you know how common this is?
Secondly, if I understand what you're suggesting, I think this just makes the world more fragmented rather than less. A library that exports
float __attribute__((pcs("aapcs-vfp"))) sinf(float)
can't be replaced by a library that exports
float __attribute__((pcs("aapcs"))) sinf(float)
because the caller must know which PCS convention is used at compile time.
Indeed - see my post of 0925 UTC. This falls under (b), which looks challenging to manage, though I didn't discuss the knock-on issues with headers and function prototypes there.
However, just tagging internal functions sounds like it could bring some benefits and is more feasible (a) - can you see any problems with that?
Cheers ---Dave
linaro-dev mailing list linaro-dev@lists.linaro.org http://lists.linaro.org/mailman/listinfo/linaro-dev