[cxx-abi-dev] C++ ABI version 2

[Michael Gschwind]

John McCall <rjmccall at apple.com> wrote on 11/29/2013 02:28:50 AM:
On Nov 25, 2013, at 7:05 PM, Michael Gschwind <mkg at us.ibm.com> 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). 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://sourcerytools.com/pipermail/cxx-abi-dev/attachments/20131129/770eb600/attachment-0001.html>