Patent Application
20060174231
Embodiments of the present invention relate to programming languages. More specifically, embodiments of the present invention relate to using code written in a language that is not native to the computer system to communicate with a procedure written in a programming language that is native to the computer system.
Ideally, implementation of a particular interface can be done either all in the native language or all in the non-native language. For example, ACPI code was written by firmware developers in AML. This code was interpreted by the operating system 140. However, the AML instruction set that was used for creating the code is limited. Some of the functionalities need assistance from the native instructions. This creates a problem with the two parts 120, 130 of the firmware needing to communicate with each other.
One way to enable the two parts of the firmware 120, 130 to communicate involved a platform management interruption mechanism for asynchronously invoking the firmware in native language 130. However, the firmware code running in the platform management interruption is executing behind the back of the operating system. If not carefully managed, this solution at times resulted in the computer system 100 crashing or hang because the operating system 140 may lose timer ticks that is crucial for its operation.
Therefore for these and other reasons, there is a need for an apparatus and a method for allowing the firmware in non-native language 120 to communicate with the firmware in native language 130. This would overcome the limitation of the instruction set in non-native language 120. Further, there is a need for an apparatus and a method for allowing the firmware in non-native language 120 to communicate with the firmware in native language 130 that does not result in the computer system 100 crashing or hang.
Embodiments of the present invention pertain to methods and apparatuses for using code written in a language that is not native to the computer system to invoke a procedure written in a programming language that is native to the computer system are described. In one embodiment, code is created to call a procedure in a manner that cooperates with an operating system that the code executes on. The code is written in a programming language that is not native to the computer system and the procedure is written in a programming language that is native to the computer system. The execution of the code to call the procedure is enabled by transmitting the code to an interpreter that is enabled to interpret the code written in the programming language that is not native. The interpreter is associated with the operating system.
The accompanying drawings, which are incorporated in and form a part of this specification, illustrate embodiments of the invention and, together with the description, serve to explain the principles of the invention:
The drawings referred to in this description should not be understood as being drawn to scale except if specifically noted.
Reference will now be made in detail to various embodiments of the invention, examples of which are illustrated in the accompanying drawings. While the invention will be described in conjunction with these embodiments, it will be understood that they are not intended to limit the invention to these embodiments. On the contrary, the invention is intended to cover alternatives, modifications and equivalents, which may be included within the spirit and scope of the invention as defined by the appended claims. Furthermore, in the following description of the present invention, numerous specific details are set forth in order to provide a thorough understanding of the present invention. In other instances, well-known methods, procedures, components, and circuits have not been described in detail as not to unnecessarily obscure aspects of the present invention.
As depicted in
The firmware 210 has a part 220 that is written in a non-native language and another part 230 that is written in a native language. Examples of languages that are native to the computer system 200 include, but are not limited to, BIOS, SAL, and EFI. Examples of languages that are not native to the computer system 200 include, but are not limited to, AML.
The CCP 224 is associated with the firmware in non-native language 220 and, therefore, is written in a non-native language, according to one embodiment, whereas the procedure 232 is associated with the firmware in native language 230 and, therefore, is written in a native language, according to another embodiment. To enable the two parts 220, 230 of the firmware 210 to communicate, the operating system 240 can intermediate communications between the CCP 224 and the procedure 232, for example, by using the optional code creator 222, the code transmitter 226, the interpreter 244 and the call back routine 242, among other things.
The code creator 222 can be software that creates the CCP 224. Alternatively, a program developer can manually perform the function of the code creator 222 by manually writing the CCP 224.
The CCP 224 can be written in a language that is not native to the computer system 200, such as AML. Therefore, according to another embodiment, the CCP 224 can be what is known as an ACPI control method. Further, the CCP 224 can be interpreted.
Since the CCP 224 is used for calling the procedure 232, the CCP 224, according to one embodiment, can include instructions for communicating with the procedure 232. More specifically, since the procedure 232 can be in a native language, such as SAL, the CCP 224 can include instructions that conform to the calling convention of the native programming language that the procedure 232 uses, such as the IA-64 Software Calling Convention that a procedure 232 written in SAL uses. In this case, the example code for creating a buffer 300 (
Example code 410 (
The code transmitter 226 can transmit the CCP 224 to the interpreter 244, which is associated with the operating system 240. As a result of the interpreter 244 interpreting the CCP 224, the value “x‘81’” to the object “_ECO” associated with code 410 can result in the call back routine 242 being invoked. The interpreter 244 can be written in various programming languages, such as C, and compiled to use the instruction set that the computer system 200 uses.
The call back routine 242 can be an operating system 240 level routine that can be registered with the operating system 240. For example, if the operating system 240 is Windows™, then the call back routine 242 can be written using Windows™ functions and registered with the Windows™ operating system.
The call back routine 242 can retrieve the values from the input parameters 320 (
The procedure 232 can retrieve the values that the call back routine 242 passed to it (originating from the input parameters 320) and perform whatever processing is requested. The input parameters 320 (refer to example code 410) can designate the type of processing that the procedure 232 is requested to perform. After the procedure 232 performs processing to satisfy the request based on the values the call back routine 242 passed to the procedure 232, the procedure 232 can return control back to the call back routine 242.
More specifically, the call back routine 242 can store the values that procedure 232 passed to the call back routine 242 into output parameters 330 (
As described above, certain processes and steps of the present invention are realized, in one embodiment, as a series of instructions (e.g., software programs such as code creator 222, CCP 224, code transmitter 26, call back routine 242, procedure 232, etc.) that reside within computer readable memory of a computer system 200 and are executed by a CPU associated with computer system 200. When executed, the instructions cause the computer system 200 to implement the functionality of the present invention as described below.
For the purposes of illustration, the discussions of flowcharts 500, 600 shall refer to the structures and/or elements depicted in
In step 510, code to call a procedure in a manner that cooperates with an operating system is created. For example, the CCP 224 can be created by a code creator 222 or by a program developer, as already described herein. Further, examples of code 300 and 400 can be used for creating the CCP 224. Examples of code 300 and 400 are written in a programming language, such as EFI, that is not native to the computer system 200.
More specifically the CCP 224 can be written to create a buffer from non-volatile storage. For example, the CCP 224 can be written with input parameters 320 to pass values to the procedure 232 and output parameters 330 for receiving values from the procedure 232. Further, the CCP 224 can be written with example code 400 for storing values into the buffer (e.g., example code 405) and invoking the procedure 232 (e.g., example code 410).
In step 515, the execution of the code to call the procedure is enabled by transmitting the code to an interpreter. For example, a code transmitter 226 can transmit the CCP 224 to an interpreter 244 that is associated with the operating system 240. The interpreter 244 can execute (for example by interpreting) the CCP 224, as illustrated by flowchart 600 below, which results in the procedure 232 being invoked.
Referring to
In step 605 of
In step 610, a buffer is created. For example, as already stated, the CCP 224 can include instructions, such as that depicted in example code 300, for creating a buffer from non-volatile storage. The interpreter 244 can cause the CCP 224 to create the buffer by interpreting the instructions, such as those depicted in example code 300, for creating the buffer.
In step 615, values are stored into the buffer's input parameters. For example, as already stated, the CCP 224 can include instructions, such as that depicted in example code 405 (
In step 620, the call back routine is invoked. For example, as already stated, the CCP 224 can include an instruction, such as that depicted in example code 410 (
The call back routine 242 can retrieve the values from the input parameters 320 (
At step 630, the procedure is invoked. For example, the procedure can retrieve values that the call back routine 242 passed to it (originating from the input parameters 320) and perform whatever processing is requested. The input parameters 320 can be used to designate the type of processing that the procedure 232 has been requested to perform. After performing the requested processing, the procedure 232 can communicate information pertaining to the requested processing by passing values back to the call back routine 242.
In step 635, the call back routine stores the values that the procedure 232 passed into the buffer's output parameters. For example, the call back routine 242 can store the values that procedure 232 passed to the call back routine 242 into output parameters 330 (
In step 640, the CCP processes the output parameters. For example, the CCP 224 can retrieve the values stored in the output parameters 330 and determine from those values what, if any, processing needs to be performed.
At step 645, processing completes.
A cooperative model between the firmware 210 and the operating system 240 is provided by using a call back routine 242, among other things, that is associated with the operating system 240, to intermediate communications between the CCP 224 and the procedure 232. Thus, the firmware in non-native language 220 is enabled to communicate with the firmware in native language 230 without resulting in the computer system 200 crashing or hang.
Using a CCP 224, among other things, that conforms to the native language calling convention that the firmware in native language 230 uses enables the firmware in non-native language 220 to communicate with the firmware in native language 230 without limiting the instruction set that the CCP 224 can use for communicating with the firmware in native language 230.
