I can't believe that there are so many bugs in ACPI spec

[nbdd0121]

They just left over some grammar rules in AML spec (chapter 20 in latest spec) ! The rules exist in older spec but suddenly they disappeared
For example, in older spec

NamedObj := DefBankField ... DefField ... DefThermalZone

Now:

NamedObj := DefBankField ... DefThermalZone

However the rule for DefField is still there! Cannot believe it! What's worst is that the Field is available in ASL spec, which is one chapter before the AML spec!

I nearly went crazy because my code encounters unexpected input, after I evaluate the binary and the source code, I found that the spec is wrong! The spec forget to include these grammar rules!

[bace]

If you're writing an AML parser, you should probably make a page on the Wiki with all the errors in that part of the ACPI specification that you find. I'm planning on making one, but that'll be a month or two down the line (probably), so if you could sort out all the junk now, that would be very helpful to me and anyone else trying. The UEFI Forum appears to managing the spec, so you could send them the error here: http://www.uefi.org/contact_us.
I'm not really surprised there are errors in the specification though, after all it's almost 1000 pages; just because it's written by big corporations doesn't mean there won't be human mistakes!

[nbdd0121]

If you're writing an AML parser, you should probably make a page on the Wiki with all the errors in that part of the ACPI specification that you find. I'm planning on making one, but that'll be a month or two down the line (probably), so if you could sort out all the junk now, that would be very helpful to me and anyone else trying. The UEFI Forum appears to managing the spec, so you could send them the error here: http://www.uefi.org/contact_us.
I'm not really surprised there are errors in the specification though, after all it's almost 1000 pages; just because it's written by big corporations doesn't mean there won't be human mistakes!

Thanks for your advice. I am sorting out AML details according to the description of ASL. Despite some minor errors in the specification, the biggest problem is that the spec is not clear enough - only grammar rules with few descriptions. I am willing to share the information if I have some progress.

[SpyderTL]

I tried writing an AML parser in C# a few years ago, and after a few weeks of fighting with it, I finally gave up. The problem is (as far as I can remember), the encoding of the language itself is ambiguous. I kept running into situations where there was absolutely no programmatic way to determine where one expression-tree ended, and the next started.

Maybe one day, I'll get back into it, but I've put it way down on my TODO list.

[nbdd0121]

The problem is (as far as I can remember), the encoding of the language itself is ambiguous. I kept running into situations where there was absolutely no programmatic way to determine where one expression-tree ended, and the next started.

True. Sometimes you'll need the PkgLength to help you to determine where one expression-tree ended, but sometimes you can't do that without evaluating whole program first - in AML, the method invocation and normal object reference are the same - you have to find the object first, then you can know whether there are arguments following it, and if so, how many arguments are following it. This is the biggest challenge.

[tom9876543]

Linus Torvalds has the best ACPI quote:

Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.

Intel has f#$ked the design of their products on more than one occasion:
iAPX 432 Processor
286 Processor
Pentium 4 Processor
RAMBUS RAM
Itanic Processor
and of course ACPI

[nbdd0121]

Linus Torvalds has the best ACPI quote:

Modern PCs are horrible. ACPI is a complete design disaster in every way. But we're kind of stuck with it. If any Intel people are listening to this and you had anything to do with ACPI, shoot yourself now, before you reproduce.

lol. To me it's very true, and so do the designs of M$'s products sometimes.

[johnsa]

So I've also been having a go at writing an aml parser.. apart from the lack of clarity in the spec ( a lot of which can be overcome by generating sample asl files and compiling them to AML ) the following has occurred to me:

1.) IASL is NOT a compiler, it's a translator.. the resulting AML still contains un-evaluated expressions (granted in prefix order).
2.) ASL allows forward references, so a multi-pass approach is required.
3.) The problem with the aml is that due to it's nature you're not actually writing an interpreter but rather a bizarre combination of compiler/interpreter.. parts of the compilation depend on actually executing code, while some of the execution depends on the compilation (for example evaluation of symbols)
4.) In general the language is complete cr*p and the following is totally valid and compilable ASL:

Code: Select all

DefinitionBlock ("test.aml", "DSDT", 2, "DELL  ", "IVB-CPT", 0x00000000)
{
	If(SS1)
	{
		Name(SS2,1)
	}
	
	If(SS2)
	{
		Name(SS1,1)
	}
}

I challenge anyone to parse that properly..
The only thing I can assume (as the spec doesn't say) is that the runtime might assume no forward references are valid.. I guess it depends on who wrote the ASL (firmware manufacturer) ?
in which case.. the first If would fail because SS1 isn't defined.. then the second If would also fail because SS2 isn't defined.. so the net result of that code wouldn't be a circular-reference (which would reach maximum passes and fail)
but rather that simply both blocks would be skipped.

[nbdd0121]

2.) ASL allows forward references, so a multi-pass approach is required.

Seems that only Package/Buffer is required to allow forward reference. Basically I store the package and buffer as thunks of code and reparse them after finishes the interpretation.

Code: Select all

