为什么我们需要 AML - ACPI 机器语言？
Why do we need AML - ACPI Machine Language?
据我所知，ACPI 定义了一个通用的硬件编程模型，其中操作系统依赖于 OEM 固件提供的 AML（ACPI 机器语言）代码来操作硬件。
为了执行 AML 代码，操作系统必须包含 AML 解释器。
所以，在我看来，固件开发人员使用 AML 来提供平台硬件和操作系统之间的控制接口。
但我们真的需要反洗钱吗？
我认为最终硬件可以只通过平台的native指令配置。所以AML解释器必须将AML翻译成原生指令否则不能在平台上执行。
但是使用像 AML 这样的中间语言有什么意义呢？我的意思是，尽管据说 AML 是 平台无关的 ，这意味着我可以使用 AML 以 非本机 的方式描述我的平台。
但实际上AML是平台固件的一部分。并且整个固件已经内置到目标平台的本机指令中。 那么让固件的这么一小部分与平台无关有什么好处呢？ 为什么不直接使用本机指令呢？ 必须 有某种方式让 OS 也能使用它。而且这种方式操作系统根本不需要 AML 解释器。可以避免很多复杂性。
最初，“80x86 PC”的硬件是从 IBM 的 PC 克隆而来的，这为硬件创建了一个有效的事实标准。然而，没过多久，制造商就想添加以前不存在的功能，因为没有（官方或事实上的）标准可供遵循。
这导致操作系统软件出现重大问题（您如何支持 "non-standard chaos"）。一些标准是为某些东西（APM 等）创建的，但它们并没有真正涵盖所有需要的东西并且已经过时了。 ACPI 的创建就是为了解决这个问题。
理想情况下，过去（现在仍然）需要的是允许操作系统检测和使用主板支持功能的标准。例如"standardised case temperature and fan control"设备（支持检测多少风扇、温度传感器等），或者"standardised CPU speed/power consumption"、"PCI slot IRQ routing for IO APICs"标准、"hot-plug PCI controller device"标准等.
但是，ACPI 并未提供硬件制造商和操作系统可以使用的有用标准。相反，ACPI 提供了一个过度设计的混乱 (AML) 来允许 OS 应对 ACPI 未能标准化硬件。
本质上；我们现在 "need" AML 因为它是 OS 解决 ACPI 未能修复的 "non-standard chaos" 问题的唯一可行方法。
提供本机代码而不是 AML 的问题在于不同的操作系统以不同的方式使用 CPU（例如，固件中的本机 64 位 80x86 代码对于较旧的“仅 32 位”来说毫无用处OS). AML 提供了不同类型 CPU 之间以及不同模式下相同 CPU/s 之间的可移植性。
还有；本机代码被认为是一个主要的安全问题（rootkit 等）；人们倾向于认为解释性语言可以缓解这个问题。当然，在实践中 AML 需要对底层硬件进行过多的访问，并且以 OS 无法检查的方式进行，甚至没有办法让 OS 确定是否在 OS 启动之前，AML 已被恶意修改。由于这些原因，尽管使用解释语言，反洗钱仍然是一个主要的安全问题。
ACPI 与其前身 APM 相比的一大目标是赋予 OS 更多的可行性和对电源状态转换的控制。
APM 是一个黑盒子。 OS 对电源管理实现一无所知。它只会调用 BIOS 函数，而 BIOS 会处理所有魔法。有用吗？系统是否正常休眠？系统冻结了吗？用户应用程序是否能够处理 BIOS 实现？可悲的事实是，许多系统的电源管理都彻底崩溃了，而微软希望为不断发展的笔记本电脑行业提供更好的电源管理体验。
现在，BIOS 将 ASL/AML 代码交给 OS 并且 OS 执行它而不是 BIOS。如果 BIOS 代码做了一些愚蠢的事情（比如弄乱了它不应该做的寄存器），Windows 可以通过解析代码检测到并阻止它。与 C 不同，AML 是 100% 可反编译的。
请记住，ACPI 不是特定于 x86 的。在开发它的时候，Itanium 和 Xscale 就在身边。英特尔和微软需要一种可以在所有平台上运行的语言，包括 32 位和 64 位。
最后，ASL 不仅仅是一个可执行函数的列表。它也是静态配置表的数量。 ASL 代码包含用于定义主板上内置的非 PnP 硬件的表格。它有支持的电源状态表。像 C 这样的传统编程语言并不是真正为此而设置的。
如果今天发明了 ACPI，他们可能会使用 XML 之类的东西向 OS 提供信息。
据我所知，ACPI 定义了一个通用的硬件编程模型，其中操作系统依赖于 OEM 固件提供的 AML（ACPI 机器语言）代码来操作硬件。
为了执行 AML 代码，操作系统必须包含 AML 解释器。
所以，在我看来，固件开发人员使用 AML 来提供平台硬件和操作系统之间的控制接口。
但我们真的需要反洗钱吗？
我认为最终硬件可以只通过平台的native指令配置。所以AML解释器必须将AML翻译成原生指令否则不能在平台上执行。
但是使用像 AML 这样的中间语言有什么意义呢？我的意思是，尽管据说 AML 是 平台无关的 ，这意味着我可以使用 AML 以 非本机 的方式描述我的平台。
但实际上AML是平台固件的一部分。并且整个固件已经内置到目标平台的本机指令中。 那么让固件的这么一小部分与平台无关有什么好处呢？ 为什么不直接使用本机指令呢？ 必须 有某种方式让 OS 也能使用它。而且这种方式操作系统根本不需要 AML 解释器。可以避免很多复杂性。
最初，“80x86 PC”的硬件是从 IBM 的 PC 克隆而来的，这为硬件创建了一个有效的事实标准。然而，没过多久，制造商就想添加以前不存在的功能，因为没有（官方或事实上的）标准可供遵循。
这导致操作系统软件出现重大问题（您如何支持 "non-standard chaos"）。一些标准是为某些东西（APM 等）创建的，但它们并没有真正涵盖所有需要的东西并且已经过时了。 ACPI 的创建就是为了解决这个问题。
理想情况下，过去（现在仍然）需要的是允许操作系统检测和使用主板支持功能的标准。例如"standardised case temperature and fan control"设备（支持检测多少风扇、温度传感器等），或者"standardised CPU speed/power consumption"、"PCI slot IRQ routing for IO APICs"标准、"hot-plug PCI controller device"标准等.
但是，ACPI 并未提供硬件制造商和操作系统可以使用的有用标准。相反，ACPI 提供了一个过度设计的混乱 (AML) 来允许 OS 应对 ACPI 未能标准化硬件。
本质上；我们现在 "need" AML 因为它是 OS 解决 ACPI 未能修复的 "non-standard chaos" 问题的唯一可行方法。
提供本机代码而不是 AML 的问题在于不同的操作系统以不同的方式使用 CPU（例如，固件中的本机 64 位 80x86 代码对于较旧的“仅 32 位”来说毫无用处OS). AML 提供了不同类型 CPU 之间以及不同模式下相同 CPU/s 之间的可移植性。
还有；本机代码被认为是一个主要的安全问题（rootkit 等）；人们倾向于认为解释性语言可以缓解这个问题。当然，在实践中 AML 需要对底层硬件进行过多的访问，并且以 OS 无法检查的方式进行，甚至没有办法让 OS 确定是否在 OS 启动之前，AML 已被恶意修改。由于这些原因，尽管使用解释语言，反洗钱仍然是一个主要的安全问题。
ACPI 与其前身 APM 相比的一大目标是赋予 OS 更多的可行性和对电源状态转换的控制。
APM 是一个黑盒子。 OS 对电源管理实现一无所知。它只会调用 BIOS 函数，而 BIOS 会处理所有魔法。有用吗？系统是否正常休眠？系统冻结了吗？用户应用程序是否能够处理 BIOS 实现？可悲的事实是，许多系统的电源管理都彻底崩溃了，而微软希望为不断发展的笔记本电脑行业提供更好的电源管理体验。
现在，BIOS 将 ASL/AML 代码交给 OS 并且 OS 执行它而不是 BIOS。如果 BIOS 代码做了一些愚蠢的事情（比如弄乱了它不应该做的寄存器），Windows 可以通过解析代码检测到并阻止它。与 C 不同，AML 是 100% 可反编译的。
请记住，ACPI 不是特定于 x86 的。在开发它的时候，Itanium 和 Xscale 就在身边。英特尔和微软需要一种可以在所有平台上运行的语言，包括 32 位和 64 位。
最后，ASL 不仅仅是一个可执行函数的列表。它也是静态配置表的数量。 ASL 代码包含用于定义主板上内置的非 PnP 硬件的表格。它有支持的电源状态表。像 C 这样的传统编程语言并不是真正为此而设置的。
如果今天发明了 ACPI，他们可能会使用 XML 之类的东西向 OS 提供信息。