Notes on mixing D16/D32 code
michael.hope at linaro.org
Thu Nov 25 22:15:03 UTC 2010
On Fri, Nov 26, 2010 at 12:00 AM, Dave Martin <dave.martin at linaro.org> wrote:
> On Wed, Nov 24, 2010 at 9:49 PM, Michael Hope <michael.hope at linaro.org> wrote:
>> It's a bit of a newbie question, but I've been wondering if you can
>> intermix hard float VFPv3-D16 code with VFPv3-D32 code. You can as:
>> According to the ABI:
>> * d0-d15 are used for floating point parameters, no matter if you are
>> D16 or D32
>> * d0-d15 are not preserved across function calls
>> * d16-d31 must be preserved across function calls
> No, I don't think that's correct - see the procedure call standard
> section 184.108.40.206
> "VFP register usage conventions (VFP v2, v3 and the Advanced SIMD Extension)"
> It's not too hard to misread ... my understanding is as follows---
> * d0-d7 (s0-s15; q0-q3) are not callee-saved and are the only regs
> used for parameter and return value exchange in the standard ABI
> * d8-d15 (s16-s31; q4-q7) are _callee-saved_
> * d16-d31 (q8-q15) are _not callee-saved_
Ah, I got the s* and d* registers mixed up. So if you have a function
which takes doubles, the first eight parameters go in registers. If
the function takes floats, then the first sixteen go in registers.
D8-D15 are preserved across calls, D16+ aren't.
> So basically, D32 code just gets to use d16-d31 for extra scratchpad
> bandwidth _in between_ external function call sites. (Of course,
> compiler-generated or hand-written code can relax the rules locally in
> some circumstances, just as for the integer ABI)
I think the conclusion is the same: you can intermix VFP-D16 and
VFP-D32 code as D16 code doesn't use D16-D31 and D32 code doesn't
expect D16-D31 to be preserved across function calls.
More information about the linaro-toolchain