为什么Delphi编译器不内联汇编函数？

Question

有时我会编写非常短的汇编函数，例如：

function SeniorBit(Value: LongWord): Integer;
asm
        OR    EAX,EAX
        JZ    @@Done
        BSR   EAX,EAX
        INC   EAX
@@Done:
end;

似乎最适合内联的候选项是：

function SeniorBit(Value: LongWord): Integer; inline;

但是Delphi编译器不允许它。为什么？

---

更新：

感谢ldsandon，现在有一个5.5年历史的开放式QC报告。该报告提出了一些建议（如扩展asm指令），以简化编译器中的asm内联。我更喜欢在过程/函数级别引入“裸”指令，告诉编译器它不必为过程创建堆栈帧，并且可选地保留哪些寄存器（eax、edx和ecx中的哪些）。

如果高效内联BASM代码的总体任务很难（甚至可能不必要），一个好主意是为最重要的情况（如明确声明寄存器使用的裸函数）启用内联。

- kludg

---

如果您想讨论编译器未来可能支持内联汇编函数的可能性，也许QC或留言板是最好的地方。我试图回答目前确实无法使用带有asm块的函数进行内联的问题。您可能认为这是一个好主意（嘿，我喜欢汇编语言，认为这很好）。但是，SO是讨论编译器功能请求的地方吗？我想您想要关于手头问题的答案：为什么我不能内联此函数。 - Ritsaert Hornstra

@Serg：从常见问题解答中可以看出：“避免提出主观性强、易引发争议或需要深入讨论的问题。这里不是讨论区，而是提供可回答问题的地方！” 如果你想要讨论这个问题，你应该在提问中说明。如果我在挑刺，我很抱歉，但我尽力回答了你的问题，而不是试图讨论未来的事情。现在结束！ - Ritsaert Hornstra

@Serg：因为SO对编译器的未来没有任何输入或影响。负责此事的人（Embarcadero）已经建立了Quality Central作为报告问题或请求新功能或增强的地方。在他们可以看到您的评论的地方发布是合乎逻辑（和适当）的地方，而不是在这里，他们可能会决定停留一段时间。 - Ken White

@Serg：仅因为有人报告了问题并不意味着它会得到修复（或应该修复）。也许BORL认为这个问题只对少数人很重要（你似乎是其中之一<g>），所以不值得花费精力，或者更改需要大量时间，而这些时间可以用在更重要的事情上。但这并不重要。重要的是，在这里期望获得EMBT员工看到您的投诉而不是他们自己办公室更好的运气，这只是不明智的。这就像你的妻子在你妈妈的语音邮件留言给你，而不是你自己的手机。哪个会更快地联系到你？ - Ken White

我不希望EBMT会实现这个。他们甚至倾向于完全放弃汇编语言（他们没有x64汇编例程）。 - Fr0sT

Answer 1

请查看Quality Central报告＃9283（并为其投票）。基本上问题在于编译器应该能够理解内联代码之前要保留哪些寄存器以及之后要恢复哪些寄存器。只要编译器处理寄存器，就很容易，当使用不在其控制范围内时，就不是这样了。 您的示例非常简单，但编译器必须能够处理更复杂的情况。该报告处于开放状态，希望新的编译器也能够内联BASM代码。

- user160694

Answer 2

您无法内联手工编写的汇编代码。

允许内联这些汇编片段将非常困难；使用普通的内联方式会产生各种影响，包括寄存器使用、本地变量等，编译器无法处理内联汇编中的这些问题。

- Ritsaert Hornstra

---

我看不出内联上述汇编函数有任何问题。实际上，它看起来比内联一个纯Pascal函数还要简单。 - kludg

如果您认为这很简单，EMbarcadero应该聘请您作为他们的新编译器专家 :-). 不开玩笑：这很困难。编译器执行不同的阶段（虽然我不知道Delphi编译器的内部情况）文本（词法分析）标记（语法分析）语法树（优化）语法树->……->（代码生成）机器代码。现在，一段内联汇编非常难以在优化阶段分析，因为您需要使用某些抽象语法树。 - Ritsaert Hornstra

我不明白为什么？这只是一个简单的从前往后的线性扫描，以查找已分配/修改的寄存器。一些启发式方法（如如果使用BP，则设置堆栈帧）。请注意，如果检测到奇怪的结构（如寻址%esp），则可以禁用内联。拥有基础工作已经非常好了。 - Marco van de Voort

@MarcovandeVoort，所以“FreePascal”可以做到这一点？ - John Lewis

不行。虽然可能并不“非常困难”，但这并不意味着它是经济的，因为它仅适用于不使用堆栈框架等的片段。对于FPC或Delphi来说也是如此。 - Marco van de Voort