OSDev.org

That sort of makes sense, except I thought the ASL External keyword should have defined that sort of expected behaviour and my example "should" throw a big fat error with it.. in any event, you can only parse what you're given.. if it's junk then one would assume any other OS running on that machine would have the same trouble (be it nix or windows) and the firmware vendor would have a problem

jnc100 wrote:The main difficulty with parsing AML where potential forward references come in is that in order to correctly parse method calls you need to know how many parameters the method has, and this is not defined at the call site but rather the declaration site which may be much further along the byte stream.

3a) If a method definition is encountered then store a method definition in the hash table, along with the start and end offsets of the code and the number of parameters, but do not try and do anything else with the methods code (e.g. tokenize it before it is called), simply skip over it and continue
3b) Similarly for if-else statements, skip over the bits which aren't called.

So i've followed your suggestions, i'm removing my tree type structure and going with a flat table + hash, i can see the simplicity of it which is great.
I'm going a similar route with method declaration.. but..
i'm still not 100% sure on how to handle these IF type blocks..
Given the above, assuming a single pass.. we get to the If SS1 code.. SS1 isn't defined yet, so we have no way of knowing if it's less than 10.. it would be wrong to assume it is 0 because then we're going to create an entry for SS2=0 and the If block will execute and the Else will be skipped. Then we declare SS1 but it's too late now to evaluate the If.
option 1) If the expression evaluation finds any undefined/unresolved symbol in the predicate.. simply skip the ENTIRE IF/ELSE block.. mark that we need another pass.. and repeat.. the problem with that is that certain code is likely to be executed twice .. like the Method call to Bob.. which may or may not be a problem, but it's not right to call it twice.. alternative
2) do the same as 1 but ONLY allocate entries in the symbol table on the initial passes don't actually execute anything at all until ALL symbols are defined/resolved... but even that is a bit suspect because the execution of the code may be absolutely required to define symbols.

this would all have been so much easier if IASL simply generated a proper bytecode instead of AML.. a virtual set of registers,stack,flags and a bunch of opcodes.. which you just execute.. all data(address relative to AML start) or whatever compiled down into a .data or .bss type section in the bytecode..

In that case yes, you'd need to do multiple passes over all reachable code (i.e. code that is currently 'valid' i.e. root scope, currently executing method or if-else block) until all forward references are resolved. The comments in nsparse.c may be of help.

I have not, however, found any production AML code that requires this (I have several test blocks taken from the virtual box aml and also dumped off several of my machines here). From reading various postings, it seems that the bios writers actively try and avoid writing code with forward references as errors were thrown in early ACPICA versions when encountering them.

Regards,
John.

ok, i would imagine it's avoided like the plague.. imagine if one of the if else blocks triggers a sleep state or something.. actually executing the wrong block based on the if / else could be "unfortunate".

I'll carry on working on an aml parser (slowly in the background) although I've managed to pretty much avoid everything acpi offers by going directly to the chipsets.. which i actually prefer in the long run, so the aml/acpi stuff would be a fallback for when specific chipsets aren't implemented.

It also helps to think of AML like Java bytecode or .NET disassembled IL, and AML objects like Javascript objects. Objects and members are referenced by name, are dynamic, and can be of any "type", meaning that pretty much any AML code executed must be evaluated one command at a time, at run time.

This limits the amount of "compile time" checking you can do to things like checking for valid "instruction" encoding. Pretty much everything else must be assumed to be correct until the instruction is executed.

And since there doesn't seem to be any concept of error handling support, and you don't have any way of reporting errors to either the user or the OS, you might as well just assume that all instructions that are properly encoded are valid, and just trust that the firmware developers have written bug-free code.

You can see why ACPI is so disliked by the osdev community. I can't imagine the Microsoft/Intel guys that were responsible for making it work were too pleased, either.