据我了解，ACPI 定义了一个通用硬件编程模型，其中操作系统依赖 OEM 固件提供的 AML（ACPI 机器语言）代码来操作硬件。
为了执行 AML 代码，操作系统必须包含一个 AML 解释器。
因此，在我看来，固件开发人员使用 AML 来提供平台硬件和操作系统之间的控制接口。
但我们真的需要 AML 吗？
我认为最终只能通过平台的本机指令配置硬件。因此 AML 解释器必须将 AML 翻译成本机指令，否则无法在平台上执行。
但是使用像 AML 这样的中间语言有什么意义呢？我的意思是虽然 AML 据说是平台无关的，这意味着我可以使用 AML 以非本地方式描述我的平台。
但 AML 实际上是平台固件的一部分。并且整个固件已经内置到目标平台的本机指令中。那么让固件的一小部分独立于平台有什么好处呢？为什么不只使用本机指令？必须有某种方法让操作系统也使用它。这样操作系统就根本不需要 AML 解释器。可以避免很多复杂性。
最初，“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 之间的可移植性。
还; 本机代码被认为是一个主要的安全问题（rootkit 等）；人们倾向于认为解释性语言可以缓解这个问题。当然，在实践中，AML 需要对底层硬件进行太多访问，并且以操作系统无法检查的方式进行操作，而且操作系统甚至无法确定 AML 是否在操作系统启动。由于这些原因，尽管使用解释性语言，AML 仍然是一个主要的安全问题。
ACPI 与其前身 APM 相比的一大目标是赋予操作系统更多的生存能力和对电源状态转换的控制。
APM 是一个黑匣子。操作系统对电源管理实现一无所知。它只会调用 BIOS 函数，而 BIOS 会处理所有的魔法。它奏效了吗？系统是否正常睡眠？系统冻结了吗？用户应用程序是否能够处理 BIOS 实施？可悲的事实是，许多系统的电源管理完全被破坏了，微软希望为不断发展的笔记本电脑行业提供更好的电源管理体验。
现在，BIOS 将 ASL/AML 代码交给操作系统，操作系统而不是 BIOS 执行它。如果 BIOS 代码做了一些愚蠢的事情（比如弄乱不应该的寄存器），Windows 可以通过解析代码来检测并阻止它。与 C 不同，AML 是 100% 可反编译的。
请记住，ACPI 不是 x86 特定的。在它被开发的时候，Itanium 和 Xscale 就在身边。英特尔和微软需要一种可以在所有平台上运行的语言，包括 32 位和 64 位。
最后，ASL 不仅仅是可执行函数的列表。它也是静态配置表的数量。ASL 代码有表格来定义内置在主板上的非 PnP 硬件。它有支持的电源状态表。像 C 这样的传统编程语言并没有真正为此设置。
如果今天发明了 ACPI，他们可能会使用 XML 之类的东西向操作系统提供信息。