On Nov 25, 2013, at 7:05 PM, Michael Gschwind <[email protected]> wrote: > On Wed Nov 20 05:33:31 UTC 2013, John McCall <rjmccall at apple.com> wrote : > | Credit the good folks at ARM for these two ideas. > > I am curious about the history here, because it seems that the AArch64 ARM > ABI appears to drop these changes? Does anybody have an explanation what > transpired to make ARM reconisder and go back to a more vanilla > "industry-standard ABI" (aka Itanium ABI)? > > Did it turn out that the improvements to be gotten (e.g., by shaving off a > few cycles for reloading this) just wasn't worth the cost of deviating from > the center of gravity for the C++ ABI that everybody else had, or can we > infer more substantial reasons? (I think there may still be a few testcase > fails for ARM32b due to different name mangling etc.) > > Also, the iOS ABI on 32b ARM seems to have stepped back from the full scope > of the ARM 32b ABI? Any thoughts what is pulling these ABIs back into the > mainline?
I believe you're over-interpreting the data. :) Compilers have been very slow to implement any of the changes from the ARM C++ ABI (except the mandatory change to member function pointers), essentially because (I believe) no major ARM-based platform has actually adopted ARM’s C++ ABI in full, essentially because compilers have been very slow to implement any of it. The point of this proposal is that, if a vendor is motivated enough to implement a better ABI when it’s bringing up the compiler for a new platform, it’d be good to have recommendations for what to do. And if those recommendations are actually out there and widely agreed upon, that becomes an inducement for compiler vendors to implement them, which of course makes it easier for any such new platforms to adopt them. John. _______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
