From owner-freebsd-current Tue Aug 27 15: 8:21 2002 Delivered-To: freebsd-current@freebsd.org Received: from mx1.FreeBSD.org (mx1.FreeBSD.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 8A4A537B400 for ; Tue, 27 Aug 2002 15:08:13 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id CA6A643E3B for ; Tue, 27 Aug 2002 15:08:11 -0700 (PDT) (envelope-from robert.moore@intel.com) Received: from fmsmsxvs041.fm.intel.com (fmsmsxvs041.fm.intel.com [132.233.42.126]) by mail2.hd.intel.com (8.11.6/8.11.6/d: solo.mc,v 1.42 2002/05/23 22:21:11 root Exp $) with SMTP id g7RM8Am29727 for ; Tue, 27 Aug 2002 22:08:11 GMT Received: from FMSMSX017.fm.intel.com ([132.233.42.196]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002082715040320736 ; Tue, 27 Aug 2002 15:04:07 -0700 Received: by fmsmsx017.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 15:04:49 -0700 Message-ID: From: "Moore, Robert" To: "'Terry Lambert'" , "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 Date: Tue, 27 Aug 2002 15:04:43 -0700 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain Sender: owner-freebsd-current@FreeBSD.ORG Precedence: bulk List-ID: List-Archive: (Web Archive) List-Help: (List Instructions) List-Subscribe: List-Unsubscribe: X-Loop: FreeBSD.ORG 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