打破ABI召集约定的后果是什么？
我正在做一些编译器编写的项目，我想确保我正确理解ABI和通话征用。
假设我正在为某些高级语言 l 编写编译器，它针对某些系统 s 。
如果我正确理解事情，只要我生成了称为其他 l 方法的指令，我就可以使用我想要的任何呼叫约定。我唯一必须遵循 s 的ABI指定的标准呼叫惯例是，每当我想进行系统调用或调用遵守ABI呼叫约定的外国功能时。
这理解是正确的吗？此外，除了与外国功能的明显兼容性外，语言运行时具有不同的内部呼叫惯例的负面后果吗？
I'm doing some compiler-writing projects and I want to make sure I'm understanding ABI and calling-conventions correctly.
Say I'm writing a compiler for some high-level language L, and it's targeting some system S.
If I'm understanding things correctly, as long as I'm generating instructions for L methods that are calling other L methods, I can use whatever calling conventions I want. The only time I'd have to follow the standard calling conventions specified by S's ABI is whenever I want to make a system call or call a foreign function that adheres to the ABI's calling convention.
Is this understanding correct? And furthermore, are there any negative consequences of a language runtime having a different internal calling convention besides the obvious compatibility with foreign functions?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（1）
如果是您的语言，则可以在硬件和操作系统的约束中使用您内部喜欢的任何呼叫约定（请参阅
但是：
如果要调用外国功能，则还需要实施他们的呼叫约定（如果需要的话，请命名）。
如果您希望外国功能能够调用您的功能（包括使用ASA顶级功能的任何内容），则需要实现他们期望您做的事情。因此，您可能需要诸如C ++'s
extern之类的东西”＆lt; language＆gt;“语法来标记外国可容纳。系统电话通常有自己的呼叫程序；通常，这涉及使用特殊用途的操作码，该操作码会增加中断。标准库通常包含用于系统调用的包装器，但是如果您有一些语法用于声明函数的呼叫约定，则可以将其用于系统调用，尽管这将限制可移植性。
但是，这都不是反对创建自己的ABI的论点。实际上，您的语言设计可能取决于没有自定义ABI（例外，coroutines，coroutines，划界连续性，生成器，异步程序等）的功能。
If it's your language, you can use whatever calling convention you like internally, within the constraints of the hardware and operating system (see @RaymondChen's comment for examples). You don't even have to be consistent if you know you can see all the call sites of a function.
But:
If you want to call foreign functions, you need to also implement their calling conventions (and name mangling, if required).
If you want foreign functions to be able to call your functions (including whatever you use asa top-level function), you need to implement do what they expect you to do. So you'll probably need something like C++'s
extern "<language>"syntax to mark foreign-callables.System calls usually have their own calling procedure; typically, this involves using a special-purpose opcode which raises an interrupt. Standard libraries usually include wrappers for system calls, but if you have some syntax for declaring the calling convention of a function, you could use that for system calls as well, although it would limit portability.
But none of that is an argument against creating your own ABI. Indeed, your language design might depend on features which cannot be efficiently implemented without a custom ABI (exceptions, coroutines, delimited continuations, generators, async procedures, etc., etc.).