bios - 为什么我们需要 AML - ACPI 机器语言？

Question

据我了解，ACPI 定义了一个通用硬件编程模型，其中操作系统依赖 OEM 固件提供的 AML(ACPI 机器语言)代码来操作硬件。

为了执行 AML 代码，操作系统必须包含一个 AML 解释器。

因此，在我看来，固件开发人员使用 AML 来提供平台硬件和操作系统之间的控制接口(interface)。

但我们真的需要 AML 吗？

我认为 最终硬件可以仅限 通过 进行配置原生 平台的指令。因此 AML 解释器必须将 AML 翻译成 native 指令，否则无法在平台上执行。

但是使用 有什么意义？中级语言 像反洗钱？我的意思是虽然 AML 被认为是独立于平台的，这意味着我可以使用 AML 以非本地方式描述我的平台。

但 AML 实际上是平台固件的一部分。并且整个固件已经内置到目标平台的 native 指令中。 那么让固件的一小部分独立于平台有什么好处呢？ 为什么不只使用 native 指令？有必须以某种方式让操作系统也使用它。这样操作系统就根本不需要 AML 解释器。可以避免很多复杂性。

Answer 1

ACPI 与其前身 APM 相比的一大目标是赋予操作系统更多的生存能力和对电源状态转换的控制。

APM 是一个黑匣子。操作系统对电源管理实现一无所知。它只会调用 BIOS 函数，而 BIOS 会处理所有的魔法。它奏效了吗？系统是否正常 sleep ？系统卡住了吗？用户应用程序是否能够处理 BIOS 实现？可悲的事实是，许多系统的电源管理完全被破坏了，微软希望为不断发展的笔记本电脑行业提供更好的电源管理体验。

现在，BIOS 将 ASL/AML 代码交给操作系统和 操作系统执行它而不是 BIOS .如果 BIOS 代码做了一些愚蠢的事情(比如弄乱不应该的寄存器)，Windows 可以通过解析代码来检测并阻止它。与 C 不同，AML 是 100% 可反编译的。

请记住，ACPI 不是 x86 特定的。在它被开发的时候，Itanium 和 Xscale 就在身边。英特尔和微软需要一种可以在所有平台上运行的语言，包括 32 位和 64 位。

最后，ASL 不仅仅是可执行函数的列表。它也是静态配置表的数量。 ASL 代码有表格来定义内置在主板上的非 PnP 硬件。它有支持的电源状态表。像 C 这样的传统编程语言并没有真正为此设置。

如果今天发明了 ACPI，他们可能会使用 XML 之类的东西向操作系统提供信息。