Is it necessary to convert all the AML in the ACPI table to x86 assembly?

Question about which tools to use, bugs, the best way to implement a function, etc should go here. Don't forget to see if your question is answered in the wiki first! When in doubt post here.
Post Reply
wishedtobe
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?

Post by wishedtobe »

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?
sebihepp
Member
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?

Post by sebihepp »

As far as I know the AML is a description language, not a programming language. So you cannot convert it to assembler.
nullplan
Member
Member
Posts: 1779
Joined: Wed Aug 30, 2017 8:24 am

Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?

Post by nullplan »

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?
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.
sebihepp wrote: Tue Oct 01, 2024 12:34 am As far as I know the AML is a description language, not a programming language. So you cannot convert it to assembler.
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!
sebihepp
Member
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?

Post by sebihepp »

nullplan wrote: Tue Oct 01, 2024 8:22 am 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.
Then I must apologize for my lacking knowledge. Another thing I learned...
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?

Post by wishedtobe »

sebihepp wrote: Tue Oct 01, 2024 12:34 am As far as I know the AML is a description language, not a programming language. So you cannot convert it to assembler.
These methods can be converted to some extent, I think. Anyway, I can't tolerate any megabytes of space being taken away.
Octocontrabass
Member
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?

Post by Octocontrabass »

wishedtobe wrote: Tue Oct 01, 2024 6:18 pmAnyway, I can't tolerate any megabytes of space being taken away.
Why do you need so much memory that you can't spare any for ACPI tables?
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?

Post by wishedtobe »

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.
My expression is flawed. What I mean is, should I call and convert them in real-time, and then keep all the ACPI tables?
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?

Post by wishedtobe »

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?
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
Member
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?

Post by Octocontrabass »

wishedtobe wrote: Tue Oct 01, 2024 6:42 pmMy faith drives me to do this.
Be careful.
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.
Sometimes things are outside of your control and you just have to deal with it. This might be one of those times.
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?

Post by wishedtobe »

I decide to change my mind. To be honest, the efficiency of the unchanged ACPI table is much higher than some poorly written programs. 😂
rdos
Member
Member
Posts: 3288
Joined: Wed Oct 01, 2008 1:55 pm

Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?

Post by rdos »

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?
nullplan
Member
Member
Posts: 1779
Joined: Wed Aug 30, 2017 8:24 am

Re: Is it necessary to convert all the AML in the ACPI table to x86 assembly?

Post by nullplan »

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?
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:42 pm which is unbearable for perfectionists.
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.
rdos wrote: Wed Oct 02, 2024 9:10 am 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.
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.
rdos wrote: Wed Oct 02, 2024 9:10 am Well, it also fools BIOS that Windows is running, but that's only an issue on severely broken BIOS implementations.
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!
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?

Post by wishedtobe »

rdos wrote: Wed Oct 02, 2024 9:10 am However, I wonder how this can use megabytes?
The DSDT+SSDT I retrieved using IASL is only about 300kb, but the ACPI reclaimable RAM obtained by accessing e820 reaches 2mb. I wonder what kind of garbage BIOS has stuffed inside.
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?

Post by wishedtobe »

nullplan wrote: Wed Oct 02, 2024 10:32 am 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.
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?
Post Reply