VFP11 Veneers (GCC ARM)

Sep 19, 2011 1 Replies

Hey y'all --



I was just looking through the disassembly of a project I'm working on around an ARM9 (NXP LPC3250) under the Code Red packaged GCC, and I noticed that all of the floating point code is surrounded by a mess of absolute branches to routines called __vfp11_veneer_N, for various values of N. Each of those routines is nothing but a single floating-point operation, followed by an absolute branch to a return point __vfp11_veneer_N_r, which is always the instruction immediately after the branch. For example:



/* Way up here */


8002978: eeb87a67 vcvt.f32.u32 s14, s15 800297c: eddf7a2d vldr s15, [pc, #180] 8002980: ea0008eb b 8004d34


08002984 : 8002984: eddf7a2c vldr s15, [pc, #176]



/* And way down there */


08004d34 : 8004d34: ee277a27 vmul.f32 s14, s14, s15 8004d38: eafff711 b 8002984

Anyone know what's going on in all of this, why the creation of all these veneer functions, and how I can convince GCC to do otherwise? It almost defeats the purpose of having hardware floating point support if you keep crashing the pipeline to jump to and fro single instruction veneers most (but not all) times you use them.



Thanks, Rob


Rob Gaddi, Highland Technology Email address is currently out of order

The point of the veneers is that by linking with the appropriate library floating point can be performed in hardware or by user-space emulation. Using the -mfloat-abi=softfp generates code that uses floating point directly, but is still ABI-compatible. -mfloat-abi=hard/-mhard-float uses a more efficient but incompatible ABI.

-a

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required