Date: Tue, 27 Aug 2002 15:04:43 -0700 From: "Moore, Robert" <robert.moore@intel.com> To: "'Terry Lambert'" <tlambert2@mindspring.com>, "Moore, Robert" <robert.moore@intel.com> Cc: "'Mitsuru IWASAKI'" <iwasaki@jp.FreeBSD.org>, yb@sainte-barbe.org, acpi-jp@jp.FreeBSD.org, current@freebsd.org, "Grover, Andrew" <andrew.grover@intel.com> Subject: RE: [acpi-jp 1735] Re: Call for testers: acpica-unix-20020815 Message-ID: <B9ECACBD6885D5119ADC00508B68C1EA0D19B71C@orsmsx107.jf.intel.com>
next in thread | raw e-mail | index | archive | help
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. Bob -----Original Message----- From: Terry Lambert [mailto:tlambert2@mindspring.com] Sent: Tuesday, August 27, 2002 2:54 PM To: Moore, Robert Cc: 'Mitsuru IWASAKI'; yb@sainte-barbe.org; acpi-jp@jp.FreeBSD.org; current@freebsd.org; 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: assumption? 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 have. "Anything that works is better than anything that doesn't" -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9ECACBD6885D5119ADC00508B68C1EA0D19B71C>