DefinitionBlock ("test.aml", "DSDT", 2, "DELL  ", "IVB-CPT", 0x00000000)
{
	If(SS1)
	{
		Name(SS2,1)
	}
	
	If(SS2)
	{
		Name(SS1,1)
	}
}

I believe that's a fatal error in runtime, since SS1 is not defined. I don't know why the compiler let it passes the translation, but certainly this code is wrong.

[johnsa]

Well i'm glad someone agrees that is some rubbish invalid code.. not sure how it's allowed to compile in that state.. probably because "compiler" is a very loose term when used with ASL

With regards to forward referencing do you mean that entries inside a package/buffer declaration can be forward referencing or that provision must be made for a package itself to be forward referenced?
So then the assumption then is that everything else should be defined (symbols created) in declaration order (ie: scopes, name)

So for some examples:

Code: Select all

/* This should be valid because root and _SB_ are predefined. */

        Name(\_SB_.Bob,1)   

/* This sort of thing should be invalid because the block/scope hasn't been declared yet... however it compiles anyway.... */

	Name(\_SB_.DEV0.BOB,1)
	Scope(\_SB_)
	{
		Device(DEV0)
		{
			Name (_HID, "PNP0C14" /* Windows Management Instrumentation Device */)  // _HID: Hardware ID
		}
	}	

[jnc100]

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.

However, I have not encountered this as a problem if you only execute what you need to. Particularly:

1) Have some sort of object that defines names as an array of 4 byte strings (for the individual scope elements) - this allows you to easily apply transforms e.g. '^' to it to get a new object defining a new name.
2) Have a hash table mapping names to objects
3) Have a function which executes an arbritrary code block by interpreting the opcodes one at a time, given a start offset and end offset.
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.

Before I realized this, I was attempting to tokenize the entire DSDT block first, which certainly led to lots of forward references.

Also note that it is perfectly valid to define any name before a Scope statement defining its parent.

As regards your SS1/SS2 example above, note that If(SS1) does not mean 'if SS1 is defined' but rather execute SS1 (if it is a variable get its value, if its a field get the location of memory it points to, if a method execute it etc) and then interpret its result as an integer and only execute the code block if it is non zero.

Regards,
John.

[johnsa]

Also note that it is perfectly valid to define any name before a Scope statement defining its parent.

It's being defined not just before opening it's parent scope but before the device (block) it belongs to.

As regards your SS1/SS2 example above, note that If(SS1) does not mean 'if SS1 is defined' but rather execute SS1 (if it is a variable get its value, if its a field get the location of memory it points to, if a method execute it etc) and then interpret its result as an integer and only execute the code block if it is non zero.

Regards,
John.

Execute it / get it's value is much the same, if it's not defined.. how can you execute it and get's value (as a variable) and the two If conditions preclude the parser from ever evaluating SS1 and SS2 (unless you assume any undefined variable=0, any undefined method returns(0)).

[jnc100]

Also note that it is perfectly valid to define any name before a Scope statement defining its parent.

It's being defined not just before opening it's parent scope but before the device (block) it belongs to.

This is perfectly valid. If you don't treat the namespace as a tree it becomes easier to implement.

As regards your SS1/SS2 example above, note that If(SS1) does not mean 'if SS1 is defined' but rather execute SS1 (if it is a variable get its value, if its a field get the location of memory it points to, if a method execute it etc) and then interpret its result as an integer and only execute the code block if it is non zero.

Regards,
John.

Execute it / get it's value is much the same, if it's not defined.. how can you execute it and get's value (as a variable) and the two If conditions preclude the parser from ever evaluating SS1 and SS2 (unless you assume any undefined variable=0, any undefined method returns(0)).

Apologies, I misunderstood what you were claiming. The ASL code as provided should spawn an error if it is the only thing in your DSDT (ACPICA would throw an error here too). Could you provide the entire DSDT so I could check it against my interpreter?

Regards,
John.

[johnsa]

Code: Select all

DefinitionBlock ("test.aml", "DSDT", 2, "DELL  ", "IVB-CPT", 0x00000000)
{
	If(SS1)
	{
		Name(SS2,1)
	}
	
	If(SS2)
	{
		Name(SS1,1)
	}
	
	Name(\_SB_.DEV0.BOB,1)
	
	Scope(\_SB_)
	{
		Device(DEV0)
		{
			Name (_HID, "PNP0C14" /* Windows Management Instrumentation Device */)  // _HID: Hardware ID
		}
	}	
	
}

There is one of my sample asl files.. (for testing), it compiles with IASL.

[jnc100]

Ah, so its one you wrote (rather than extracted from a Dell machine)? Yes, its badly formed and should throw an error when interpreted. It is not iasl's job to catch this sort of error as it doesn't know what state the namespace would be in before this code was executed. There may, for instance, have been other code executed first which did define SS1 etc.

It is analogous to the following in C:

Code: Select all

extern int SS1;
extern int SS2;
void Name(int, int);

void func()
{
    if(SS1)
        Name(SS2, 1);

    if(SS2)
        Name(SS1, 1);

    ...
}

which any compiler would process (although you'd get a link error if SS1/2 weren't defined elsewhere).

Regards,
John.