Why do we need AML - ACPI Machine Langauge?
As I understand it, ACPI defines a generic hardware programming model in which the operating system relies on the OEM firmware supplied with AML (ACPI machine langauge) to control the hardware.
To execute AML code, the operating system must include an AML interpreter.
So, it seems to me that firmware developers use AML to provide a control interface between platform hardware and operating system.
But do we really need AML?
I think ultimately the hardware is only configured with the native platform instruction . Therefore the AML interpreter must translate AML into its own instructions, otherwise it cannot be executed on the platform.
But what's the point of using an intermediate language like AML? I mean, although AML is said to be platform independent, which means I can use AML to describe my platform in a non-native way.
But AML is part of the platform's firmware in practice. And all the firmware is already built into the target platform user instructions. ... What is the use of making such a small piece of firmware platform independent? Why not just use your own instructions? There must be a way for the OS to use it as well. And thus the operating system doesn't need an AML interpreter at all. Many complications can be avoided.
source to share
One of the main goals of the ACPI over its predecessor, APM, was to provide greater OS resilience and control over power transitions.
APM was a black box. The OS knew nothing about the implementation of power management. It would just call the BIOS function and the BIOS handled all the magic. Did it work? Did the system sleep properly? Is the system frozen? Was the custom application capable of handling the BIOS implementation? The sad truth was that many systems had completely disrupted power management and Microsoft wanted to provide the best power management experience for the growing laptop industry.
Now the BIOS passes the ASL / AML code to the OS and the OS does not do the BIOS . If the BIOS code is doing something dumb (for example, a mess with registers, it shouldn't), Windows can detect it by analyzing the code and blocking it. AML is 100% decompiled, unlike C.
Remember ACPI is not x86 specific. At the time it was developed, Itanium and Xscale were around. Intel and Microsoft needed a language that would work on all platforms, both 32 and 64 bits.
Finally, ASL is not just a list of executable functions. It is also the number of static configuration tables. The ASL code has tables to identify non-PnP hardware built into your motherboard. It has tables of supported power states. A traditional programming language like C isn't really set up to do this.
If ACPI were invented today, they would probably use something like XML to provide OS information.
source to share
The original "80x86" PC hardware was cloned from the IBM PC and this created an effective de facto standard for hardware. However, it didn't take long for developers to add features that didn't exist before, where there was no (official or de facto) standard.
This led to a major problem for the operating system software (how do you maintain "custom chaos"). Some standards were created for some things (APM, etc.), but they really didn't cover everything needed and are not outdated. ACPI was created to fix this.
Ideally, what was (and still is) needed are standards that allow the operating system to discover and use supported features on the motherboard. For example, "standardized chassis and fan temperature measurement device" (with support for determining the number of fans, temperature sensors, etc.) Or "standardized processor speed / power consumption", standard "PCI-IRQ routing for IO APIC", "standard hot-plug PCI controller device "and so on.
However, ACPI has not provided useful standards that hardware and operating system manufacturers can use. Instead, ACPI provided Recycled Clutter (AML) to allow the OS to deal with ACPI failure to standardize hardware.
Essentially; we "need" AML because it is the only viable way for the OS to deal with the "substandard chaos" problem that ACPI was unable to fix.
The problem with providing native code instead of AML is that different operating systems use processors differently (for example, native 80x86 64-bit code in firmware would be useless for an older "32-bit" OS). AML provides portability between different types of processors and between the same CPU / s in different modes.
Also; native code is considered a major security issue (rootkits, etc.); and people tend to think that interpreted language mitigates this problem. Of course, in practice, AML requires too much access to the underlying hardware and does so in such a way that the OS cannot verify, and even the OS cannot determine if the AML was maliciously modified before the OS booted. For these reasons, AML is still a major security issue despite the use of an interpreted language.
source to share