|
|-
|}
== Parsing AML ==
While the ACPI specification (and therefore the ''meaning'' of the AML in the [[DSDT]] and [[SSDT]]) is very complicated, the bytecode itself is described by a formal grammar described in the ACPI specification. For example, here is the grammar that describes a simple ASCII string.
<source lang="c">
String := StringPrefix AsciiCharList NullChar
StringPrefix := 0x0D
AsciiCharList := Nothing | <AsciiChar AsciiCharList>
AsciiChar := 0x01 - 0x7F
</source>
It seems reasonable that you could write recursive descent parsers for these individual objects, as below.
<source lang="c">
function parse_string:
if parse_string_prefix:
if parse_ascii_char_list:
if parse_null_char:
return 1
else:
return 0
else:
return 0
else:
return 0
function parse_string_prefix:
if next char == 0x0D:
return 1
else:
return 0
function parse_ascii_char_list:
if parse_ascii_char:
return parse_ascii_char_list
else:
return parse_nothing
function parse_ascii_char:
if next char < 0x01:
return 0
else if next char > 0x7F:
return 0
else:
return 1
function parse_null_char:
if next char == 0x00:
return 1
else:
return 0
function parse_nothing:
return 1
</source>
This will work for the vast majority of the AML grammar. In fact, if it weren't for two things, you could write a parser for all of AML by referring only to the 10 pages of formal grammar in the specification and not knowing a thing about what the objects you're parsing ''mean''. Unfortunately, those two things are '''PkgLength''' and '''MethodInvocation'''.
===PkgLength===
'''PkgLength''' is an object that appears in some grammars, like '''DefScope''':
<source lang="c">
DefScope := ScopeOp PkgLength NameString TermList
ScopeOp := 0x10
TermList := Nothing | <TermObj TermList>
...
</source>
Every AML object is either "implicit-length, fixed-length", "implicit-length, nested", or "explicit length". '''ScopeOp''' is a simple example of an "implicit-length, fixed-length" object: it's one byte long and wherever it appears, will only be one byte long. '''TermList''' is an example of an "implicit-length, nested" object. It's a recursively defined list, and who knows how long it might be. There's a problem with implicit-length, nested objects. What if two are nested within each-other? For example:
<source lang="c">
TermObj TermObj TermObj
</source>
Is this a single TermList containing one TermObj? Or is it a single TermList containing one TermObj and another TermList, which itself contains two TermObjs?
To resolve this confusion, "implicit length, nested" objects appear within "explicit length" objects. '''DefScope''' is an example of an "explicit length" object. The '''PkgLength''' object tells you how many more bytes in the AML bytecode (counting the PkgLength field itself) are part of the explicit length object. This way you know when to stop parsing any implicit-length, nested objects like TermLists.
This isn't a huge problem for your parser though. A parsing function for an "implicit length, nested" object like '''TermList''' needs to take an argument that tells it how many bytes to parse. This number is determined by the previous '''PkgLength''' parser.
[[Category:ACPI]]
|