Is it necessary to convert all the AML in the ACPI table to x86 assembly?
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
Is it necessary to convert all the AML in the ACPI table to x86 assembly?
Or should I keep the entire AML and use the interpreter? Given that the DSDT and the SSDT have approximately taken up 2mb of my memory space, will converting them to assembly save some space?
-
- Member
- Posts: 184
- Joined: Tue Aug 26, 2008 11:24 am
- GitHub: https://github.com/sebihepp
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
As far as I know the AML is a description language, not a programming language. So you cannot convert it to assembler.
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
If you have something that can convert the AML to assembler, then don't you already have an AML interpreter? Only yours emits assembler instructions instead of just executing the AML. Or are you doing this by hand? In that case, it is only necessary to convert the stuff that ends up getting used. If you have no desire to implement ACPI sleep levels 1-4, there is no need to convert those routines, for example.wishedtobe wrote: ↑Mon Sep 30, 2024 8:29 pm Or should I keep the entire AML and use the interpreter? Given that the DSDT and the SSDT have approximately taken up 2mb of my memory space, will converting them to assembly save some space?
No, AML is a programming language. With a bunch of weird rules, and for some reason identifiers can only consist of four bytes each, and a lot of them have predefined meanings, but a programming language nonetheless.
Carpe diem!
-
- Member
- Posts: 184
- Joined: Tue Aug 26, 2008 11:24 am
- GitHub: https://github.com/sebihepp
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
Then I must apologize for my lacking knowledge. Another thing I learned...
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
-
- Member
- Posts: 5531
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
Why do you need so much memory that you can't spare any for ACPI tables?wishedtobe wrote: ↑Tue Oct 01, 2024 6:18 pmAnyway, I can't tolerate any megabytes of space being taken away.
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
My expression is flawed. What I mean is, should I call and convert them in real-time, and then keep all the ACPI tables?nullplan wrote: ↑Tue Oct 01, 2024 8:22 am If you have something that can convert the AML to assembler, then don't you already have an AML interpreter? Only yours emits assembler instructions instead of just executing the AML. Or are you doing this by hand? In that case, it is only necessary to convert the stuff that ends up getting used. If you have no desire to implement ACPI sleep levels 1-4, there is no need to convert those routines, for example.
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
My faith drives me to do this. Even the code of my planned operating system will not exceed 400kb, but now a few bytes of useful information occupy 2mb, which is unbearable for perfectionists.Octocontrabass wrote: ↑Tue Oct 01, 2024 6:25 pm Why do you need so much memory that you can't spare any for ACPI tables?
-
- Member
- Posts: 5531
- Joined: Mon Mar 25, 2013 7:01 pm
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
Be careful.
Sometimes things are outside of your control and you just have to deal with it. This might be one of those times.wishedtobe wrote: ↑Tue Oct 01, 2024 6:42 pmEven the code of my planned operating system will not exceed 400kb, but now a few bytes of useful information occupy 2mb, which is unbearable for perfectionists.
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
I decide to change my mind. To be honest, the efficiency of the unchanged ACPI table is much higher than some poorly written programs.
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
My ACPI driver is 392kB, which is a huge waste of space, particularly since the only thing it does is to provide me with IRQ numbers of some nasty PCI devices that doesn't support MSI or MSI-X. Well, it also fools BIOS that Windows is running, but that's only an issue on severely broken BIOS implementations. However, I wonder how this can use megabytes?
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
You can also convert them and then free the ACPI tables. Or not convert them and just interpret them in real time. You can also convert only the parts that interest you and ignore the rest. That should compress the data somewhat.wishedtobe wrote: ↑Tue Oct 01, 2024 6:30 pm My expression is flawed. What I mean is, should I call and convert them in real-time, and then keep all the ACPI tables?
Perfection is a really high bar to clear. Might want to set your sights on something slightly more realistic first? Perfection is best attained asymptotically.
Same advice for you: Only convert the parts you need for that. As I recall, you also have no need for hibernation support, right? That should reduce the amount of data saved considerably.
Most BIOSes are severely broken. Some guy at the ACPI forum once wrote some example code that tested for Linux (just to show what _OSI() could be used for), and now a bunch of devices exist which contain the same (broken) example code for Linux, so Linux itself is not even declaring itself anymore.
Carpe diem!
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
-
- Posts: 20
- Joined: Sat May 04, 2024 7:48 am
- Libera.chat IRC: wishedtobe
Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?
I once analyzed the source code of an operating system called BleskOS. This is how it handles ACPI: from RSDP to RSDT, then to FADT (where it obtains the base address of pm1), followed by DSDT. Additionally, it uses SCASD to search for the S5 field. So, it simply utilizes ACPI for shutdown. Should I follow suit and use SCASD when dealing with ACPI?