据我所知，ACPI定义了一种通用硬件编程模型，其中操作系统依赖于OEM固件提供的AML（ACPI机器语言）代码来操作硬件。
为了执行AML代码，操作系统必须包含AML解释器。
因此，我认为固件开发人员使用AML在平台硬件和操作系统之间提供控制接口。
但我们真的需要AML吗？
我认为 最终 硬件只能 通过 native <配置 / em> 平台的指令。因此，AML解释器必须将AML转换为本机指令，否则无法在平台上执行。
但使用像
但是AML在实践中是平台固件的一部分。整个固件已经内置到目标平台的本机指令中。 那么将固件的这么一小部分作为独立于平台的东西有什么用呢？ 为什么不使用原生指令呢？ 必须 是让操作系统使用它的某种方式。这种方式操作系统根本不需要AML解释器。可以避免很多复杂性。
答案 0 :(得分：2)
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的东西来为操作系统提供信息。
答案 1 :(得分：1)
最初，“80x86 PC”的硬件是从IBM的PC上克隆出来的，这为硬件制定了一个有效的事实标准。然而，在制造商想要添加以前不存在的功能之前不久，没有（官方或事实上）标准可以遵循。
这导致了操作系统软件的一个主要问题（如何支持“非标准混乱”）。有些标准是为某些事物（APM等）创建的，但它们并没有真正涵盖所需的一切，并且已经过时了。创建ACPI是为了解决这个问题。
理想情况下，所需的（仍然是）标准允许操作系统检测和使用主板支持的功能。例如，“标准化外壳温度和风扇控制”设备（支持检测多少风扇，温度传感器等），或“标准化CPU速度/功耗”，“用于IO APIC的PCI插槽IRQ路由”标准，“热插拔PCI控制器设备”标准等
但是，ACPI没有提供硬件制造商和操作系统可以使用的有用标准。相反，ACPI提供了一个过度设计的混乱（AML），允许操作系统应对ACPI无法标准化硬件。
本质;我们现在“需要”AML，因为它是操作系统解决ACPI无法修复的“非标准混乱”问题的唯一可行方式。
提供本机代码而不是AML的问题在于不同的操作系统以不同的方式使用CPU（例如，固件中的原生64位80x86代码对于较旧的“仅32位”OS而言是无用的。 AML提供不同类型CPU之间以及不同模式下相同CPU之间的可移植性。
也;本机代码被认为是一个主要的安全问题（rootkit等）;人们倾向于认为解释性语言可以缓解这个问题。当然，在实践中，AML需要对底层硬件的过多访问，并且以操作系统无法检查的方式进行操作，并且操作系统甚至没有办法确定AML是否在之前被恶意修改。操作系统启动。由于这些原因，尽管使用了解释语言，AML仍然是一个主要的安全问题。