�
Personally, I vote for solution 2. It requires fewer changes, and is safer. We could always change the method later if we have the proof it is significantly faster, and we are ready to face the drawbacks.
I agree with you, solution 2 is safe but it leaves some bitter taste :) I was thinking about solution #3:
- behavior is unchanged (d0 for non-FPU, fp0 for FPU), rest as with solution #1
- but, we change one annoying thing, discussed here in the past and with no final decision taken: we wont allow (ever) mixing libraries in gcc, i.e. gcc -m68020-60 *never* searches in other place than <prefix>/lib/m68020-60
Background behind this is that solution #2 hides inefficient intermixing totally. With #1 it's pretty good chance my FPU code will show me nonsense and I realize "damn it, wrong linking" and use / recompile good libs. With solution #3 you've got clear error about missing math/whatever library. But it's true it wont fix a situation with missing declarations (i.e. d0 will be used) but I'd say that's programmer's fault, one should never ignore warnings like that.
Second thing is, asm code intermixing is nonsense. We've got FPU asm code and we return a value into d0 instead of fp0. Why on earth would be this useful? I'm compiling non-FPU application so I must not use *any* FPU code, not only for return value! So not the asm code is here in play but wrong linking (you compile some math-like library for 68000 and link it with -m68020-60 app). And this is cured by what? Right, explicit linking, i.e. solution #3.
P.S. Yes I realize my previous attitude was "let's use d0 in all cases" but this only proves one should never make a decision without deep thinking ;-)