WinCE 和 Linux 上的 ARM 调用约定？
WinCE 和 Linux 在 ARM 上使用相同的调用约定吗？有什么区别？
到目前为止我找到的文档并没有很好地解释。例如 http://msdn.microsoft.com/en-us/library /ms864497.aspx，一行写着“Windows CE .NET Compiler”，下一行写着“ARM编译器”，最后一行写着“CLARM”，不清楚是否指的是相同的编译器或不同的编译器。这是我到目前为止发现的...
- ARM 调用序列规范 (WinCE) - 文档写得不好
- ARM 到 C 的调用约定 (Linux) - 非正式解释
- Wikipedia - 没有指定操作系统，也没有指定操作系统说明了如何处理结构、浮点或 64 位数字，并且没有说明额外的参数放置在哪里，以防它们不适合寄存器。
- 更新：ARM 架构的过程调用标准 - 最后我找到了一份综合文档，但它没有说明哪些操作系统遵循该标准（或者这些操作系统可能施加哪些变体或附加限制）。
我问的原因是我想尝试在WinCE中使用LLVM在运行时生成一些简单的代码，但它只正式支持Linux。
Do WinCE and Linux use the same calling convention on ARM? What are the differences?
The documents I've found so far do not explain very well. For example on http://msdn.microsoft.com/en-us/library/ms864497.aspx, it says "Windows CE .NET Compiler" on one line, but "the ARM compiler" on the next line, and "CLARM" at the bottom, and it's not clear whether it is referring to the same compiler or different compilers. Here's what I've found so far...
- ARM Calling Sequence Specification (WinCE) - poorly-written documentation
- ARM to C calling convention (Linux) - informal explanation
- Wikipedia - no OS is specified and it does not say how structures, floating-point or 64-bit numbers are handled, and it does not say where extra arguments are placed in case they do not fit in registers.
- Update: Procedure Call Standard for the ARM Architecture - finally I found a comprehensive document, but it doesn't say which operating systems follow the standard (or what variants or additional constraints those OSs might impose).
The reason I ask is that I'd like to try using LLVM in WinCE to generate some simple code at run-time, but it only officially supports Linux.
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
调用约定是由编译器实现的，与操作系统无关。话虽如此，我可以确认 gcc 和 RVCT（ARM 的 c/c++ 编译器）都生成遵循您上面提到的 ARM 体系结构的过程调用约定的代码。
查看 Microsoft 文档的链接，我还可以确认它遵循 ARM 调用约定。
Calling conventions are something that are implemented by the compiler and are not operating system specific. Having said that I can confirm that both gcc and RVCT (ARM's c/c++ compiler) both generate code that follow the Procedure call convention for ARM architecture that you mentioned above.
Looking at the link to the Microsoft documentation, I can also confirm that it follows the ARM calling convention.
我遇到了完全相同的问题并试图找到答案。即哪里/什么文件说了些什么或定义了 LINUX 下使用的 ARM ABI。
以下文档是我最接近答案的
ARM GNU/Linux Application Binary Interface Supplement，它由 CodeSourcery 提供，其摘要中的编码在我看来是上述问题的答案，即：
ARM 架构的应用程序二进制接口 (ABI)（由 ARM Ltd 发布的文档）指定了用于 ARM 架构的工具链之间互操作所需的编译和链接的各个方面。然而，由于本文档中发布的 ABI 是在不参考特定操作系统的情况下设计的，因此某些方面仍未指定。
显然，CodeSourcery 的文档旨在通过指定使用 GNU/Linux 操作系统时针对这些方面所做的决策来补充 ARM 架构的 ABI。
我提供了该文档的一个链接（可以通过搜索文档标题找到其他链接）：
http://www.boost.org/doc/libs/1_51_0_beta1/libs/context/doc/pdf/arm-linux-aapcs.pdf
看来LINUX 下指定 ARM ABI 的标准并不存在，CodeSourcery 的文档似乎又试图涵盖这方面。
I came across the exact same question for which I tried to find an answer. Namely where / what document says something or defines the ARM ABI used under LINUX.
The following document is the closest I came to an answer
ARM GNU/Linux Application Binary Interface Supplementit is by CodeSourcery and in encoded in its abstract lies in my opinion an answer to the question above, namely that:
The
Application Binary Interface (ABI) for the ARM Architecture( a document published by ARM Ltd ) specifies various aspects of compilation and linkage required for interoperation between toolchains used for the ARM Architecture.However, as the ABI published in this document is designed without reference to a particular operating system, there are certain aspects which remain unspecified.
Apparently the document by CodeSourcery, is intended to supplement the ABI for the ARM Architecture by specifying the decisions made for these aspects when using the GNU/Linux operating system.
I supply one link to this document ( others could be found by searching for the document's title ):
http://www.boost.org/doc/libs/1_51_0_beta1/libs/context/doc/pdf/arm-linux-aapcs.pdf
It seems that a standard specifying the ARM ABI under LINUX didn't exist, and again it seems that the document by CodeSourcery is an attempt at covering this aspect.