Date: Tue, 27 Aug 2002 15:51:07 -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: <B9ECACBD6885D5119ADC00508B68C1EA0D19B71D@orsmsx107.jf.intel.com>
next in thread | raw e-mail | index | archive | help
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
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?B9ECACBD6885D5119ADC00508B68C1EA0D19B71D>