Fast conditional thunk utility

Details Fast conditional thunk utility Fast conditional thunk utility

1998-06-05

2003-04-22

Maung, Zarni (Department: 2126)

Electrical computers and digital processing systems: multicomput

Computer-to-computer data routing

Least weight routing

C717S138000, C717S170000

Reexamination Certificate

active

06553429

ABSTRACT:

TECHNICAL FIELD
This invention relates generally to the field of computer software and, more particularly, to a fast conditional thunk utility employing an assembler-level direct-branch thunk technique.
BACKGROUND OF THE INVENTION
A conditional thunk layer is a software operation that assists in an associated function call, typically by making a decision that affects the function call. In general, a conditional thunk layer immediately precedes its associated function call and makes a decision based on the status of a condition. The result of this decision affects the associated function call, typically by determining which version of the function to call.
For example, a software system may include more than one function that may be called to produce a desired result. In this case, the thunk layer is a precursor operation that determines which function to call. In another example, the software system includes a function that may be called with more than one set of arguments to produce a desired result. In this case, the thunk layer is a precursor operation that determines which arguments to include in the function call.
A first conventional approach implemented in the OFFICE 97 suite of programs, distributed by MICROSOFT Corporation, performs conditional thunk decisions through a “C-level” conditional thunk function. This type of thunk layer is referred to as a “thunk function” to indicate that the thunk decision is implemented through a “C-level” function call. Because the thunk function immediately precedes its associated application program interface (API) function call, this approach results in a duplication of function calls.
Moreover, the added thunk function call alters the parameter passing utility, such as the stack, from the precise condition desired for the ensuing API function call. For this reason, the parameter passing utility must be returned to the condition desired for the API function call after the thunk function call. For a non-thunked function call requiring “X” instructions, this duplication of stack conditioning burdens the processor with “2X+2” instructions for a conditionally-thunked version of the function call. The OFFICE 97 solution checks the thunk condition for each API function called and, thus, is useful in circumstances in which the thunk condition can vary relatively frequently while the client program is running.
A second conventional approach implemented in the ACCESS 97 program, also distributed by MICROSOFT Corporation, performs conditional thunk decisions by loading a look-up table with a pointer to a memory address for each conditionally-thunked API function call. Each entry in the table points to the appropriate thunk code for the function call. That is, the thunk conditions are checked at start up or when the ACCESS 97 program is loaded, and the look-up table is populated with the appropriate pointers for the API function calls. The look-up table may be subsequently refreshed as needed to account for changes in the thunk conditions. Thus, the ACCESS 97 solution is typically used in circumstances in which the thunk conditions can be expected to change less frequently than the look-up table will be referenced. For example, the ACCESS 97 is particularly advantageous when the thunk conditions are invariant, or vary relatively infrequently, while the client program is running.
Because the look-up table is populated with pointers to API functions, this type of branch is referred to as an “unconditional indirect” branch. The branch is “unconditional” because the look-up table contains only one possible target location for the jump. Thus, a condition does not have to be checked to select among alternative target locations for the jump at the time the branch is encountered. The branch is “indirect,” however, because the look-up table must be referenced to determine the target location for the jump. In other words, a pointer must be “indirected” or “de-referenced” to determine the branch target.
The ACCESS 97 approach encounters drawbacks because typical processors, such as the INTEL PENTIUM PRO processor and related models, handle certain indirect branches inefficiently. More specifically, the processor cannot always determine where the branch will lead (i.e., the instruction at the target address of the indirect branch) until it reads the entry in the look-up table, which must be loaded from memory. This is because the processor utilizes a Branch Target Buffer (BTB) that includes only 512 entries. Although the processor may reference the BTB to correctly predict the target address for an encountered branch, the BTB only stores the target addresses for the most recent 512 branches encountered. The processor has no mechanism to correctly predict the target address for an indirect unconditional branch that is not among the most recent 512 branches encountered.
For relatively large program modules, such as MICROSOFT OFFICE, branches not reflected in the BTB may be encountered frequently. For these branches, the look-up table must be reference to determine the correct target address for the branch. While the entry is being read, the processor typically pre-processes future instructions using a prediction of the next instruction. As it turns out, this prediction is almost always wrong for branches that are not reflected in the BTB. This is because the next instruction will be located at the address from the look-up table, which has not yet been read. The processor's pre-processing algorithm, on the other hand, usually predicts the next instruction to be the instruction immediately following the indirect branch instruction. This prediction is almost always incorrect because, if this was not the case, the look-up operation to determine the target address of the indirect branch would not have been necessary in the first place. The time elapsed until the successful execution of the instruction at the target location following an incorrect prediction leading to performing unwanted instructions is sometimes referred to as a “processor stall.”
Thus, there is a need for a conditional thunk methodology that avoids duplicative stack manipulation, such as that produced by using a “C-level” function call to implement a conditional thunk routine. There is a further need in the art for a conditional thunk methodology that avoids an indirect branch, such as a reference to an address in a look-up table stored in system memory, to determine the target address of a conditional thunk routine.
SUMMARY OF THE INVENTION
The present invention meets the needs described above in a fast conditional thunk utility. The improved conditional thunk layer is referred to as a “utility” to indicate that, unlike certain previous conditional thunk layers, it is not implemented using a “C-level” function call. Nor is the conditional thunk layer implemented using a look-up table stored in system memory. Instead, the invention implements a conditional thunk utility through an assembler-level direct-branch technique.
The fast conditional thunk utility is typically employed when a client program, such as an application program, accesses an application program interface (API) exposed by a host program, such as the operating system. The primary advantage of the invention is a significant improvement in the processing speed or performance of the conditional thunk decision. Another advantage is a significant reduction in the size of the code required to implement the conditional thunk layer, which reduces the memory requirement of the client program.
In a first configuration, referred to as a “condition-check” alternative, the conditional thunk utility performs a condition check followed by a direct-branch jump. Because the condition-check methodology is implemented using an assembler-level direct-branch technique, the conditional thunk utility does not utilize the parameter passing utility, typically the stack, to queue the arguments of a function call. Thus, the stack is not altered from its desired condition just prior to executing the API function call. The condition-check altern

Affiliated with

Also associated with

Rating

Fast conditional thunk utility does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Fast conditional thunk utility, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Fast conditional thunk utility will most certainly appreciate the feedback.

Rate now

Comments { 0 }

Profile ID: LFUS-PAI-O-3104629