据我了解，ACPI定义了一个通用硬件编程模型，其中操作系统依赖于OEM固件提供的AML(ACPI机器语言)代码来操作硬件。
为了执行 AML 代码，操作系统必须包含 AML 解释器。
因此，在我看来，固件开发人员使用 AML 在平台硬件和操作系统之间提供控制接口。
但我们真的需要反洗钱吗？
我认为最终硬件只能通过平台的本机指令进行配置。因此，AML解释器必须将AML转换为本机指令，否则无法在平台上执行。
但是使用像AML这样的中间语言有什么意义呢？我的意思是，虽然 AML 据说是独立于平台的，这意味着我可以使用 AML 以非原生方式描述我的平台。
但AML在实践中是平台固件的一部分。整个固件已经内置到目标平台的本机指令中。那么，使固件的这么小的一部分独立于平台有什么好处呢？为什么不直接使用本机指令？必须有某种方法可以让操作系统也使用它。这样操作系统根本不需要 AML 解释器。可以避免很多复杂性。
与其前身 APM 相比，ACPI 的主要目标之一是为操作系统提供对电源状态转换的更多可行性和控制。
APM是一个黑匣子。操作系统对电源管理实施一无所知。它只会调用一个BIOS函数，BIOS处理所有的魔法。它有效吗？ 系统是否正常睡眠？系统是否冻结？ 用户应用程序是否能够处理 BIOS 实现？ 可悲的事实是，许多系统的电源管理完全被破坏了，Microsoft希望为不断发展的笔记本电脑行业提供更好的电源管理体验。
现在，BIOS 将 ASL/AML 代码交给操作系统，操作系统执行它而不是 BIOS。如果BIOS代码做了一些愚蠢的事情(比如弄乱寄存器，它不应该)，Windows可以通过解析代码并阻止它来检测它。与 C 不同，AML 是 100% 可反编译的。
请记住，ACPI 不是特定于 x86 的。在开发它的时候，Itanium和Xscale已经存在。英特尔和Microsoft需要一种适用于所有平台(32 位和 64 位)的语言。
最后，ASL 不仅仅是一个可执行函数的列表。它也是静态配置表的数量。ASL 代码具有用于定义主板上内置的非 PnP 硬件的表。 它具有支持的电源状态表。 像C这样的传统编程语言并不是真正为此而设置的。
如果ACPI是今天发明的，他们可能会使用XML之类的东西向操作系统提供信息。
最初，"80x86 PC"的硬件是从IBM的PC克隆而来的，这为硬件创造了一个有效的事实标准。然而，没过多久，制造商就想要添加以前不存在的功能，而这些功能没有(官方或事实上的)标准可循。
这导致了操作系统软件的一个主要问题(你如何支持"非标准混沌")。为某些事情(APM等)创建了一些标准，但它们并没有真正涵盖所需的一切，并且已经过时了。创建 ACPI 就是为了解决此问题。
理想情况下，过去(现在仍然)需要的是允许操作系统检测和使用主板支持功能的标准。例如，"标准化机箱温度和风扇控制"设备(支持检测风扇数量、温度传感器等)，或"标准化 CPU 速度/功耗"、"IO APIC 的 PCI 插槽 IRQ 路由"标准、"热插拔 PCI 控制器设备"标准等。
但是，ACPI 没有提供硬件制造商和操作系统可以使用的有用标准。相反，ACPI提供了一个过度设计的混乱(AML)，以允许操作系统应对ACPI未能标准化硬件的问题。
从本质上讲，我们现在"需要"AML，因为这是操作系统解决ACPI未能解决的"非标准混乱"问题的唯一可行方法。
提供本机代码而不是 AML 的问题在于，不同的操作系统以不同的方式使用 CPU(例如，固件中的本机 64 位 80x86 代码对于较旧的"仅 32 位"操作系统毫无用处)。AML 提供不同类型的 CPU 之间以及不同模式下相同 CPU/s 之间的可移植性。
此外，原生代码被认为是一个主要的安全问题(rootkits等);人们倾向于认为解释性语言可以缓解这个问题。当然，在实践中，AML需要对底层硬件进行太多的访问，并且以操作系统无法检查的方式进行，甚至没有办法让操作系统确定AML是否在操作系统启动之前被恶意修改。由于这些原因，尽管使用了解释性语言，反洗钱仍然是一个主要的安全问题。