On Jan 14, 2013, at 5:21 AM, Tim Northover <[email protected]> wrote: >> It seems to be the case that aarch64's ABI is just the ARM32 ABI except >> that ABI guards are 64-bit. A cleaner way of expressing this would be to >> say that aarch64 uses the ARM ABI, and that the ARM ABI says that ABI >> guards are size_t's. Are you expecting further divergences? > > It would be a simpler change and we're certainly not anticipating any > more differences on the AArch64 side. This was actually an attempt to > improve existing code; I didn't like "IsARM" covering multiple > different company-specific traits that other targets might want to > change.
I agree that the IsARM bit is ugly, but I prefer not to increase abstraction without a real understanding of what the expected variation is going to be. It would be better to use methods instead of extra bools, anyway. >> Can I kibbitz about your ABI here, or is it too late and you've actually >> committed to it? > > I'm afraid it is too late for changes now, barring complete breakage > being discovered. The specification is published and implemented by at > least two separate compilers (GCC and ARMCC). Okay, just idly curious. >> I will note that your va_arg code is *huge*. > > It's a similar size to the x86_64 code. I suspect the complexity is > inevitable to manage the possibility of arguments going in either > general registers, floating registers or on the stack independently. > > AAPCS gets around it by requiring soft-float for variadic functions so > that a single pointer suffices in va_list. Yeah, in principle it's obviously best to always pass variadic arguments on the stack. I can sympathize with ABI authors who are afraid of the K&R legacy, though. John. _______________________________________________ cfe-commits mailing list [email protected] http://lists.cs.uiuc.edu/mailman/listinfo/cfe-commits
