I think you are missing something:

1) BIOS vendor writes ASL
2) BIOS vendor compiles ASL to AML byte-code
3) BIOS vendor puts AML into BIOS
4) OS gets AML from the BIOS
5) OS interprets AML

The error you are experiencing is in (5).  There is no return statement in
the original ASL, so there is no return opcode in the AML.  The AML
interpreter has nothing to "return" and things fall apart.

However, the error was written in (1) and should have been caught by the ASL
compiler in (2).   However, there are other ASL compilers out there that do
not perform such error-checking.  This is how these kinds of problems creep
into the BIOS AML code.


-----Original Message-----
From: Terry Lambert [mailto:[EMAIL PROTECTED]] 
Sent: Tuesday, August 27, 2002 2:54 PM
To: Moore, Robert
[EMAIL PROTECTED]; Grover, Andrew
Subject: Re: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815

"Moore, Robert" wrote:
> Well, the *real* problem is that there is no Return AML opcode in the
> control method and the interpreter therefore does not return a value.
> However, to answer your question with a question:
> Would you ask a C compiler, or any other compiler for that matter, to
> actually *GUESS* at what you had intended to be the return value of a
> function?

Is this a trick question?

If I had to write my source code to read-only media, with no
way to tell whose compiler was going to be used on it, and had
no way to fix it afterwards, I think the answer would have to
be "yes".  8-) 8-).

FWIW, there's historical precedent for this: the DEC VAX/VMS
C compiler would imply semicolons for the programmer that
forgot them, and a couple of other similar "fixups", issue a
warning, but the resulting code would run "as the programmer
most likely intended", rather than not generating a running
program at all.

The issue here is one of syntactical vs. grammatical ambiguity;
if the only choices are between two possible outcomes, and one
of them is a failure to operate at all, while the other is to
operate, but potentially incorrectly.  The upshot is that ir
can't hurt, and it might help:

                        no              yes
grammar error   |       FAILS   |       FAILS   |
syntax error    |       FAILS   |       WORKS   |

So the worst possible outcome in the failure case is that it
fails -- which it already does, without the assumption -- and
the best possible outcome is that it succeeds when it wouldn't

"Anything that works is better than anything that doesn't"

-- Terry

To Unsubscribe: send mail to [EMAIL PROTECTED]
with "unsubscribe freebsd-current" in the body of the message

Reply via email to