OSDev.org

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?

As far as I know the AML is a description language, not a programming language. So you cannot convert it to assembler.

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.

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...

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.

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?

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?

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.

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.

I decide to change my mind. To be honest, the efficiency of the unchanged ACPI table is much higher than some poorly written programs.

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?

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.

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.

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?