The AArch64/MacOS conventions are those of AArch64/iOS, a little known system that the author can be forgiven for not knowing about :-). I suspect the place where the overhead of calling variadic functions actually matters is in things like objc_msgSend which may well occur in computationally significant portions of code.
objc_msgSend() is not actually variadic. The old runtime defined it that way, but that created problems which led to us having to have special versions for returning structures or floating point (depending on architecture). The modern runtime explicitly requires that you cast the objc_msgSend() function pointer to the correct function type for the method you are invoking, which avoids that problem as well as the issue of the variadic calling convention being different.
You may be correct for the cases you have tried, but there are other cases where varadic and non-varadic functions are called differently on, I believe, a number of ISAs. For example on RISC-V all arguments to a varadic function are passed in integer registers, including floating point arguments.
@Bruce: Thanks, yes, floating point arguments are certainly another place where things could sanely be changed. In my specific context, I know that the arguments are all "void *" so that change wouldn't affect me, but you are clearly right. Thanks for taking the time to comment!
There's even a non-architecture specific example; arguments passed to a variadic function are subject to default argument promotion rules, whereas arguments whose types are declared are not.
This is why (for instance) you can use the "%f" format specifier in printf() with either float or double.
Excellent, thanks. I thought it should be possible, but failed to manage to find the necessary runes! I'll file them away so that I can do that next time I need to.
The AArch64/MacOS conventions are those of AArch64/iOS, a little known system that the author can be forgiven for not knowing about :-). I suspect the place where the overhead of calling variadic functions actually matters is in things like objc_msgSend which may well occur in computationally significant portions of code.
objc_msgSend() is not actually variadic. The old runtime defined it that way, but that created problems which led to us having to have special versions for returning structures or floating point (depending on architecture). The modern runtime explicitly requires that you cast the objc_msgSend() function pointer to the correct function type for the method you are invoking, which avoids that problem as well as the issue of the variadic calling convention being different.
You may be correct for the cases you have tried, but there are other cases where varadic and non-varadic functions are called differently on, I believe, a number of ISAs. For example on RISC-V all arguments to a varadic function are passed in integer registers, including floating point arguments.
https://godbolt.org/z/z5r5z8
@Bruce: Thanks, yes, floating point arguments are certainly another place where things could sanely be changed. In my specific context, I know that the arguments are all "void *" so that change wouldn't affect me, but you are clearly right. Thanks for taking the time to comment!
There's even a non-architecture specific example; arguments passed to a variadic function are subject to default argument promotion rules, whereas arguments whose types are declared are not.
This is why (for instance) you can use the "%f" format specifier in printf() with either float or double.
Clang can be told to compile for other targets, for example "-target arm64-apple-macosx" gives you this: https://godbolt.org/z/avGExz
Excellent, thanks. I thought it should be possible, but failed to manage to find the necessary runes! I'll file them away so that I can do that next time I need to.