VFP11 Veneers (GCC ARM)

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
Reply to
Rob Gaddi
Loading thread data ...

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.


Reply to

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.