US 5,623,617 AGrant
Method for Decoding Sequences of Guest Instructions for a Host Computer
Issue Date:1997-04-22
•18 Claims
•9 Drawing Sheets
Abstract
Emulator performance can be improved by recognizing repeated sequences of the same instruction, or commonly groups of instructions. For example, it is very common to see a three instruction sequence of MOVEM, UNLK A6, and RTS instructions for a 68020 processor in procedure exit code. By looking for these sequences, and combining the operations performed by the separate sequences, overhead of decoding and dispatching the individual instructions in the sequence can be eliminated, and performance improved. Common instruction sequences or repeated sequences in a guest program are detected during emulation of the guest program on a host processor, and performance of the emulation optimized based on the detected sequences. Thus, the emulation logic comprising host instructions embedded within a particular emulation program for a particular guest instruction, detects a particular sequence of guest instructions and in response to detection of the particular sequence bypasses the dispatch logic for guest instructions within the particular sequence. The sequences detected can comprise repeated guest instructions, or common sequences of two or more than two guest instructions.
Metadata
Assignee
- Apple Computer, Inc.
Inventor
- Gary G. Davidian
Application Information
Application Number:US 478426&
Filing Date:1995-06-07
Priority Date:1993-05-07
Art Unit:235
Classifications
IPC:
G06F 9455
Field of Search:
395375;800;500
Patent Drawings (9 sheets)
Description
Background of the Invention
1. Field of the Invention
The present invention relates to the emulation of software written for a given computer on a different computer which executes a different set of instructions; and more particularly to a system for decoding guest instructions into host instructions by the host computer.
2. Description of the Related Art
Central processing units for computers are designed to execute a specific set of instructions unique to a particular central processing unit. Thus, a microprocessor in one family, such as the Motorola 68000 family, executes software written in a language unique to the 68000 family, while processors in the Intel 80286 family execute software written with another language which is unique to that family of processors. A need often arises to execute software written for a particular processor in a host processor that utilizes a different language. For the purposes of this application, the language for the host CPU is based on "host instructions", while the language for other CPUs are referred to as "guest instructions".
Because of the large body of software written for existing processors, such as the Motorola 68000 series, new processors which are designed often attempt to emulate the 68000 series processors in software. This emulation process involves first decoding the 68000 series guest instructions into a sequence of host instructions which accomplish the result intended by the guest instruction. The routines needed to emulate a given instruction are stored in a host addressable table. For instance, in one prior art system, each guest instruction is used to generate a jump table pointer which points to a table that includes one entry for each of the possible combinations of operational code and addressing mode for a guest instruction. The jump table stores a pointer to the particular code segment adapted to a particular code combination. See, ARRANGEMENT FOR SOFTWARE EMULATION, International Application No. PCT/GB87/00202; invented by MacGregor.
A disadvantage of this prior art technique arises because of the delay involved in composing a jump table pointer based on the guest instruction, looking up a second pointer in the jump table, and then accessing the emulation segment. Because of data access latencies and the like, this can significantly slow down the emulation routine.
At least one prior art system based upon a jump table includes an ability to detect common opcode sequences, so that optimized emulation programs may be used for such sequences. This prior art system is based on eight bit opcodes, and forms a 16 bit index using the two 8 bit opcodes in the sequence. Using the 16 bit index, a jump table entry can be found to an optimized emulation program. This approach works well with eight bit opcodes, which result in an index of manageable size. However for current 16 bit opcode systems, this approach would require a 32 bit index--or with over 4 billion possible entries. The prior art has not provided a practical technique for optimizing the emulation of commonly occurring guest instruction sequences for longer opcodes.
Accordingly, it is desirable to provide an emulation system which enhances the performance of the host processor in emulation of guest instructions sequences particularly suited to longer opcodes of current processor architectures.
Summary of the Invention
Emulator performance can be improved by recognizing repeated sequences of the same instruction, or commonly used groups of instructions. For example, it is very common to see a three instruction sequence of MOVEM, UNLK A6, and RTS instructions for a 68020 processor in procedure exit code. By looking for these sequences, and combining the operations performed by the separate sequences, overhead of decoding and dispatching the individual instructions in the sequence can be eliminated, and performance improved. The present invention provides a technique in which common instruction sequences or repeated sequences in a guest program can be detected during emulation of the guest program on a host processor, and performance of the emulation optimized based on the detected sequences. According to the present invention, this detection is performed in the execution of the emulation program for the first instruction in the sequence. This approach does add some overhead to the general case of the first instruction when it is not followed by the expected second instruction. However, these optimizations improve performance if the probability of this sequence occurring is very high in the guest program being emulated.
Accordingly, the present invention can be characterized as a system for decoding guest instructions in a host processor. The system includes a guest program store in host addressable memory to store at least one program of guest instructions. An emulation program store in the host addressable memory includes a set of emulation programs which comprise host instruction routines for respective particular guest instructions. Further, dispatch logic is coupled with the guest program store and the emulation program store to dispatch emulation programs in response to guest instructions in a guest instruction program, and in response to the emulation programs in the emulation program store. Emulation logic comprising host instructions embedded within a particular emulation program for a particular guest instruction, detects a particular sequence of guest instructions and in response to detection of the particular sequence bypasses the dispatch logic for guest instructions within the particular sequence. The sequences detected can comprise repeated guest instructions, or common sequences of two or more than two guest instructions.
According to a further aspect of the invention, both the dispatch logic and the emulation logic which detects guest instruction sequences are based on host instructions embedded within the emulation programs.
Further, the decoding system is further optimized according to the present invention by dividing the emulation program store into a dispatch store and an emulation routine store. The dispatch store is placed in host addressable memory, and stores a set of dispatch entries. Each dispatch entry includes a plurality of host instructions of the emulation program corresponding to a particular guest instruction. The emulation routine store is placed in host addressable memory and includes a set of emulation entries beginning at corresponding emulation table addresses. Each emulation entry in the set includes a host instruction routine for the particular emulation program. The plurality of host instructions in the dispatch entries include a host jump instruction which causes a jump upon execution by the host processor to an emulation table address of a corresponding emulation entry in the emulation routine store. The emulation entries include host instructions which upon execution by the host processor form an emulation program address to a dispatch entry in response to a next guest instruction, and jump directly to the dispatch table address. Thus, according to this optimization, emulation programs in the emulation program store comprise a dispatch table entry and a host instruction routine in the emulation routine store. Further, the dispatch logic and the logic for detecting guest instruction sequences are embedded in the host instruction routine stored in the emulation routine store.
According to this embodiment, the host system includes a guest instruction pointer store for a guest instruction pointer indicating a guest instruction address, a prefetched guest instruction store for a guest instruction read from the program of guest instructions in response to the guest instruction pointer, and an emulation program pointer store for an emulation program address formed in response to the guest instruction read from the prefetched guest instruction store. Also, the emulation program includes a first macro which upon execution by the host processor forms an emulation program address in the emulation program pointer store in response to the guest instruction in the prefetched guest instruction store. A second macro of host instructions reads the next guest instruction from an address indicated by the guest instruction pointer into the prefetched guest instruction store. A third macro of host instructions causes a jump to the emulation program indicated by the emulation program address in the emulation program pointer store. A fourth macro embedded within the emulation routine bypasses at least the third dispatch segment upon detection of the particular sequence of guest instruction.
Accordingly, a decoding technique for emulating a guest program of instructions in a host processor is provided. The system includes an optimized technique for dispatching emulation programs in response to guest instructions, in combination with the ability to detect common sequences of guest instructions. Upon detection of common sequences, optimized emulation programs can be executed which bypass the dispatching overhead, and which, where appropriate, optimize the emulation of the instruction sequence. The improved emulator optimizes common instruction sequences in the guest programs being emulated, even for guest instructions which comprise long opcodes (e.g., 16 bits).
Other aspects and advantages of the present invention can be seen upon review of the figures, the detailed description, and the claims which follow.
Brief Description of the Figures
FIG. 1 is a schematic block diagram of a computer system implementing the present invention.
FIG. 2 is a diagram of a dispatch store according to the present invention.
FIG. 3 is a diagram of an emulation routine store according to the present invention.
FIG. 4 is a flow chart illustrating the decoding method according to the present invention.
FIG. 5 illustrates an emulation program according to the present invention.
FIG. 6 illustrates an alternative emulation program according to the present invention.
FIG. 7 is a flow chart of an emulation program which is optimized for a three opcode sequence, which may be common in guest programs.
FIG. 8 illustrates an emulation program according to the present invention for a guest instruction which may be a first instruction of a three instruction sequence of guest instructions.
FIG. 9 illustrates an emulation program according to the present invention for a guest instruction, which may be the first guest instruction in a two opcode sequence.
FIG. 10 illustrates an emulation program according to the present invention for a guest instruction, which may be repeated.
Description of the Preferred Embodiments
A detailed description of preferred embodiments of the present invention is provided with respect to FIGS. 1-10.
I. Emulator System
FIG. 1 illustrates a host processor which is adapted to emulate guest instructions according to the present invention. The host processor includes a host CPU 10 which executes host instructions. Coupled with the host CPU 10 are a set of general purpose registers 11, and a set of special purpose registers 12, implemented as commonly known in the industry as part of an integrated circuit microprocessor, incorporating the CPU 10.
The host CPU 10 is coupled to a system bus 13. The bus is also coupled to input devices such as a keyboard and mouse 14, a display system 15, and a memory system 16 such as a disk drive.
The host processor system also includes host addressable memory, which includes an emulation program store 17, a sequence of guest instructions in a guest program store 18, and other memory 19. The emulation program store 17, according to a preferred embodiment of the present invention, includes an emulation dispatch store 20, and a set of emulation routines 21.
FIG. 2 illustrates the structure of a preferred embodiment of the emulation dispatch store 20. The emulation dispatch store 20 includes a set of instruction pairs, e.g., pair 30, pair 31, pair 32. Each pair includes a host non-jump instruction and a host jump instruction.
According to the preferred embodiment, the dispatch store is an indexed table of 65536 pairs of host instructions, which correspond to the entry points for emulation programs to emulate each of the 65536 possible guest instruction encodings for a Motorola 68020 microprocessor assembly language. The first instruction of the pair will generally perform some operation related to a source operand fetching or addressing. The second instruction of the pair is generally a branch instruction to an emulation routine which resides outside of the dispatch store in the emulation routine store 21. Since each pair of instructions will occupy 8 bytes, the total size of the dispatch store is 512K bytes. The dispatch store may be located, for instance, at addresses (hex) 68000000 through (hex) 6807FFFF.
The alignment of the beginning of the store is important. In a preferred system, the store starts at either the beginning of a 2 Megabyte address boundary, or a 512 Kilobyte address boundary past the 2 Megabyte boundary. By having this 512K byte block aligned onto a 512K byte address, block address translation registers can be used to perform address translation of a fairly randomly accessed block of code and eliminate potential thrashing in translation lookaside buffers.
The 512K byte alignment also allows a single instruction to index the dispatch store using a sixteen bit 68020 opcode multiplied by 8. Thus, a single host instruction can shift a 68020 opcode left by 3 bits (multiplied by 8), and insert it into the address of the base of the table to form the address of a dispatch table entry for that opcode.
By having this table start in the first 1 Megabyte of a 2 Megabyte aligned boundary, where the second 1 Megabyte of addresses will cause an exception if accessed, it is possible to use an additional address bit to assist in the detection of address errors as described below.
As illustrated in FIG. 2, the host CPU 10 executes a host instruction in order to dispatch a guest instruction by accessing the first instruction in an instruction pair in the dispatch store. The first instruction executes, and then a second instruction in the dispatch pair is executed. This second instruction includes a jump instruction which goes to an emulation block in the emulation routine store 21.
FIG. 3 illustrates the implementation of the emulation routine store 21. The emulation routines are allocated to a 64K block of bytes for host instruction routines to which the jump instruction in the dispatch entry branches. In general, the first two host instructions in an emulation program reside in an entry in the dispatch store, while the remaining instructions, which are referred to as emulation routines, reside in the emulation routine block of code. This block may be located, for instance, at addresses (hex) 68080000 through (hex) 6808FFFF.
As above, the alignment of the block of code for the emulation routines is also important. In a preferred system, it needs to start at the beginning with 64K byte boundary.
During emulation, it is frequently desirable to compute the address of a guest instruction within the emulated block, such as by computation of a PC relative address. The host architecture in a preferred system may not provide an instruction to compute a PC relative address. By storing the address of the beginning of the emulation routine block so that it has zeros in the 16 least significant bits in a host register, referred to as code.sub.-- ptr, a computation of the address of any label within this 64K byte block of code can be optimized by using the value in code.sub.-- ptr as a code base by doing an OR immediate, with a 16 bit immediate value as the offset.
Within the 64K byte block of emulation routine code, there is additional attention paid to code alignment. In particular, the emulation blocks are aligned into blocks which match the processor caching routing used to retrieve the code. In a preferred system, a processor cache uses 32 byte cache blocks in a cache line of 64 bytes, and the emulation blocks are packed into aligned 32 and 64 byte blocks.
Thus, as illustrated in FIG. 3, the emulation routine store 21 may include a plurality of emulation routines including emulation block 40, emulation block 41, emulation block 42, emulation block 43, emulation block 44, etc. Each of these blocks 40-44 is either a 32 or 64 byte block.
A particular emulation block, e.g., block 42, is entered by a jump from the dispatch table, and ends with an instruction to dispatch the next guest instruction.
As illustrated in FIG. 3, some emulation blocks may include effective address calculation routines, such as block 43. Such effective address routines are entered by a jump from the dispatch table as described below, and end with a jump to a return address of an emulation block within the emulation routine memory.
FIG. 4 illustrates the emulation decoding process according to the present invention. As mentioned above, the host processor 10 shown in FIG. 1 includes a plurality of special purpose and general purpose registers. The general purpose register disp.sub.-- table stores a pointer to a dispatch table entry. Also, at this point in the decoding sequence, a special purpose register labelled ctr will contain the same value as disp.sub.-- table. A general purpose register labelled pc stores a guest instruction pointer 2 bytes past a current guest instruction. A general purpose register labelled ptefetch.sub.-- data stores a next guest instruction, as indicated at block 50. As mentioned above, the emulation routines include host instructions distributed within the routines to carry out the decoding process. Thus, each emulation program will include a DISPATCH macro, generally 51, which does inter-instruction processes which may be required between guest instructions, and causes a jump to the dispatch table entry indicated by the pointer in register ctr. The emulation program also includes a macro referred to as DECODE1 macro 52, which takes the next guest instruction from the prefetch.sub.-- data register, multiplies that instruction by 8, and inserts the results in the general purpose register labelled disp.sub.-- table so that it forms an address of a dispatch table entry.
A next macro 53 within an emulation program referred to as DECODE2 macro, copies the value in the disp.sub.-- table register to the special purpose register ctr.
A final macro referred to as PREFETCH macro 54 is included within an emulation program. The PREFETCH macro 54 advances the guest instruction pointer in register pc by 2 bytes, then causes a prefetch of the next guest instruction from the address indicated by the pointer in register pc and places the prefetched instruction in the general purpose register prefetch.sub.-- data. The final macro in a given emulation routine is the DISPATCH macro 51. Thus, as illustrated in FIG. 4, an emulation program for a particular guest instruction begins immediately after the jump instruction of the DISPATCH macro 51.
The structures of alternative emulation programs, according to the present invention, are shown in FIGS. 5 and 6. FIG. 5 illustrates the general case. Line 1 is the first instruction INST1 stored in a dispatch entry in the dispatch store. Generally, this is a non-jump instruction relevant to addressing mode of the guest instruction. Line 2 stores the second instruction INST2 stored in the dispatch entry. Generally, this is a jump to a block of code in the emulation routine store.
Line 3 corresponds to the instruction or instructions at the beginning of an emulation block. Within an emulation program, the DECODE1 macro occurs next, as indicated at line 4. After the DECODE1 macro in line 4, an instruction or instructions may be included relevant to emulation of the guest instruction. Next, a DECODE2 macro is executed as indicated at line 6. The DECODE2 macro in line 6 may be followed by other instructions indicated by line 7, relevant to the decoded guest instruction. Next in the sequence, a PREFETCH macro of line 8 is executed. The PREFETCH macro may be followed by an instruction or instructions represented by line 9 of the emulation program. Finally, the DISPATCH macro is executed as indicated at line 10. The first instruction of the DISPATCH macro is a conditional jump to the value in the ctr register, if no special conditions are pending.
FIG. 5 illustrates the distribution of the DECODE1, DECODE2, PREFETCH, and DISPATCH macros within an emulation program. It will be appreciated by those of skill in the art that the presence of instructions between such macros may or may not occur. However, by distributing the macros among the instructions of the emulation program, the programmer can take advantage of any data or instruction access latency occurring in the program to improve performance.
FIG. 6 illustrates an emulation program which is used when a single instruction in a dispatch entry in the dispatch table is insufficient to handle addressing mode issues. In this case, the first instruction, INST of the dispatch entry, is shown in line 1. This instruction is a non-jump instruction which sets the value of a return address in a host register labelled rtn.sub.-- addr which is a general purpose register in a preferred embodiment of the present invention. The next instruction in line 2 of FIG. 6 is the instruction INST2 in the dispatch entry. This instruction causes a jump to an effective address routine stored in the emulation routine store, as illustrated at element 43 of FIG. 3.
Line 3 of FIG. 6 illustrates the beginning instructions of the effective address routine. Line 4 of the program shown in FIG. 6 is an instruction which results in moving the return address from the register rtn.sub.-- addr to a special purpose register Ir, which is used for jump addresses by the host processor. This may or may not be necessary in a given implementation of the present invention. Line 5 of the program illustrates the final instruction of the effective address routine, which requires a jump to the return address stored in the register Ir. This jump results in execution of the instructions illustrated at line 6, starting the emulation block for the guest instruction. This emulation block will include the DECODE1 macro, line 7, possibly other instructions, line 8, the DECODE2 macro, line 9, the PREFETCH macro, line 10, possibly other instructions, line 11, and the DISPATCH macro, line 12, as described above with respect to FIG. 5.
II. Multi-Instruction Sequence Emulation
The emulation system according to the present invention may be further optimized for sequences of guest instructions which are expected to be relatively common in the guest code to be emulated. For instance, the move multiple opcode MOVEM in the 68020 architecture may be a first instruction in a three instruction sequence, including MOVEM, unlink UNLK, and return-to-subroutine RTS, which commonly occurs in many programs written for the 68020 processor. Thus, FIG. 7 illustrates how an emulation program for the MOVEM opcode may be implemented according to the present invention.
The MOVEM emulation program, after dispatching, as described above, will include a section which begins execution of the opcode, including the DECODE1, DECODE2, and PREFETCH macros (block 100). After the prefetching, the next opcode (2nd) can be tested to determine whether it is the UNLK opcode (block 101). If it is not, then the expected sequence is not occurring, and the MOVEM instruction is completed (block 102).
If at block 101, the emulation program detects a UNLK instruction, then the algorithm tests whether special conditions are pending, such as an interrupt, or instruction tracing condition (block 103). If a special condition is pending, then the algorithm branches back to complete the MOVEM instruction at block 102, because the special condition must be handled between guest instructions.
If no special condition is pending at block 103, then the next opcode (3rd) is tested (block 104). If the third opcode is not the RTS instruction, then the predicted three instruction sequence is not found, and the algorithm branches to complete a combined MOVEM and UNLK instruction program (block 105). If the next opcode is found to be RTS in block 104, then the algorithm branches to complete the combined MOVEM, UNLK, and RTS instruction sequence (block 106).
Thus, it can be seen that for the combined sequence, the overhead of the decoding and dispatching logic for UNLK and RTS is bypassed.
FIG. 8 illustrates an emulation program for the MOVEM instruction, or a similar instruction which may be the first instruction in a three guest instruction sequence. As illustrated in FIG. 8, the first guest instruction is dispatched by the emulation program of the previous instruction, as described above. Thus, the first guest instruction emulation program includes instruction 1 on line 1 and instruction 2 on line 2 which are found in the dispatch table. Instruction 2 on line 2 causes a jump to line 3 of the program, found in the emulation program store. These instructions for the MOVEM instruction will need a MOVEM opcode extension. This opcode extension will have been loaded by the previous emulation program in the prefetch.sub.-- data register, as it consists of the next two bytes in the guest instruction sequence. Thus, an additional prefetch is needed to be executed to find the next guest instruction. So, the pc value is then incremented by two bytes and a prefetch operation to fetch the instruction from the address pointed to by the register pc to a general purpose register gpr, other than the prefetch.sub.-- data register is executed (line 4). The emulation program tests whether the second guest instruction, which is now indicated by the value in the general purpose register is the expected second guest instruction of the sequence and saves the result (line 5).
Line 6 of the program indicates that the extension data is used by the emulation program. An additional instruction or group of instructions may be executed (line 7). Lines 8 and 9 of the program illustrate that the DECODE1 and DECODE2 macros are executed. Line 10 indicates that an instruction or instructions may be interspersed between the DECODE2 macro and the PREFETCH macro on line 11. After the DECODE1, DECODE2 and PREFETCH macros are executed, a check for special conditions, such as an interrupt or instruction tracing mode, is made (line 12). As indicated at line 13, the program will branch if the sequence had been detected in line 5, and no special conditions were found. If the sequence is not detected, then instructions indicated at line 14 are executed to complete emulation of the MOVEM instruction. Finally, the DISPATCH macro is executed to jump to the dispatch table entry for the second guest instruction (line 15).
In FIG. 8, if the branch is taken at line 13, then the program moves to line 16. At this point, instructions may be executed. Line 17 of FIG. 8 shows that the program then tests for the third expected guest instruction in the sequence by looking at the value in the prefetch.sub.-- data register. As indicated at line 18, the algorithm will branch if the sequence is detected. If not, the instructions indicated by line 19 are executed to carry out a combined two instruction sequence. The DECODE1 and DECODE2 macros are executed, as indicated at lines 20 and 21. Line 22 indicates the possibility of interspersed instructions for the emulation program between the macros. At line 23, the PREFETCH macro is executed to prefetch the fourth guest instruction in the sequence. Next, the DISPATCH macro is executed to jump to the dispatch table entry for the third guest instruction in the sequence (line 24).
If at line 18 of the program the branch was taken, then for the program illustrated in FIG. 8, line 25 is executed. This line indicates that instructions in the emulation program are executed. Line 26 illustrates that an additional fetch operation is executed to retrieve the fourth guest instruction into the prefetch.sub.-- data register. For the RTS instruction in this sequence, the PREFETCH macro is replaced by instructions to retrieve the target of the return from subroutine instruction into the prefetch.sub.-- data register.
Lines 27 and 28 correspond to the standard DECODE1 and DECODE2 macros in the emulation system. Line 29 indicates the presence of interspersed instructions to complete the combined three guest instruction emulation. Line 30 illustrates the presence of the PREFETCH macro to retrieve the fifth guest instruction in the sequence. Line 31 ends up the routine with a DISPATCH macro which causes a jump to the dispatch table entry of the fourth guest instruction in the sequence.
Thus, it can be seen that the emulation program includes logic which bypasses the dispatching of instructions in the detected sequence. This greatly reduces the overhead involved in executing common guest instruction sequences.
FIG. 9 illustrates an emulation program for a sequence of guest instructions, such as a repeated sequence. As can be seen in FIG. 9, the first guest instruction is dispatched by the previous emulation program, and instructions 1 and 2 from the dispatch table entry are executed (lines 1 and 2). Instruction 2 causes a jump to the emulation program store and execution of the sequence beginning with line 3.
Line 3 in FIG. 9 illustrates that the emulation program will include instructions that test the prefetch.sub.-- data register for the sequence. This register will have been filled with the second guest instruction in the sequence by the PREFETCH macro of the previous guest instruction.
As indicated on line 4, the algorithm branches if the sequence is detected to line 11. If the sequence is not detected, then the algorithm continues with instructions indicated at line 5 to complete the emulation program. The emulation program would also include the DECODE1 and DECODE2 macros as indicated at lines 6 and 7. Line 8 indicates that instructions of the emulation program may be interspersed with the macros involved in decoding and prefetching instructions. At line 9, the PREFETCH macro is executed to retrieve the third guest instruction in the sequence. Line 10 is the DISPATCH macro which jumps to the dispatch table entry for the second guest instruction. If at line 4, the branch was taken, a PREFETCH macro is executed to retrieve the third guest instruction. This macro is necessary because the DECODE1, DECODE2, and PREFETCH macros of lines 6, 7, and 9 were bypassed by the detection of the sequence of guest instructions. Then, the instructions at line 12 are executed for the combined emulation program. Next, the emulation program will include a DECODE1 macro as indicated at line 13. Line 14 indicates the possible distribution of instructions within the emulation program. Line 15 indicates the DECODE2 macro which loads the ctr register with the address of the dispatch entry for the third guest instruction. Line 16 indicates the PREFETCH macro for retrieving the fourth guest instruction in the sequence. Line 17 is the DISPATCH macro which causes a jump to the dispatch table entry for the third guest instruction.
Thus, FIG. 9 illustrates the bypassing of decode and dispatch logic in the emulation program for a common opcode sequence, such as a repeated pair of opcodes.
FIG. 10 illustrates a program which is optimized for decoding repeated sequences of instructions. In this example, the first instruction on line 1 is a test for repeat and the second instruction is a jump from the dispatch table entry to an emulation routine on line 3 as shown in FIG. 10. Thus, lines 1 and 2 of FIG. 10 correspond to the dispatch table entry for the first guest instruction.
At line 3, the routine executes an instruction or instructions relevant to the guest instruction being decoded. Next, the DECODE1 macro is executed, followed by the PREFETCH macro for the third guest instruction (lines 4 and 5). After the PREFETCH macro, an instruction or instructions for emulating the guest instruction are executed (line 6). In line 7, the algorithm then branches if a repeat had been detected to line 11 of the routine. If no repeat had been detected, then the DECODE2 macro is executed, as indicated at line 8. This macro is followed by instructions indicated at line 9 which wrap up the emulated guest instruction. Line 10 indicates the DISPATCH macro is executed. This results in dispatching of the (2+N)th guest instruction, where "N" is the number of times that a repeated instruction had been detected. Thus, if no repeat is detected at line 7, then the second guest instruction is dispatched at line 10.
If the branch had been taken at line 7, then the algorithm goes to line 11 to test for a repeat once again. Thus, the second and third guest instructions can be compared to determine whether a repeat has occurred at this point, because the PREFETCH macro on line 5 had prefetched the third guest.
In line 12 of the routine, a branch is taken if a special condition is detected to line 8 to complete the execution of the current guest instruction. In line 13, additional instructions are executed to handle the combined execution of repeated instructions. At line 14, the DECODE1 macro is executed, followed by the PREFETCH macro in line 15. The PREFETCH macro on line 15 prefetches the (3+N)th guest instruction, where "N" again is the value indicating the number of times that a repeat had been detected.
At line 16, instructions are executed relevant to emulation of the guest instruction sequence. At line 17, the algorithm branches if a repeat had been detected at line 11 back to line 11. The algorithm continues in this loop from lines 11 through 17, until the repeated sequence ends. Line 18 of the routine causes a branch to line 8 to wrap up the sequence if the branch at line 17 is not taken.
III. Details of a 68020 Emulation on a Power Architecture
The present invention may be further understood with reference to or detailed information concerning emulation of the Motorola 68020 microprocessor guest code on an IBM POWER microprocessor architecture. Thus, the internal design of a 68020 emulator for the POWER architecture processor is provided below.
POWER Registers
The POWER architecture defines 32 general purpose 32 bit registers (actually they can be 64 bits, but the emulator just uses the 32 bit architecture) referred to as r0 . . . r31. There are 32 double precision 64 bit floating point registers referred to as f0 . . . f31, which are not used at all by the emulator. There are 4 additional special purpose 32 bit registers used by the emulator, they are called cr (condition register), xer (exception register), ctr (counter), and Ir (link register).
In the source code, the general purpose register are referred to by names, instead of r0 . . . r31. These name will be used in the remainder of the document. The current assignments are as follows, although they can easily be rearranged.
The zero register contains a constant value of zero, it is never changed. Assigning this to register r0 is also convenient due to the POWER architecture base address quirk that does not allow r0 to be used as a memory base register.
The register d0 . . . d7, a0 . . . a7, pc, sr.sub.-- and.sub.-- flags, ccr.sub.-- x, and vbr are used to hold corresponding 68020 register state. This is described in detail later in this document.
Registers addr, data, rtn.sub.-- addr, immed.sub.-- data, and base.sub.-- disp are five temporary scratch registers used during the emulation of a 68020 instruction. Although they can be used for many different purposes, their names describe how they are used by effective address calculation routines, which are used during the emulation of many of the opcodes.
The prefetch.sub.-- data register generally contains the sign extended 16 bit data value pointed to by the pc register.
The disp.sub.-- table register points to an entry in the 512KB instruction dispatch table. The opcode being dispatched to is inserted into this register to index the table, this is described in more detail later.
The code.sub.-- ptr register points to the beginning of the 64KB block of code that contains the emulation routines this block is 64KB aligned so that a 16 bit immediate value can be "or"ed with this register to point to any address with this 64KB block of code.
EmulatorStatePtr points to the base of the memory area that is used to store less frequently used emulator state that cannot be contained in the POWER registers.
The POWER special purpose Ir register is available for use during the emulation of a 68020 instruction, and does not correspond to any 68020 register state.
The POWER special purpose ctr register is available for use during the emulation of a 68020 instruction, and does not correspond to any 68020 register state. It is used by convention to hold the address of the first POWER instruction to be executed to emulate the next 68020 instruction.
The POWER special purpose xer register is used to hold the V and C bits of the 68020 CCR register. It also contains the POWER SO bit, as well as the byte count to be used by POWER string instructions.
The POWER condition register cr is used to hold the N and Z bits of the 68020 CCR register. The low 16 bits are available for general use during the emulation of a 68020 instruction. The 4 bit condition register fields cr1 and cr2 are not used, the 4 bits of cr3 are used for global flags related to interrupts and special conditions which are described later.
68020 Register State Assignments
The 68020 has a number of general purpose and special purpose registers, some of which are only accessible in supervisor mode. All of these registers contents must be maintained by the emulator. In some cases, the bits in these registers may be distributed in a number of different places within the POWER architecture, but the emulator will gather/scatter the bits whenever it encounters a 68020 instruction that accesses the entire register. In other cases, there may be multiple copies of a register contents. Many of the special purpose registers are stored in memory pointed to by EmulatorStatePtr. The 68020 registers and their POWER locations are as follows.
The 68020 registers d0 . . . d7/a0 . . . a6 are in POWER registers. The 68020 has three stack pointers, and the active stack pointer will be in register a7, while the remaining two inactive stack pointers will reside in memory. The memory copy of the active stack pointer is not used and inconsistent while that stack pointer is selected as the active stack pointer. When the selection of the active stack pointer is changed, the register copy of the old stack pointer will be written to memory, and the new register copy of the active stack pointer will be read from memory. It should be noted that register a7 is assigned to POWER register r1, which is register used for the native POWER stack pointer. This is to allow a single stack model in a mixed emulated and native environment.
In the 68020, the pc generally points to the beginning of the instruction that is currently being executed. During emulation the pc register advances as the instruction is decoded and executed, and generally points somewhat past the beginning of the instruction being executed. At the beginning of the execution of an instruction, the pc always points two bytes (16 bits) past the beginning of the instruction, which may actually point to the next instruction. Since this offset is constant, it is always possible to compute the actual pc at an instruction boundary. When the 68020 instruction trace mode is active, the exception frame that is generated after the execution of a traced instruction needs to contain the pc of the beginning of the instruction that has just completed. Since it is generally not possible to compute the size of the instruction that just completed, or worse yet, it may have been a branch instruction which computed a completely new pc, there is a memory copy called trace.sub.-- pc. When trace mode is active, the pc of an instruction that is about to execute is save in the memory based trace.sub.-- pc, so that the starting pc of the instruction can be determined when the instruction completes. Since there is a performance penalty associated with this computation and updating, this is only performed when trace mode is enabled.
The 68020 CCR register consists of five condition code bits, called X, N, Z, V, and C. During emulation, these are treated as five separate bits which are in three different registers, instead of a single field of five bits. The X bit is stored in bit 2 of the POWER register named ccr.sub.-- x. This bit position corresponds the position of the CA bit in the POWER special purpose XER register. The N bit is stored in bit 0 of the POWER cr register, this corresponds to the hi condition bit of cr0. The Z bit is stored in bit 2 of the cr register, this corresponds to the EQ condition bit of cr0. The V bit is stored in bit 1 of the POWER special purpose XER register, which is the OV flag. The C bit is stored in bit 2 of the XER register, which is the CA flag. Most of the 68020 data movement and logical operations only update four of the five condition codes. They leave the X bit unchanged, set the N and 7 bits to indicate if the result is negative or zero, and always clear the V and C bits. Using this arrangement, a single POWER instruction can move data from one register to another, and update some or all of these four bits of the CCR as follows.
Most of the 68020 arithmetic and shift operations update the X bit to the same value as the C bit. Since the C bit is in the XER register, a simple move from the XER register into the ccr.sub.-- x register is all that is required to update the X bit. It should be noted that the 68020 X and C bits are set to 1 if there is a borrow during subtraction, while the POWER (and most other RISC processors) set the CA bit to 0 if there is a borrow during subtraction. This will require the CA bit to be complemented before saving it as the X and C bits. The same inversion is needed when the X bit is used as a borrow-in for the 68020 SUBX instruction. By using the following instruction pair, it is possible to perform a subtraction followed by an addition, which will set the CA flag to correspond to the 68020 conventions.
The upper byte of the 68020 SR register is stored in the low 8 bits (24 . . . 31) of the sr.sub.-- and.sub.-- flags register. The high 16 bits (0 . . . 15) of this register contain test-mode enable flags. Bit 20 is the flag.sub.-- group.sub.-- 1.sub.-- active bit which indicates that a group 1 exception (Bus Error or Address Error) is being processed, and is used to detect a Double Bus Fault situation. Bit 22 is the flag.sub.-- odd.sub.-- pc bit, which is used for Address Error detection. Bit 23 is the flag.sub.-- trace.sub.-- pending bit, which indicates that the 68020 instruction currently being executed is being traced, and needs to generate a trace exception when it completes.
Many of the 68020 special purpose registers that are accessed via the MOVEC instruction are stored in memory, because they are infrequently accessed, and there are not enough POWER registers available to hold all of them. An exception to this is the vbr register, there is a dedicated POWER register that is used to hold a copy of the vbr register contents, however the memory copy is also kept up to date. The various stack pointers are also an exception. Since only one of the three stack pointers can be selected at a time, the register a7 is used for the selected stack pointer, and the remaining two inactive stack pointers are stored in memory.
The Dispatch Table
The dispatch table is an indexed table of 65536 pairs of POWER instructions, which correspond to the entry points for the routines to emulate each of the 65536 possible 68020 instruction encodings. The first instruction of the pair will generally perform some operation related to source operand fetching or addressing. The second instruction of the pair is generally a branch instruction to an emulation routine which resides outside of this table. Since each pair of instructions will occupy 8 bytes, the total size of this table is 512K bytes. Currently this table is located at addresses $68000000 . . . $6807FFFF, and can reside in Read Only Memory (ROM). The register disp.sub.-- table is used to address this table.
The alignment of the beginning of the table is very important, it needs to start at either the beginning of a 2MB boundary, or 512KB past the beginning. By having this 512KB block aligned to a 512KB address, the POWER Block Address Translation (BAT) registers can be used to perform the address translation of this fairly randomly accessed block of code, and eliminate potential thrashing of the TLBs.
The 512KB alignment also allows a single POWER instruction to index the table using the 68020 opcode times 8. The following instruction will shift the opcode left by 3 bits (multiply by 8), and insert it into the address of the base of the table, forming the address of the table entry for that opcode.
By having this table start in the first 1 MB of a 2 MB aligned boundary, where the second 1MB of addresses will cause an exception if accessed, it is possible to use an additional address bit to assist in the detection of Address Errors (see discussion later in this document).
The Emulation Routines
There is a block of 64K bytes allocated for the POWER instructions the Dispatch Table branches to. In general, the first two POWER instructions in the emulation of a 68020 instruction reside in the Dispatch Table, while the remaining instructions, which we refer to as the Emulation routines, reside in this block of code. Currently this block is located at addresses $68080000 . . . $6808FFFF, and can reside in Read Only Memory (ROM). The register code.sub.-- ptr contains the address of the beginning of this block.
Just like the Dispatch Table, the alignment of the block of code for the Emulation routines is also very important, it needs to start at the beginning of a 64KB boundary.
In the emulator, it is frequently desirable to compute the address of an instruction within this block of code. The POWER architecture does not provide an instruction to compute a pc-relative address. The register code.sub.-- ptr points to the beginning of the block, and there is a label in the source code called cb which marks the code base. To easily compute the address of any label within this 64 KB block of code, the following instruction can be used.
Within the 64 KB block of code, there is additional attention paid to code alignment. The 601 processor cache has 32 byte cache blocks, and a cache line consisting of 2 cache blocks, or 64 bytes. To improve locality, and reduce the number of bytes of code that needs to be fetched when there is a cache miss, the routines are packed into nicely aligned 32 or 64 byte blocks.
68020 Instruction Prefetching
On the 601 processor, as well as most other RISC processors, there is some latency associated with memory read operations, and attempts to use the results of a load instruction, in the very next instruction will usually result in a pipeline stall. To improve performance, and minimize these stalls, it is very desirable to issue memory reads several instructions before attempting to use the data that they read.
Since the emulator needs to read all of the 68020 opcode and operand bytes in order to emulate an instruction, performance can be improved by issuing these reads long before the data is needed. To accomplish this, the emulator uses a register called prefetch.sub.-- data to read (or pre-fetch) the next 16 bits (sign extended) of the instruction stream into, as soon as the current 16 bits have been consumed. The register pc is used to point to the position within the 68020 instruction stream that has been read. The POWER architecture provides an efficient instruction that can both advance the pc register, and read the data pointed to by the updated pc. The instruction is as follows, and there is also a macro called PREFETCH that is used within the emulator source code.
The prefetched data is always read 16 bits at a time, and sign extended, because the 68020 opcodes and extension words are most often organized in 16 bit groups. The sign extension is useful for the addressing modes that use a 16 bit signed displacement that is added to an A-register or the PC register.
68020 Instruction Decoding
By using many of the concepts introduced above, the four basic steps required to decode and emulate a simple 68020 instruction can now be described. The four steps are referred to as DECODE1, DECODE2, PREFETCH, and DISPATCH. For simplicity, we will assume that this is a 16 bit opcode that does not perform any useful operation.
Since this is a very pipelined sequence of events, and we must start somewhere in the pipeline, we will begin at the first instruction in the dispatch table for this opcode, and after going through the remaining stages, we will see how we get back here after completing the remaining phases.
Upon entry, the following registers are setup as follows. The disp.sub.-- table and ctr registers contains the address of the dispatch table entry for this opcode (the POWER address that we are currently executing at). The pc register points 2 bytes past the 68020 opcode that we are about to emulate. The prefetch.sub.-- data register contains the sign extended 16 bit value that the pc register points to (in this example, it is the next 68020 opcode to be emulated).
The first phase is DECODE1, this phase is begins the decoding of the next 68020 instruction to be emulated. In this example, we are assuming that the current 68020 instruction consists of just a 16 bit opcode, and does not have any extension words. If there were extension words, they would need to be consumed by PREFETCHing, until prefetch.sub.-- data contains the opcode of the next 68020 instruction, and pc points to that opcode. The DECODE1 operation takes the next 68020 opcode that is in the prefetch.sub.-- data register, multiplies it by 8, and inserts it into the disp.sub.-- table register, forming the address of the dispatch table entry for the next 68020 instruction. This is done in a single POWER instruction as follows, the macro DECODE1 performs this instruction.
Since DECODE1 was the first of the two POWER instructions that reside in the dispatch table entry for this 68020 instruction, the second instruction must be a branch out of the dispatch table, and into an emulation routine. This is not considered to be one of the phases of the decoding process, but rather a necessity imposed by the two instruction limit with a dispatch table entry. In this example we will assume that this branch is as follows.
The second phase is DECODE2, which in this example will occur in the first POWER instruction of the emulation routine. DECODE2 simply takes the dispatch table entry address that was computed by DECODE1, and moves it into the POWER ctr register. This is because the POWER branch instructions cannot branch to addresses contained in the general purpose registers, and can only branch to addresses in either the ctr or Ir special purpose registers. The DECODE2 phase is done in a single POWER instruction as follows, the macro DECODE2 performs this instruction.
The third phase is PREFETCH, which in this example will occur in the second POWER instruction of the emulation routine. As described earlier, PREFETCH will advance the pc register by 2 bytes, and read the sign extended 16 bit value at that address into the prefetch.sub.-- data register. We need to prefetch at this time, because we have consumed the previous contents of the prefetch.sub.-- data register, which had contained the 16 bit 68020 opcode for next instruction to be emulated. This will setup the prefetch.sub.-- data register with the first extension word (if any) associated with the next opcode, or the opcode of the instruction following the next instruction. As shown earlier, the PREFETCH phase is done in a single POWER instruction as follows, the macro PREFETCH performs this instruction.
The fourth and final phase is DISPATCH, which in this example will occur in the third and fourth POWER instructions of the emulation routine. There are two POWER instructions needed for this phase, but in general the second one never gets executed. The DISPATCH phase completes the emulation of the current 68020 instruction, and begins the emulation of the next 68020 instruction. Since this marks the boundary between two 68020 instructions, any special processing that needs to occur between two 68020 instructions must happen here. Instruction Trace exceptions, and 68020 interrupt processing are examples of special events that need to be processed on instruction boundaries. There is a bit in the POWER cr register referred to as cr.sub.-- special.sub.-- event.sub.-- pending, which gets set whenever any of this special handling is needed. How this bit gets set will be described later, but for now, lets just assume that it is cleared. Since the dispatch table entry address for the next 68020 instruction is already loaded into the POWER otr register, the DISPATCH phase simply needs to branch to this address when there are no special events pending, or branch to a common routine to process pending special events. This final phase is done in two POWER instructions as follows, the macro DISPATCH performs these instructions.
By breaking the decoding and dispatching process into these simple phases, the instructions to perform the various phases can be distributed between other instructions within the emulation routines to execute in gaps where the processor would have otherwise stalled due to memory access latency.
Effective Address Computation
The 68020 architecture has a number of different addressing modes, some are very simple, and some can become very complex. Since the effective address, and the data that it points to, is generally needed very early in the emulation of a 68020 instruction, it is convenient to have a number of Effective Address Computation routines that can run be selected based upon the addressing mode, and a common emulation routine to implement the operation independent of the addressing mode used.
In some cases, the entire Effective Address Computation can occur in a single POWER instruction, and can be placed in the Dispatch Table. In other cases a short (or possibly long) subroutine is needed. Since there is only room for two instructions in the dispatch table, one method of performing a subroutine call would be to have the first instruction contain a call to the subroutine, which would return to the second instruction, which would be a branch to the emulation routine. This would result in a branch to a branch instruction, on the initial dispatch, and a branch to a branch instruction when returning from the Effective Address subroutine. This type of branching does not perform well on the POWER processor. It is more desirable to have the Effective Address calculation subroutine return directly to the @ first instruction of the emulation routine.
To reduce the number of branches, a slightly different subroutine calling convention is used. The first instruction in the dispatch table will load the address of the emulation routine into the register rtn.sub.-- addr, and the second instruction will branch to the Effective Address subroutine. The subroutine will move the address of the emulation routine from rtn.sub.-- addr into the Ir, and when it returns, it will return to the emulation routine.
routine, the code.sub.-- ptr register is used as a base address. An example of what the two instructions in the dispatch table may look like is as follows.
There are some register conventions used by the effective address routines. As mentioned before rtn.sub.-- addr is used to pass the return address, and may be used as a scratch register by the Effective Address routine. The register addr is used to return the effective address (if one is computed). The register data will contain the data that was read from the effective address (if it was a Fetch Effective Address routine) , or will remain unchanged. The register immed.sub.-- data is used to return the immediate operand, or opcode extension word that follows to opcode but precedes the Effective Address extension words, for Immediate/Extended Effective Address routines. The register base.sub.-- disp is used as a scratch register.
The 68020 modes 6n and 73 indexed addressing modes can be very complex. In it's simplest form, any of the sixteen 68020 A/D registers can be used as an index. The index can be treated as a sign extended 16 bit quantity, or a full 32 bit value, and can be multiplied by 1, 2, 4, or 8, added to a base register, and added to a sign extended 8 bit displacement. Most of the information needed to compute the address is in a secondary extension word. There is an additional bit that indicates that even more complex addressing options are available. To quickly decode all of these options, there is a 256 entry table of instruction pairs that is at the beginning of the emulation routine code block. The code.sub.-- ptr register points to the base of this indexed addressing mode decode table.
Address Error Processing
Since all instructions in the 68020 architecture are a multiple of two bytes long, the 68K does not allow instructions to begin on odd addresses. If a branch to an odd address is attempted, an Address Error exception is generated. Since this exception is an indication of a programming error, and is not a normal occurrence, the emulator would like to spend as little time as possible checking for this condition. There have been two methods used in the emulator to detect branches to odd addresses, each has different performance characteristics.
The first method (which is no longer used) consists of two phases, called CHECK.sub.-- ODD.sub.-- PC1 and CHECK.sub.-- ODD.sub.-- PC2. Each phase consisted of a single instruction. The first instruction would move the low bit of the pc register into bit 31 of the cr register. The second instruction would "or" bit 31 into the special event pending flag. This would cause the process.sub.-- special.sub.-- event routine to be entered if the new pc value was odd. That routine would check to see if the pc was odd, and generate an Address Error exception if it was. The POWER instructions used by the two phases are as follows.
The second method consists of a single phase, called CHECK.sub.-- ODD.sub.-- PC1, which is a single POWER instruction. This instruction will insert the low bit of the pc register into bit 11 of the disp.sub.-- table register. Assuming that this is done before the DECODE2 phase, it will cause the DISPATCH phase to jump to an address that is 1MB past the Dispatch Table Entry that should have been used. This is an illegal address, and will cause an exception when the DISPATCH is attempted. The handler for this exception will notice that the bit in disp.sub.-- table had been set, and will cause an Address Error exception to be generated. This method has less overhead than the first method when the pc is even, but significantly more overhead when the pc is odd. The single POWER used by this method is as follows.
MOVEM Register List Optimizations
The 68020 MOVEM instruction has a 16 bit register list mask associated with it. There is one bit for each of the 16 A/D registers, indicating if the register should be moved. In general, the emulator would need to perform 16 individual tests of the bits to determine if the corresponding register needed to be read/written. This can be very time consuming. Due to compiler register allocation, parameter passing, and calling conventions, there are some registers that rarely appear in the register list of the MOVEM instruction, and others that are much more frequent. Taking advantage of this, the emulator can first check to see if any of the infrequent registers are on the list, using a bitwise "and" operation against the mask. If none of those bits were set, then there is a much smaller list of bits that need to be checked individually (7 instead of 16), which will improve performance. The infrequent registers that the emulator currently test for are d0-d3/a0-a1/a5-a7 and the frequent registers are d4-d7/a2-a4.
Optimizations based on Opcods Synonyms
In the 68020 instruction set, there are many cases where two different opcode encodings perform exactly the same operation. Since the emulator can uniquely decode each of the 65536 possible opcode encodings, it can make sure that the dispatch table entries for two opcode synonyms are the same, and have exactly the same performance. Below is a list of instructions and their synonyms.
Optimizations based on Operands
In many cases, opcodes that have the same register specified as both the source and destination behave the same as some other Opcode which executes faster. For these opcodes, we create an optimized dispatch table entry which is the same as the simpler opcode, instead of using the dispatch table entry for the general case. The table below shows the transformations.
In many cases, memory to memory MOVE instructions that have the same source and destination addresses behave the same as a TST instruction. If we can assume that the read and the write will be to the same RAM location, and that there are no side effects (write protected or I/O space accesses), then it should be safe to omit the write, and just do the read. The table below shows the transformations.
Optimizations based on repeated Opcodes
There are many places in the Macintosh QuickDraw routines where data movement loops are "unwound" and contain 16 repeated sequences of the same instruction, followed by a DBRA looping instruction. There are also cases of shorter sequences in compiler generated code for structure copying. Since the emulation of a repeated sequence of 68020 opcodes will cause a repeated sequence of POWER instructions to be executed within the emulator, it is possible for the emulation of one of these opcodes to detect that the next opcode is the same, and eliminate some of the decoding and dispatching overhead, which will improve the performance of the subsequent instances of the same opcode. If instruction tracing or an interrupt is pending, this optimization cannot be performed, because special event processing would need to occur at the instruction boundaries. The opcodes that the emulator currently detects repeated sequence of are shown below.
Optimizations based on Opcode Sequences
In compiler generated code, and sometimes in the Macintosh ROM code there are common sequences of two and sometimes three instructions that occur frequently due to runtime calling conventions. In many cases detecting these sequences is done by having the emulation of the first instruction of the sequence check to see if it is followed by the second instruction of the sequence. For sequences of three instructions, if the pair of the first two had been detected, then the check for the third instruction can be made. The emulator currently detects and optimizes the following pairs and triples of instructions. As with other optimizations of this kind, the optimization cannot be performed if special events are pending. The sequences that the emulator may detect are shown below.
ATrap Dispatcher Acceleration
The Macintosh OS and Toolbox use the unimplemented LineA opcode space to encode system calls. The LineA dispatcher in the ROM executes several instructions (on every call) to dispatch to the desired routine. This whole process can be greatly improved by having the emulator directly dispatch these instructions. However, there must also be a way for this feature to be disabled if the standard LineA dispatcher has been replaced, such as when using the A-Trap record/break features of MacsBug. In order to achieve this compatibility, we need to know if the handler address (in vector offset $28) has changed. Fortunately, we do not have to worry about tracing, since the 68000 will not take a trace trap on a LineA (or any other unimplemented) instruction.
IV. Conclusion
This emulation technique is also optimized for an upgraded version of the POWER architecture, referred to as the POWER PC architecture. This updated version of the POWER architecture executes the same opcodes listed above for the POWER architecture instructions, except with different mnemonics.
Thus, a highly efficient method for decoding 68020 instructions in the POWER architecture processor, utilizing a special table of instruction sequences, specific sequences of instructions and other optimizations is provided. The alignment and method of indexing the table contribute to the high speed decoding of the 68020 instructions. In particular, a single POWER instruction can be used to index the table, by aligning the dispatch table on a 512K byte boundary within a two megabyte range, shifting the opcode left by three bits and inserting the shifted opcode into the address of the base of the table. Each entry in the table contains two POWER instructions. The first instruction generally performs an operation specific to source addressing mode, and the second instruction branches to an emulation routine which is generally independent of the source addressing mode. This allows reduced code size, and better memory reference and cache locality for the emulation routines.
There are four phases of the instruction decoding process. DECODE1 forms the address of the next dispatch table entry by shifting and inserting the next 68020 opcode into the address of the base of the dispatch table. DECODE2 moves that dispatch table address to the power architecture CTR register. PREFETCH reads the 16 bits (assigned extended to 32 bits) that follow the next 68020 instruction into a temporary holding register called prefetch.sub.-- data. Finally, DISPATCH jumps to the address that was computed by DECODE1.
This sequence of four instruction macros is the minimum number of instructions in this embodiment of the invention that this task can be performed in on the POWER architecture, and the use of opcode prefetching reduces or eliminates pipeline stalls due to memory reference latency.
Overall, performance of an emulating guest instructions is enhanced by reducing the number of host instructions needed to be executed to emulate the guest instruction. One primary reason for this benefit is the direct access to the instructions in the dispatch table, combined with prefetching of the guest instructions. Furthermore, opcode sequences of any length may be optimized, and decoding and dispatch logic bypassed for the sequence, to further enhance emulator performance.
The foregoing description of preferred embodiments of the present invention has been provided for the purposes of illustration and description. It is not intended to be exhaustive or to limit the invention to the precise forms disclosed. Obviously, many modifications and variations will be apparent to practitioners skilled in this art. The embodiments were chosen and described in order to best explain the principles of the invention and its practical application, thereby enabling others skilled in the art to understand the invention for various embodiments and with various modifications as are suited to the particular use contemplated. It is intended that the scope of the invention be defined by the following claims and their equivalents.
Claims
What is claimed is:
1. A computer system that decodes guest instructions for emulation, comprising: host processor that executes host instructions; guest program store accessible by said host processor, said guest program store containing a program sequence of said guest instructions for emulation by said host processor; emulation routine store accessible by said host processor, said emulation routine store containing a set of emulation routines each corresponding to a particular one of said quest instructions, said emulation routines for execution by said host processor during emulation of said program sequence, each emulation routine having dispatch logic for handling a next guest instruction after said particular one of said guest instructions in said program sequence wherein said dispatch logic handles said next guest instruction by initially determining whether said particular one of said guest instructions followed by said next guest instruction correspond to a predefined opcode sequence, said dispatch logic then emulating said next guest instruction for said predefined opcode sequence without dispatching to said emulation routine that corresponds to said next guest instruction if said particular one of said guest instructions followed by said next guest instruction correspond to said predefined opcode sequence, and wherein said dispatch logic handles said next guest instruction by dipatching to said emulation routine that corresponds to said next guest instruction if said particular one of said guest instructions followed by said next guest instruction do not correspond to said predefined opcode sequence.
2. The computer system of claim 1, wherein said dispatch logic detects said predefined opcode sequence by prefetching said next guest instruction in said program sequence and determining whether said particular one of said guest instructions emulated by said emulation routine that corresponds to said particular one of said guest instructions followed by said next guest instruction correspond to said predefined opcode sequence.
3. The computer system of 2, wherein said dispatch logic also includes logic for determining whether an opcode of said next guest instruction is the same as an opcode of said particular one of said guest instructions emulated by said emulation routine and then emulates said next guest instruction if said opcodes are the same without dispatching to said emulation routine that corresponds to said next guest instruction.
4. The computer system of claim 3, wherein said dispatch logic dispatches said next guest instruction to said emulation routine for said next guest instruction contained in said emulation routine store if said opcodes are not the same.
5. The computer system of claim 4, further comprising a dispatch table store accessible by the host processor, said dispatch table store having a plurality of entries including an entry corresponding to said particular guest instruction of said guest instructions wherein said entry corresponding to said particular guest instruction contains a set of host instructions for execution by said host processor during emulation of said particular guest instruction.
6. The computer system of claim 5, wherein said emulation logic dispatches said next guest instruction by determining an index into said dispatch table store in response to said next guest instruction by converting said next guest instruction into said index within said host processor and by directly accessing said host instructions contained in said dispatch table that correspond to said next guest instruction according to said index.
7. The computer system of claim 6, wherein said emulation logic determines said index into said dispatch table store by providing an instruction that loads a specialized address register in said host processor with said next guest instruction multiplied by a constant value.
8. The computer system of claim 7, wherein said instruction that loads said specialized address register shifts said next guest instruction at least one bit position according to said constant value.
9. The computer system of claim 8, wherein said instruction that loads said specialized address register in said host processor obtains said next guest instruction from a specialized prefetch register in said host processor.
10. A method for decoding guest instructions for emulation in a computer system having a host processor that executes host instructions, said method comprising the steps of: providing a guest program store accessible by said host processor that contains a program sequence of said guest instructions for emulation by said host processor; providing an emulation routine store accessible by said host processor that contains a set of emulation routines for execution by said host processor during emulation of said guest instructions wherein each emulation routine corresponds to a particular one guest instruction of said guest instructions, wherein each emulation routine when executed by said host processor handles a next guest instruction after said particular one of said guest instructions in said program sequence by performing the steps of initially determining whether said particular one of said guest instructions followed by said next guest instruction correspond to a predefined opcode sequence, then emulating said next guest instruction for said predefined opcode sequence without dispatching to said emulation routine that corresponds to said next guest instruction if said particular one of said guest instructions followed by said next guest instruction correspond to said predefined opcode sequence, and otherwise by performing the step of dispatching to said emulation routine that corresponds to said next guest instruction if said particular one of said guest instructions followed by said next guest instruction do not correspond to said predefined opcode sequence.
11. The method of claim 10, wherein said step of determining whether said particular one of said guest instructions followed by said next guest instruction correspond to a predefined opcode sequence includes the step of prefetching said next guest instruction in said program sequence.
12. The method of 11, wherein each emulation routine when executed by said host processor handles said next guest instruction by performing the steps of determining whether an opcode of said next guest instruction is the same as an opcode of said particular guest instruction emulated by said emulation routine and then emulating said next guest instruction if said opcodes are the same.
13. The method of claim 12, wherein each emulation routine when executed by said host processor handles said next guest instruction by further performing the step of dispatching said next guest instruction to said emulation routine for said next guest instruction if said opcodes are not the same.
14. The method of claim 13, further comprising the step of providing a dispatch table store accessible by the host processor, said dispatch table store having a plurality of entries including an entry corresponding to said particular guest instruction of said guest instructions wherein said entry corresponding to said particular guest instruction contains a set of host instructions for execution by said host processor during emulation of said particular guest instruction.
15. The method of claim 14, wherein said step of dispatching said next guest instruction includes the step of determining an index into said dispatch table store in response to said next guest instruction by converting said next guest instruction into said index within said host processor and by directly accessing said host instructions contained in said dispatch table that correspond to said next guest instruction according to said index.
16. The method of claim 15, wherein said step of determining said index into said dispatch table store includes the step of loading a specialized address register in said host processor with said next guest instruction multiplied by a constant value.
17. The method of claim 16, wherein said step of loading said specialized address register includes the step of shifting said next guest instruction at least one bit position according to said constant value.
18. The method of claim 17, wherein said step of loading said specialized address register in said host processor includes the step of obtaining said next guest instruction from a specialized prefetch register in said host processor.
Patent Citations (27)
| Patent | Date | Inventor | Cited By |
|---|---|---|---|
| US3698007 | 1972-10-01 | Malcolm et al. | |
| US3972029 | 1976-07-01 | Bailey, Jr. | |
| US4087857 | 1978-05-01 | Joyce et al. | |
| US4262330 | 1981-04-01 | Berglund et al. | |
| US4307445 | 1981-12-01 | Tredennick et al. | |
| US4429361 | 1984-01-01 | Maccianti et al. | |
| US4587612 | 1986-05-01 | Fisk et al. | |
| US4635188 | 1987-01-01 | Williamson et al. | |
| US4722047 | 1988-01-01 | Chan et al. | |
| US4722050 | 1988-01-01 | Lee et al. | |
| US4727480 | 1988-02-01 | Albright et al. | |
| US4791557 | 1988-12-01 | Angel et al. | |
| US4812972 | 1989-03-01 | Chastain et al. | |
| US4812975 | 1989-03-01 | Adachi et al. | |
| US4839797 | 1989-06-01 | Katori et al. | |
| US4841476 | 1989-06-01 | Mitchell et al. | |
| US4951195 | 1990-08-01 | Fogg, Jr. et al. | |
| US4972317 | 1990-11-01 | Buonomo et al. | |
| US4992934 | 1991-02-01 | Portanova et al. | |
| US5070475 | 1991-12-01 | Normoyle et al. | |
| US5077657 | 1991-12-01 | Cooper et al. | |
| US5167023 | 1992-11-01 | de Nicolas et al. | |
| US5235686 | 1993-08-01 | Bosshart | |
| US5247624 | 1993-09-01 | Koumoto et al. | |
| US5432935 | 1995-07-01 | Kato et al. | |
| GBX2203572 | 1987-03-01 | ||
| WOXWO88/07718 | 1988-10-01 |
Non-Patent Literature (3)
- Vahlstrom, "Microprogramming Emulation of a General-Purpose Processor", Electrical Design News, vol. 20, No. 6, Mar. 20, 1975, pp. 61-66.
- Sherman, "Attention to Basics Reduces Risk in Ada Compiler Choice", Computer Design, vol. 25, No. 12, Jun. 15, 1986, pp. 87-90.
- Threaded code interpreter for Object code.