Advice on AML Interpreter

[Jabus]

Hi,
I'm just starting to write an AML interpreter for my OS. I was wondering if any of you who are reading this have already written one and would care to give me any advice regarding the problems that you had. Finally I have read on the forums in other posts abou ACPI that your AML interpreter has to interpret AML in exactly the same way as Microsoft does: How true is this?

Thank you

[exkor]

I really doubt that any OSes presented on this forum will go beyond x86(x86-64) so I suggest you write your interpreter in assembly. If you are doing LongMode then you are likely to get away with no memory variables at all.

A bit off from AML & highlighting benefits of assembly(if you know this language):
When you are parsing MADT table:

Code: Select all

  test al, al
  jz   .0_CPU_LAPIC
  cmp  al, 8               ;8 or higher
  ja   .8_plus
  je   .7_L_SAPIC
  cmp  al, 2
  je   .2_INT_Override     ;Interrupt Source Override
  jp   .1_IO_APIC
  cmp  al, 5
  je   .5_LAPIC_addr_Override
  jpe  .4_LINTn_NMI        ;Local APIC NMI
  ja   .6_IO_SAPIC                            

.3_NMI:
  jmp  .apic_entry 

and don't forget eax/ax/al/ah is sometimes smaller than any other reg
You can off course restructure the code I presented so that the entries that appear most often go in front.

Finally I have read on the forums in other posts abou ACPI that your AML interpreter has to interpret AML in exactly the same way as Microsoft does: How true is this?

For me it really doesn't matter how often(it happens time to tme, however you'll need large # of motherboards to tell that) - if compiler that produces AML - produces different AML at least once then your code needs to care about that always.

[Dex]

I really doubt that any OSes presented on this forum will go beyond x86(x86-64) so I suggest you write your interpreter in assembly.

DexOS has a ARM port, as well as a X86, but than again its written in assembly, so you addvise is still valid.

[JamesM]

I really doubt that any OSes presented on this forum will go beyond x86(x86-64) so I suggest you write your interpreter in assembly. If you are doing LongMode then you are likely to get away with no memory variables at all.

A bit off from AML & highlighting benefits of assembly(if you know this language):
When you are parsing MADT table:

Code: Select all

  test al, al
  jz   .0_CPU_LAPIC
  cmp  al, 8               ;8 or higher
  ja   .8_plus
  je   .7_L_SAPIC
  cmp  al, 2
  je   .2_INT_Override     ;Interrupt Source Override
  jp   .1_IO_APIC
  cmp  al, 5
  je   .5_LAPIC_addr_Override
  jpe  .4_LINTn_NMI        ;Local APIC NMI
  ja   .6_IO_SAPIC                            

.3_NMI:
  jmp  .apic_entry 

and don't forget eax/ax/al/ah is sometimes smaller than any other reg
You can off course restructure the code I presented so that the entries that appear most often go in front.

Finally I have read on the forums in other posts abou ACPI that your AML interpreter has to interpret AML in exactly the same way as Microsoft does: How true is this?

For me it really doesn't matter how often(it happens time to tme, however you'll need large # of motherboards to tell that) - if compiler that produces AML - produces different AML at least once then your code needs to care about that always.

That's a little narrow minded - our operating system (Pedigree) has x86, x64, MIPS-el and ARM ports. A PPC port is on its way too.

[exkor]

I am single person JamesM and operating well in my capabilities, quality but little. You James had several posts lately where indicated wrong knowledge of x86 assembly but at least you know all those arch(ia64 is pretty much dead, ARM[which one?] is only widely used in cell phones,PocketPC,HPC[while Intel pushing its Atom and partially sold xscale business], Apple switched to x86 for laptops at least).

[pcmattman]

ARM[which one?] is only widely used in cell phones

Sorry, had to point out that that's not really correct.

Yes, ARM is used in a majority of phones, but it's also in the Nintendo Gameboy and DS, the iPod(s) (and other portable music players), etc...

It's also in many things you wouldn't expect, such as a set top box, dvd recorder, your router.

