chicken-hackers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Chicken-hackers] New dimensions in ABI design braindamage


From: felix . winkelmann
Subject: [Chicken-hackers] New dimensions in ABI design braindamage
Date: Wed, 08 Jul 2015 12:40:57 +0200

Hello!


We are currently investigating a problem with CHICKEN code compiled on ARM64
(iOS) and it seems that the way procedure-calls are compiled is entirely
incompatible with Apple's modifications of the ARM64 ABI. I'm not completely
sure, but judging from the Information found at [1] and [2], the type of
a called function must _exactly_ match the type known at the call-site,
including the fixed number of arguments in a variadic function, so calling
a function ptr of type

  typedef void (*C_proc4)(C_word, C_word, C_word, C_word, C_word)

that points to a function of (say) this type

  void myproc(C_word c, C_word k, C_word a1, ...)

will break, as the number of fixed args does not match. According to [2], fixed
args are always passed in registers with and varargs being passed on the stack.
If I understand the legalese in [1] correctly, then the prelude for a vararg
function should save all registers on the stack, but this doesn't seem to be
the case on iOS. See also [3].

CHICKEN-compiled code does this everywhere: optional args are processed as
varargs, to ensure that args known to be fixed can be placed in registers at
the call-site, but the call site can not know this (which is the whole point of
having first-class functions). Using "void (*PTR)(C_word c, ....)" everywhere
would be a serious performance degradation, IMHO, as _all_ compiled C functions
would have to use varargs to extract arguments, in addition to forcing all
arguments on the stack, not being able to utilise registers for argument
passing (with the exception of the first arg, the argument count).

Other options would be to pass arguments in global storage (no improvement over
using varargs everywhere) or rolling our own varargs, using assembly. 

I'm out of my wits. This is extremely stupid and breaks every attempt at
implementing generic function-pointers in C without paying a massive
performance penalty. But I will not rant, I will not rant, I will try very hard
not to rant...

Any ideas?


felix

[1] 
http://infocenter.arm.com/help/topic/com.arm.doc.ihi0055b/IHI0055B_aapcs64.pdf
[2] 
https://developer.apple.com/library/ios/documentation/Xcode/Conceptual/iPhoneOSABIReference/Articles/ARM64FunctionCallingConventions.html
[3] 
https://developer.apple.com/library/ios/documentation/General/Conceptual/CocoaTouch64BitGuide/ConvertingYourAppto64-Bit/ConvertingYourAppto64-Bit.html



reply via email to

[Prev in Thread] Current Thread [Next in Thread]