smw*_*dia 5 bios firmware acpi uefi
据我了解，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 之间的可移植性。
还; 本机代码被认为是一个主要的安全问题（rootkits 等）；人们倾向于认为解释型语言可以缓解这个问题。当然，在实践中 AML 需要对底层硬件进行太多访问，并且以操作系统无法检查的方式进行访问，操作系统甚至无法确定 AML 是否在此之前被恶意修改。操作系统启动。由于这些原因，尽管使用解释性语言，AML 仍然是一个主要的安全问题。
ACPI 相对于其前身 APM 的一大目标是为操作系统提供更多的可行性和对电源状态转换的控制。
APM 是一个黑匣子。操作系统对电源管理实现一无所知。它只会调用 BIOS 函数，而 BIOS 会处理所有的魔法。它起作用了吗？系统睡眠是否正常？系统冻结了吗？用户应用程序是否能够处理 BIOS 实现？可悲的事实是，许多系统的电源管理完全被破坏，微软希望为不断发展的笔记本电脑行业提供更好的电源管理体验。
现在，BIOS 将 ASL/AML 代码移交给操作系统，操作系统而不是 BIOS 执行它。如果 BIOS 代码做了一些愚蠢的事情（比如弄乱了它不应该的寄存器），Windows 可以通过解析代码并阻止它来检测到它。与 C 不同，AML 是 100% 可反编译的。
请记住，ACPI 不是特定于 x86 的。在它开发的时候，安腾和 Xscale 就在身边。英特尔和微软需要一种可以在所有平台（32 位和 64 位）上运行的语言。
最后，ASL 不仅仅是可执行函数的列表。它也是静态配置表的数量。ASL 代码具有定义构建在主板上的非 PnP 硬件的表格。它有支持的电源状态表。像 C 这样的传统编程语言并没有真正为此设置。
如果今天发明了 ACPI，他们可能会使用 XML 之类的东西向操作系统提供信息。