Notes on mixing D16/D32 code

[Michael Hope]

On Fri, Nov 26, 2010 at 12:00 AM, Dave Martin <dave.martin at linaro.org> wrote:
> Hi,
>
> 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 5.1.2.1
> "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
> variants
>  * 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.

-- Michael