David Edelsohn wrote:
Mark Mitchell writes:
Mark> However, if I understand correct, some users have probably been
Mark> implicitly using those options because they were using "-mcpu=970", or
Mark> otherwise specifying an AltiVec CPU. It seems desirable in the abstract
Mark> that this code still be binary-compatible with new -mcpu=970 code, if it
Mark> was "plain C" code not using AltiVec vectors explicitly. But, I don't
Mark> know if that's technically feasible or not.
The problem is that "plain C" code can generate Altivec
instructions in multiple ways.
I was afraid of that.
The Altivec ABI does change the stack alignment. This should not
create an incompatibility for old code, but new code may not receive the
stack properly aligned without additional dynamic alignment. The other
issue is argument passing for GCC generic vectors, mentioned by Janis, but
that feature is documented to have "unexpected behavior" and few people
use it.
So, if we wanted to make this interoperate better, we'd have to
introduce dynamic stack alignment in every externally visible function,
thereby penalizing the average user who isn't trying to support linking
with legacy code. Right?
I suppose that another solution would be to have the linker generate
stubs. Let the new code just use the standard ABI, but mark the
functions in some way to that the linker could generate stubs for calls
from legacy code. The stubs would align the stack and then call the
real function. That would avoid penalizing the new code, but still
preserve compatibility.
If you think that's a good idea, though, that doesn't stand in the way
of the plan you and Janis have presented -- it's a follow-on idea that
could be implemented if there's enough demand. That's good.
Thanks,
--
Mark Mitchell
CodeSourcery
[EMAIL PROTECTED]
(650) 331-3385 x713
