[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [MiNT] GCC return register
Miro Kropáček wrote:
Background behind this is that solution #2 hides inefficient intermixing
totally.
The question is:
Do we want to allow intermixing 68000 and 68020-60 libraries or not ?
Personally, I don't.
But I agree, some binary libraries are not available for m68020-60.
Anyway, they should be recompiled. An executable partially optimized for
a specific CPU makes me sick.
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?
To be compatible with equivalent code without FPU.
To allow mixing FPU and non-FPU code.
More generally, remember that GCC appeared as an alternative to
proprietary UNIX compilers. The important thing was ABI (Application
Binary Interface) compatibility with existing tools and libraries for a
given platform. This is why its behavior varies and can be configured.
So the question is:
How traditional Atari compilers return pointers and floats ?
If I'm not wrong, AHCC (and maybe Pure C ?) returns pointers to a0.
What about floats ?
And what about vbcc ?
Another consideration is GCC for ColdFire. The GCC team (?) has chosen
to always return floats to d0, even if the FPU and fp0 is available on
new models.
And another point: in the real world, no manually written assembler
routine will return floats. float manipulation is usually done in C.
With one exception, the libm implementation, for only a few very
specific functions written in assembler.
So there are very few chances that the register used to return floats
will affect any assembler programmer.
--
Vincent Rivière