John McCall <[email protected]> wrote on 11/29/2013 02:28:50 AM: 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.
I understand the point you're making, but in the specific example, Apple was the one bringing up a new platform (which is exactly the opportunity point you're referencing) and chose not to do what you describe. And, as a kicker, ARM then basically went back on the platform recommendations they had for the 32b ABI when the spec'ed a new ABI for 64b. To phrase the question differently, when that platform vendor is to spec a new ABI (like Apple did), are the benefits of the proposed changes sufficient to motivate changes in what is (mostly) a machine-independent part of a compiler, that then has to be maintained separately, and can cause all sorts of distinct maintenance work? At what point does a platform vendor like Apple decide to walk down a trodden path - as per precedent - and how high has the payoff to be to forge a new path? The Itanium C++ ABI changes rose to a level of changeworthiness in the eyes of many and hence was widely implemented and adopted. ARM's proposed improvements, though arguably nice, shave off a small number of cycles of what is otherwise a comparatively larger cost, and it seems that when making a cost/benefit analysis both Apple for iOS and ARM for AArch64 chose to forgo those changes, possibly based on enablement cost vs. expected benefits, as you're pointing out (implicitly).
_______________________________________________ cxx-abi-dev mailing list [email protected] http://sourcerytools.com/cgi-bin/mailman/listinfo/cxx-abi-dev