ARM is an extremely popular architecture for embedded systems (it's been researched and there are more ARM chips than x86 processors in use ).

[Cognition]

The only thing you really should need to change for MS compatibility is the _OS variable. I'm not sure if that's the case on all motherboards, but on mine it'd check if the string was "Windows", "Windows NT" or something else and set another set of feature flags.

I'd recommend getting Intel's ASL/AML tools as well.
http://www.intel.com/technology/iapc/acpi/downloads.htm

I haven't looked at the licensing, but it actually has an interpreter you can integrate. If you're really set on writing your own though, keep in mind the documentation given in the specification is very very poor. I'd get the tools anyways so you can disassemble your DSDT for reference.

[Jabus]

I'd recommend getting Intel's ASL/AML tools as well.
http://www.intel.com/technology/iapc/acpi/downloads.htm

I haven't looked at the licensing, but it actually has an interpreter you can integrate. If you're really set on writing your own though, keep in mind the documentation given in the specification is very very poor. I'd get the tools anyways so you can disassemble your DSDT for reference.

That sounds like a good idea. I'll certainly look into those tools. My current idea was that I could look at the BOCHS dsdt ASL file. Then see if my interpreter produces the same namespcae that is described. Does this sound feasable?

[JamesM]

You James had several posts lately where indicated wrong knowledge of x86 assembly

Hi Exkor:

Could you please link to these posts? I wholeheartedly apologise for not knowing by heart the exact workings of that orthogonal and unobtuse instruction set that is the x86!

Cheers,

James

EDIT: you also seem confused: x64 != ia64 -- x64 is a synonym for amd64 or x86_64. Also, PPC is a chip made by IBM, based on the old PowerPC chip. Apple used to use them in its macs pre-intel.

[Cognition]

I'd recommend getting Intel's ASL/AML tools as well.
http://www.intel.com/technology/iapc/acpi/downloads.htm

I haven't looked at the licensing, but it actually has an interpreter you can integrate. If you're really set on writing your own though, keep in mind the documentation given in the specification is very very poor. I'd get the tools anyways so you can disassemble your DSDT for reference.

That sounds like a good idea. I'll certainly look into those tools. My current idea was that I could look at the BOCHS dsdt ASL file. Then see if my interpreter produces the same namespcae that is described. Does this sound feasable?

That's a good way to start. Keep in mind that bochs has a very small amount of AML code compared to an actual desktop though, you'll likely need to compile some ASL code at one point or another just to make sure your interpreter understands it. After that you'll have to make sure all of it functions.

Some other things I'd note about just using the bochs sources is that their simplicity and design ultimately ends up making AML look a lot cleaner then what you'll find on a real system. For instance namespace objects don't need to be declared before they're referenced. There's no bytecode to indicate that a function is being called or how many parameters are being passed to it i.e: SomeMethod(param1, param2) can for all purposes be mistaken for SomeMethod, param1, param2. I'm not sure how other interpreters deal with it, but I found it necessary to pass through the the code once to establish a general structure and locate all methods located in the DSDT, then pass through it again to actually assemble everything into functional operations, just so you can list a list of methods to compare name references to. AML actually supports runtime loading of external code too which complicates things even further, but that's something to deal with much later on.

[lukem95]

Just a quick question, will you be publishing/gpl-ing your interpreter once its complete?

I am interested in ACPI, but i don't think i have the knowledge to code an interpreter. Don't get me wrong, im not trying to steal your code, but if you do plan to share your work, in any form, im sure a wiki article detailing how to begin would be warmly received

[Cognition]

If I ever get my code into a releasable state I'd probably public domain it. But that's a ways off to be honest. I started working on an interpreter just because it seemed like something interesting to work on, not because my OS was at a great stage todo so. It's still too bloated for my tastes and I'll probably rework the RTTI setup I have and simplify the overall structure with some additional templates. It still doesn't have run time loading or every single opcode for the 1.0 specification let alone some of the newer ones.

I don't think it's something that would really fit in a wiki article either tbh, it's just too big and I'd rather finish it and post some code. The plus side of all this is it's completely done in C++ and should be portable to just about anything that has the proper bus interfaces and dynamic memory management.

[Jabus]

Personally I wouldn't release any code. However I would be strongly interested on writing a wiki article about it if my endeavours are successful.

[lukem95]

ok, im sure it would be well reveived.

As for the wiki article, i understand that a complete wiki article would be very unsuitable, as it seems like quite a large project. However maybe something detailing how to start, with a few tips/tricks, some links (to Cognition's code when it's released) etc, so people can have a go at writing one.

[jal]

Iirc, Linux uses the Intel sources? As for other platforms, are there actually other platforms using AML? I thought it was a PC-only thing.


JAL