原文： https://mikeash.com/pyblog/objc_msgsends-new-prototype.html
总结 ：
objc_msgSend 类型申明改变的原因： 让错误在编译的时候发生，而不是等到运行时。
为什么有 运行时错误 ： ABI 的错配，调用方的ABI （对参数的传递） 和 接收方ABI（ 对参数的处理）错配了
为什么 错配： 我传的是float ，你把我当double 了，浮点 转成 双精度浮点，这可不是和short 转 int 单单高位补几个0就可以了
为什么float 转 double 了： C 语言 经常搞这种骚操作，毕竟处理数据的时候，用更高的精度有好处。
怎么阻止 float 转 double ： 可以把函数中的参数类型申明成float ，而不是模棱两可
等等函数参数 怎么会模棱两可： C 语言 变参函数了解一下 ，也就是void functionA(int a,int b, ...) 这种点点点函数，不幸原来的objc_msgSend 就是长这个样子的
翻译笔记：
objc_msgSend 变了
objc_msgSend 和 objc_msgSendSuper 的类型申明改了，那他们实际上接受什么参数，以及它实际上返回什么？
objc_msgSend 不得不用汇编
objc_msgSend 是用汇编实现的，不只是为了快，只用 C 是实现不了objc_msgSend的功能是的（pencilCool: 因为不能去扰乱传参的寄存器呀 ）
objc_msgSend 做的基础工作
objc_msgSend的fast path 做了几件关键的事情：
- 加载对象的类
- 在该类的方法缓存中查找selector 。
- 跳转到在缓存中找到的方法实现。
objc_msgSend 不干扰函数传参的寄存器
因为objc_msgSend直接跳到了方法实现，而没有进行函数调用，所以一旦它的工作完成，它就有效地消失了。
这个实现很谨慎，没有干扰任何可以用来向函数传递参数的寄存器。
调用者在调用objc_msgSend时，就像直接调用方法实现一样，以同样的方式传递所有的参数。
一旦objc_msgSend查找到实现并跳转到它，这些参数仍然是实现所期望的位置。当实现返回时，它直接返回给调用者，而返回值是由标准机制提供的。
这就回答了上面的问题：objc_msgSend的原型是它最终调用的方法实现的原型。
旧的原型在某些情况下可以工作（当ABI匹配时），而在其他情况下却奇怪地失败（当ABI不匹配时）。
新的原型永远不会工作，除非你先把它投到适当的类型。只要你把它投到正确的类型上，它就总是能工作。因此，新的做事方式鼓励正确做事，并使做错事变得更难。
最小的原型
尽管objc_msgSend的原型取决于将被调用的方法实现，但有两件事在所有的方法实现中是共同的：第一个参数总是id self，第二个参数总是SEL _cmd。objc_msgSend需要这两个信息来执行它的方法调度工作，所以它们必须总是在同一个地方，以便它能够找到它们。
我们可以为objc_msgSend写一个近似的泛化原型来表示这一点。
objc_msgSend(id self, SEL _cmd, ???)
其中，??的意思是我们不知道，它取决于将被调用的特定方法实现。当然，C语言没有办法表示这样的通配符。
对于返回值，我们可以尝试挑选一些常见的东西。因为Objective-C是关于对象的，所以假设返回值是id是有意义的。
id objc_msgSend(id self, SEL _cmd, ???)
这不仅涵盖了返回值是一个对象的情况，也涵盖了返回值是无效的情况，以及其他一些返回值是不同类型但没有被使用的情况。
那么参数呢？C语言实际上有一种方法来表示任意类型的任意数量的参数，其形式是可变参数函数原型。在参数列表的末尾有一个省略号，意味着后面有一个任意类型的可变数量的值。
id objc_msgSend(id self, SEL _cmd, ...)
这正是最近改变之前的原型。
ABI错配
运行时的相关问题是调用地点的ABI是否与方法实现的ABI匹配。也就是说，接收者是否会从相同的位置，以调用者传递的相同格式检索参数？如果调用者将一个参数放入 $rdx，那么实现者就需要从 $rdx中获取该参数，否则就会出现混乱。
最小的原型可能能够表达传递任意数量的任意类型的概念，但是为了让它在运行时真正发挥作用，它需要使用与方法实现相同的ABI。该实现几乎肯定使用了不同的原型，并且通常有固定数量的参数。
不能保证一个变量函数的ABI与一个有固定参数数的函数的ABI相匹配。在一些平台上，它们几乎完全匹配。在其他平台上，它们完全不匹配。
英特尔ABI
让我们看一个具体的例子。macOS使用x86-64的标准System V ABI。ABI中有大量的细节，但我们将专注于基础知识。
参数是在寄存器中传递的。整数参数在寄存器rdi、rsi、rdx、rcx、r8和r9中传递，按顺序排列。浮点参数在SSE寄存器xmm0到xmm7中传递。当调用一个变量函数时，寄存器 al 被设置为用于传递参数的SSE寄存器的数量。整数返回值被放在rax和rdx中，浮点返回值被放在xmm0和xmm1中。
变参函数的ABI几乎与普通函数的ABI相同。唯一的例外是传递al中使用的SSE寄存器的数量。然而，当使用变参函数 ABI调用普通函数时，这一点是无害的，因为普通函数会忽略al的内容。
C语言把事情搞得有点乱。C语言规定，当作为变量参数传递时，某些类型会被提升为更广泛的类型。小于int的整数（如char和short）被提升为int，而float被提升为double。如果你的方法签名中包括这些类型之一，那么如果调用者使用变量原型，就不可能将参数传递为该确切的类型。
对于整数来说，这实际上并不重要。整数被存储在相应的寄存器的底层位，无论哪种方式，其位数最终都在同一个地方。然而，这对浮点数来说是灾难性的。将一个较小的整数转换为int只需要用额外的位来填充它。将float转换为double涉及到将数值完全转换为一个不同的结构。float中的位与double中的相应位并不一致。如果你试图使用一个变量原型来调用一个接受浮动参数的非变量函数，该函数将收到垃圾。
To illustrate this problem, here's a quick example:
// Use the old variadic prototype for objc_msgSend.
#define OBJC_OLD_DISPATCH_PROTOTYPES 1
#import <Foundation/Foundation.h>
#import <objc/message.h>
@interface Foo : NSObject @end
@implementation Foo
- (void)log: (float)x {
printf("%f\n", x);
}
@end
int main(int argc, char **argv) {
id obj = [Foo new];
[obj log: (float)M_PI];
objc_msgSend(obj, @selector(log:), (float)M_PI);
}
It produces this output:
3.141593
3370280550400.000000
正如你所看到的，当写成消息发送时，这个值是正确的，但是当通过显式调用objc_msgSend时，这个值被完全扭曲了。
这个问题可以通过转换objc_msgSend的签名来解决。回顾一下，objc_msgSend的实际原型是最终将被调用的方法的原型，所以使用它的正确方法是将其转换为相应的函数指针类型。这个调用可以正常工作。
((void (*)(id, SEL, float))objc_msgSend)(obj, @selector(log:), M_PI);
ARM64 ABI
让我们看看另一个相关的例子。iOS使用了ARM64的标准ABI的一个变体。
整数参数在寄存器x0到x7中传递。浮点参数在v0到v7中传递。 其他参数在堆栈中传递。返回值被放置在作为参数传递的同一个或多个寄存器中。
这只适用于普通参数。变量参数从不在寄存器中传递。它们总是在堆栈中传递，即使是在有参数寄存器的情况下。
没有必要仔细分析这在实践中是如何实现的。ABI是完全不匹配的，一个方法在被调用的时候，如果没有cast objc_msgSend，那么它的参数中就会收到垃圾。
新的原型
新的原型简短而贴心。
void objc_msgSend(void)。
这一点都不正确。然而，旧的原型也不正确。这个原型的错误更明显，这是件好事。旧的原型使你可以很容易地使用它而不去铸造它，并且经常工作，以至于你很容易就会认为一切都很好。当你遇到有问题的情况时，这些错误就非常不清楚了。
这个原型甚至不允许你传递self和_cmd这两个必要参数。你可以在完全没有参数的情况下调用它，但它会立即崩溃，这应该是很明显的出错原因。如果你试图使用它而不进行转换，编译器会抱怨，这比奇怪的破参数值要好得多。
因为它仍然有一个函数类型，你仍然可以把它投到一个适当类型的函数指针上，然后用这种方式调用它。只要你把类型弄对了，这就能正确工作。