> Why would ACPI somehow have to be less powerful than the rest of the > computer firmware?
ACPI is not actually firmware -- ACPI doesn't actually DO anything like firmware does. Firmware is sort of like "permanent software" (executable code stored usually in non-volatile RAM or ROM), while ACPI does not contain any executable code (at least nothing that can be executed directly). > I have not finished reading the ACPI specification, but my > understanding is, it is essentially a series of tables (and > bytecodes) that tell an OS (e.g. MS-DOS, Windows) about the > peripherals and features a machine has, and some information on how > to control them. Sort of. ACPI contains tables of the hardware contents of the computer similar to SMBIOS (and from what I understand that part of ACPI is intended to make SMBIOS completely obsolete). It's also intended to make APM obsolete, but does not do anything that APM does. For example, APM has built-in functions you can call directly to do things like shut down the computer or get the current battery information for a laptop, but ACPI does not (at least not directly) have any kind of similar functionality. Just like SMBIOS, ACPI is "hard-coded" and does not change in real-time (or even at boot time) to adjust itself to the current state of the computer. The ACPI data is "compiled" when the computer is first manufactured, so if you have changed anything on the computer (e.g., replaced the original Intel CPU with an AMD CPU or changed the CPU to something with a different number of cores or over/underclocked the CPU or ...) it will never be reflected in the ACPI tables. So, ACPI should never contain data on anything that is "replaceable" or "upgradable", or at least you should never trust anything ACPI tells you about anything that is not "permanent". As far as "bytecodes", that's also a "sort of". As I alluded to above, ACPI does not contain any directly executable code or even any functions that return useful data like APM does. You could not, for example, just pull a section out of ACPI, insert it into memory, and then have the CPU execute the data stored in memory as if it contained properly compiled/assembled code. The "bytecode" contained in ACPI is stored in a special format called ACPI Machine Language (AML). AML is weird -- the best way I can describe it is Encrypted PseudoCode. What you must first do is Disassemble the AML code. It really is a Machine Language analogous to what is stored in the computer's memory for "normal" executable code, but if you Disassemble AML into something human-readable what you see is PseudoCode rather than the ASM code that you would see from a "normal" Disassembly. From what I understand, the reason it is PseudoCode instead of "real" code is to be CPU-independent. That is, the same computer could have an Intel-compatible or ARM or RISC CPU or even something else and the ACPI part would never need to change. To actually do something with ACPI, you must then take the Disassembled PseudoCode, somehow create "real" code from it, and compile/assemble that "real" code into something executable that the CPU can actually use. In an actual implementation, of course, you wouldn't necessarily need to go through a human-readable format in the middle, but you somehow need to convert from ACPI Machine Language to "real" Machine Language. ACPI really is a weird, convoluted, multi-tiered, confusing, nightmare to work with. In addition, computer manufacturers don't create AML "code" directly, but use a higher-level language program (something similar to ASM or C or PERL) to "compile" the ACPI tables and AML "code". Just like almost nobody creates programs any more using "real" machine language, almost nobody creates ACPI tables directly in AML. And just like regular programs, sometimes ACPI tables have bugs and errors, so you can't necessarily trust everything they tell you. ACPI is also not "modular". It's really designed so that you need to Disassemble, Convert, and Compile the whole ACPI even if all you are trying to do is one simple thing. Trying to extract one simple item from it can be unbelievably cumbersome. I've done a little bit of it myself, and I know Eric has as well. I know others here have at least some experience with ACPI too. Let's use the current discussion as an example -- twiddling the BIOS so that the computer will automatically boot as soon as it gets power. The BIOS on my particular computer doesn't have that option, but it does have "boot on LAN" and "boot on certain days of the month or certain times of day" options. There is enough circuitry in the computer that I think adding a "boot as soon as you get power" option wouldn't be too difficult to add (maybe it would, but I don't think so). Anyway, let's say it were possible and if you upgraded the BIOS that would be a new option in there. Let's also say that the current ACPI included options to monitor and adjust time-of-day and day-of-month boot options. Even if I were to upgrade the BIOS, though, the ACPI would not be upgraded to include the new boot option because ACPI is "hard-coded". That's part of the reason you don't want non-permanent things (like BIOS options) in ACPI. Another example would be something like Model-Specific Registers (MSR's) in the CPU. In theory, you could put something like that in the ACPI tables, but they would be wrong if you replaced the CPU with something else. > Nothing prevents the ACPI tables from exposing to the OS whatever > functionality the firmware might have, if the ACPI tables so choose. That's true -- it could (at least theoretically) be done. But, for the reasons indicated above (in addition to other reasons) it's really not a good idea. Let ACPI do what it was designed to do and leave it at that. Some people want a single "standard" like ACPI to address absolutely everything, and it will never (and can never) do that. It's sort of like a "Theory of Everything" that the scientists are trying to come up with that will replace all the different aspects of science as we know them today (physics, chemistry, biology, the "social sciences", etc.). It's a pipe dream that will never happen because that's just not how things work. I personally think that even what ACPI attempts to accomplish already is an extreme overreach. _______________________________________________ Freedos-devel mailing list Freedos-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/freedos-devel
