From owner-freebsd-current Tue Aug 27 15:51:28 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 E100737B400 for ; Tue, 27 Aug 2002 15:51:23 -0700 (PDT) Received: from mail2.hd.intel.com (hdfdns02.hd.intel.com [192.52.58.11]) by mx1.FreeBSD.org (Postfix) with ESMTP id 069C343E6E for ; Tue, 27 Aug 2002 15:51:23 -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 g7RMpMP19772 for ; Tue, 27 Aug 2002 22:51:22 GMT Received: from fmsmsx29.FM.INTEL.COM ([132.233.42.29]) by fmsmsxvs041.fm.intel.com (NAVGW 2.5.2.11) with SMTP id M2002082715502909094 ; Tue, 27 Aug 2002 15:50:29 -0700 Received: by fmsmsx29.fm.intel.com with Internet Mail Service (5.5.2653.19) id ; Tue, 27 Aug 2002 15:51:16 -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:51:07 -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 We have to look at each of these on a case-by-case basis. It turns out that it is purely an accident that the code works on windows; by some fluke of their AML interpreter, the value gets returned. Because of architectural differences, the CA interpreter deletes everything that isn't needed before the method returns -- and therefore any "implied" return object is long gone by the time the method exits. Toshiba knows about this problem and has agreed to fix it in it's various BIOSs Bob -----Original Message----- From: Terry Lambert [mailto:tlambert2@mindspring.com] Sent: Tuesday, August 27, 2002 3:40 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: > 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. As a consumer of 1-3, I have zero opportunity to fix the problem before item #4. Since use of a trademark or other legal baseball bat (8-)) won't get the code in the BIOS fixed, the only way to make things work in the short term is to either intervene in step #4 or in step #5. In the long term, it'd probably be a good idea to release the source code for the ASL-to-AML compiler under a strict license, and displace all the ASL compilers that fail to do error checking, so problems like this can't arise in the first place. I guess I would like to know if the AML can be recognized as defective by the interpreter, and modify it at step #4 before interning it for interpretation; Windows has to have *some* way of dealing with this, short of supplying replacement AML for every PC ever manufacturered, right? -- Terry To Unsubscribe: send mail to majordomo@FreeBSD.org with "unsubscribe freebsd-current" in the body of the message