GB2337140A - Emulation in microprocessors - Google Patents

Abstract

An emulation system to allow code written for a specific computing environment to be run on a different microprocessor platform comprises: an emulation routine generator including a table storing code segments corresponding to instructions of said specific computing environment, said emulation routine generator creating said emulation routines written in code for said different microprocessor platform from selected code segments in said table, said emulation routines corresponding to instructions of said specific computing environment; an emulator kernel to read instructions of said specific computing environment and access and execute emulation routines thereby to emulate and carry out said read instructions; and an interface resembling said specific computing environment. The generator also puts linking addresses to the emulation routines into a jump table.

Description

1 2337140 EMULATION SYSTEM INCLUDING EMULATOR GENERATOR

Field Of The Invention

The present invention relates generally to microprocessor platforms and in particular to an emulation system including an emulator generator to permit code developed for a specific computing environment to be executed on microprocessor platforms of different design.

Background Of The Invention

A variety of microprocessor platforms exist on the market today. However, new microprocessor platforms are being introduced with increasing frequency. As new microprocessor platforms emerge and old microprocessor platforms become obsolete, it is desirable to retain the use of legacy code (i.e. code written for older obsolete microprocessor platforms) due to the investment of time and expertise legacy code represents. In order to retain the use and fanctionality of legacy code in new microprocessor platforms, the legacy code must either be ported, rewritten or emulated.

Unfortunately, porting and re-N,,,riting of legacy code requires a substantial investment of time and effort. Emulation however, provides an opportunity to use legacy code on new microprocessor platforms thereby allowing new tools, applications and/or functionality to be accessed while minimizing time and/or resource commitments.

Although emulation provides advantages over porting and re-writing, software emulation in the past has been generally too slow to provide sufficient performance to be feasible and thus, has seldom been considered.

It is therefore an object of the present invention to provide an emulation system to permit code developed for a specific computing, environment to be executed on microprocessor platforms of different design which obviates or mitigates the disadvantages associated with the prior art.

Summary Of The Invention

According to one aspect of the present invention there is provided an emulation system to allow code written for a specific computing environment to be run on a different microprocessor platform comprising:

an emulation routine generator including a table storing code seaments corresponding to instructions of said specific computing environment, said emulation routine generator creating said emulation routines written in code for said different microprocessor platform from selected code segments in said table, said emulation routines corresponding to instructions of said specific computing environment; an emulator kernel to read instructions of said specific computing environment and access and execute emulation routines thereby to emulate and carry out said read instructions; and an interface resembling said specific computing environment.

A link between the instruction (1 6-bit pattern for a Motorola 68000) and the emulating routine is contained within a jump-table prepared by the generator.

Brief Description Of The Drawings

An embodiment of the present invention will now be described more fully with reference to the accompanying drawings in which:

Figure 1 is a schematic block diagram of an emulation system in accordance with the present invention; Figure 2 is a schematic block diagram of an emulator generator forming part of the emulation system of Figure 1; Figure 3 is a schematic block diagram of an M68k emulator kernel 25 forming part of the emulation system of Figure 1; Figure 4 is a schematic block diagram of an emulation API forming part of the emulation system of Figure 1; Figure 5 is schematic block diagram of an input component forming part of the emulator generator of Figure 2; Fiaure 6 shows a flow chart and a data flow diagram illustrating the t> overall operation of the input component of Figure 5; Figure 7 shows a flow chart illustrating an initialize static strings function performed by the input component of Figure 5; Figure 8 shows a data flow diagram illustrating the initialize static strings function of Figure 7; Figure 9 shows a flow chart illustrating a read operations format function performed by the input component of Figure 5; Figure 10 shows a data flow diagram illustrating the read operations 10 format function of Figure 9; Figure 11 is a schematic block diagram of an emulation routine generation component forming part of the.etnulatGr generator of Figure 2; Figure 12 shows a flow chart illustrating the overall operation of the emulation routine generation component of Figure 11; Figure 13 shows a data flow diagram of Figure 12; Figure 14 shows a flow chart illustrating a determine operations characteristics function performed by the emulation routine generation component of Figure 11; Figure 15 shows a data flow diagram illustrating the determine 20 operation characteristics function of Figure 14; Figure 16 shows a flow chart illustrating a fill emulation string table function performed by the emulation routine generation component of Figure 1 Figures 17 and 18 show a data flow diagram illustrating the fill emulation strina table function of Ficure 16; Figure 19 is a schematic block diagram of an output component forming part of the emulator generator of Figure 2; C> 1; Figure 20 shows a flow chart and a data flow dia ram illustrating the 9 overall operation of the output component of Figure 19; Figure 21 shows a flow chart and a data flow diagram illustrating an t> 0 emulation code function performed by the output component of Figure 19; Figure 22 shows a flow chart illustrating an emulation loop executed by the M68k emulator kernel of Figure 3; Figure 23 shows a flow chart of an ExceptionPending routine executed C> by an Exception Detection function forming part of the M68k emulator kernel of Figure 3; Figure 24 shows a flow chart and a data flow diagram of an AutoVector routine executed by the Exception Detection function forming part of the M68k emulator kernel of Figure 3; Figure 25 shows a flow chart and a data flow diagram of an Exception Handler function forming part of the M68k emulator kernel of Figure 3; Figure 26 shows a flow chart of a PackSR routine executed by the M68k emulator kernel of Figure 3j., Figure 27 shows a flow chart of a UnpackSR routine executed by the M68k emulator kernel of Figure 3; Figure 28 shows a flow chart and data flow diagram of an Emu68kInit routine executed by a control component of the emulation API of Figure 4; Figure 29 shows a flow chart and data flow diagram of an Emu68kRun routine executed by the control component of the emulation API of Figure 4; Figure 30 shows a flow chart and data flow diagram of an Emu68kStep routine executed by the control component of the emulation API of Figure 4; Figure 31 shows a flow chart and data flow diagram of an Emu68kWriteMecord routine executed by a memory access component of the emulation API of Figure 4; Figure ')2 shows a flow chart and data flow diagram of an Emu68kProcessSRecord routine executed by the memory access component of the emulation API of Figure 4; Figure 33 shows a sample flow chart and sample data flow diagram of an "Emu68kRequest... " routine executed by a requests component of the emulation API of Figure 4; and Figure 34 shows a flow chart and data flow diagram of an 0 Emu68kSysternsExecptions routine executed by the requests component of the emulation API of Figure 4.

Detailed Description Of The Preferred Embodiments

Referring now to Figure 1, an emulation system to allow code written for a specific computing environment to be run on a different microprocessor platform is shown and is generally indicated to by reference numeral 50. In the preferred embodiment, the emulation system 50 allows Motorola 68000 ("M68k") code to be emulated and run on an Intel 80x86 microprocessor platform. The emulation system 50 forms part of a PC-based PBX (private branch exchange) incorporating preexisting call control software written in SX2000 code for a non-PC-based environment as described in co-pending Canadian application serial No. filed on May 1, 1998 for an invention entitled "Method And Apparatus For Migrating Embedded PBX System To Personal Computer". In this manner, the pre- existing call control software can be maintained even though the processing platform is different. Those of skill in the art will however appreciate that the emulation system can be used in other environments and can be configured to provide for the emulation and running of M68k code or other code on different microprocessor platforms.

The emulation system 50 includes an emulator generator 52 accessing an external data-table 54, a M68k emulator 56 communicating with the emulator generator 52 and an emulation applications program interface (API) 58 communicating with the M68k emulator 56. The emulator generator 52 includes a larae table (hereinafter referred to as a static string structure) containing emulation code segments written in Intel assembly which can be assembled to create emulation routines. The emulation routines when executed by the M68k emulator 56 allow for M68k instructions to be carried out.

The emulation code segments are designed to replace each M68k instruction with a set of Intel instructions that perform an identical task and support Motorola-like registers. The M68k instruction set consists of fifty-five base operations, some of which include additional variations or subsets. With few exceptions, operations performed on bytes, words and Iona words, can use any of the 14 Motorola addressing modes and work with any of the 14 Motorola registers. Combining instruction types, data types, addressing modes and source/destination registers produces several thousand useful instructions.

The instruction set of the M68k microprocessor is based on a 16-bit instruction format. Thus, each instruction is represented by a specific 16-bit pattern, comprised of an instruction mask and permutation masks. The permutation masks are required to identify addressing modes, affected registers and size of the operations.

Of the sixty-five thousand possible permutations available to a 16-bit format, about forty-seven thousand are used. The remaining combinations were not used by Motorola as of the day the present application was filed. The static string structure contains emulation code segment entries corresponding to the forty-seven thousand M68k instructions, each entry being between 5 and 50 lines long.

The M68k emulator 56 executes the emulation routines created by the emulator generator 52 to carry out the M68k instructions while the emulation API 58 provides an interface as similar as possible to that of the M68k microprocessor platform. In this manner, the emulation system 50 appears as a M68k microprocessor to the pre-existing soft-,,,,,are being executed.

The external data-table 54 contains a list of frames or characteristic data packets representing all of the M68k instructions to be emulated. The stored characteristic data packets describe the syntax, base operation, operand size, instruction format, source addressing modes available, destination addressing modes available, condition codes modified by instruction, privilege level, modification of source and/or destination, change in flow, and possible modifications to status register, of each instruction. Separate frame entries are created in the external datatable 54 to distinguish between instructions as a function of the operation size. That is, frames are created for byte operations, for word operations and for long word operations. Multiple frames entries are created, if required, to differentiate amongst variations or subsets of a given instruction. For example, frames entries are created for the ADD instruction and the ADDI (add immediate) instruction which is a subset of the ADD instruction. Just over 300 frame entries provide all of the characteristic information required to generate the full set of M68k instructions to be emulated.

Figure 2 better illustrates the emulator generator 52 and as can be seen, the emulator generator includes an input component 60, an emulation routine generation component 62 and an output component 64. The input component 60 is responsible for reading information on each M68k instruction to be carried out from the external data-table 54 and for initializing the static string structure as well as an emulation structure as will be described. The emulation routine O'eneration 7n io component 62 is responsible for determining the characteristics of each M68k instruction to be carried out and based on the determined characteristics, selecting appropriate emulation code segments stored in the static string structure. The output Z> component 64 is responsible for piecing the emulation code segments together to create emulation routines 66 so that each M68k instruction will be emulated when the corresponding emulation routine is run by the M68k emulator kernel 56. The output component 64 is also responsible for generating jump-tables 68 containing linking addresses to the emulation routines to allow the M68k emulator 56 to access the emulation routines. These emulation routines 66 and jump-tables 68 are generated once and included as relocatable objects during link time with the M68k emulator kernel 56 code.

Referring now to Figure 3, the M68k emulator kernel 56 is better illustrated. As can be seen, the M68k emulator kernel includes an emulator loop 70 executing a main program and accessing memory 72, an exception detection function 74 and an exception handler function 76. Two supporting routines are executed by the M68k emulator kernel 56, namely a PackSr routine and an UnpackSr routine as will be described.

The main program loop is basically a continuous loop which reads M68k instructions from the memory 72, uses the M68k instructions to index into the jump-tables which contain the location of the corresponding emulation routine associated with the read M68k instructions, executes the emulation routines and then cycles back to repeat the process. The main program is exited only when an exception is present and is detected by the emulator loop 70. The exceptions may be software (S/W) exceptions, hardware (H/W) interrupts, trace exceptions or system exceptions as determined by the exception detection function 74 and are treated by the M68k emulator kernel 56 as requests. When software or trace exceptions or hardware interrupts are detected, the main program is exited and control is passed to the exception handler function 76 to allow the exceptions to be handled. Once the exception handler function 76 handles the exceptions, control is passed back to the main program of the emulator loop 70. When a system exception is detected, the M68k emulator kernel 56 is exited. A new call to the M68k emulator kernel 56 must be made in order to return to the main program loop.

The emulator API 58 is best illustrated in Figure 4, and as can be seen, the emulator API includes a control component 80, a registers component 82, a requests component 84 and a memory access component 86. Control, registers and requests components 80 to 84 respectively communicate with the M68k emulation kernel 56 while memory access component 86 communicates with the memory 72.

The control component 80 is responsible for initializing and cleaning up the M68k emulator kernel 56 and for conditioning the M68k emulator kernel 56 to operate in either a step mode or a run mode as will be described. The memory access component 86 provides an interface to the memory 72 allowing M68k instructions to be loaded into the memory 72 once the M68k emulator kernel 56 has been initialized.

The M68k instructions are written to the memory 72 in an S-Record format (see Appendix A) using a Write-S-Record function.

The registers component 82 makes the registers that are available to a native M68k microprocessor platform available to the M68k emulator kernel 56. The re-isters made available to the M68k emulator kernel 56 by the registers component 82 include control registers such as the status register (SR), the program counter (PC), Zn t> the user stack pointer (USP) and the supervisor stack pointer (SSP), information registers such as the data registers (DO, D I, D2.. D7) and the address registers (A0, C> A I, A2.. A7). The M68k emulator kernel 56 also supports a vector base realster (VBR) used in the native M68020 instruction set.

The requests component 84 allows requests (i.e. software exceptions, hardware interrupts, trace exceptions and system exceptions) to be set and cleared and their status tested.

In the present embodiment, the main function of the emulation system 50 is to take existint> SX2000 code (which is designed to take advantage of the M68k microprocessor architecture and is thus very tightly coupled to this architecture) and run it on an Intel 80x86 platform. Due to the different processor structures (register structure, instruction set, etc.), each M68k instruction must be translated into and emulated by a series of Intel 80x86 instructions.

The emulator generator 52 is run to generate the emulating routines 66 and the jump-tables 68. The emulating routines 66 and jump-tables 68 are assembled (currently using Microsoft Assembler 5. 1) to generate object files to be linked with the M68k emulator kernel 56 and emulation API 58.

During start-up, the SX2000 code is loaded from file and stored into the memory 72 using the S-Record format (see Appendix A). This format specifies where within the memory each section of the code is to be located. The S-Record is read directly as a file. In order to run the SX2000 code, the M68k emulator kernel 56 takes each M68k instruction read from memory 72 and uses it to index into the jumptables 68 to access the emulation routine. The emulation routine is then executed to carry out the M68k instruction. Once the M68k instruction has been processed, the M68k emulator kernel 56 tests for exceptions and if none are found automatically executes the subsequent M68k instruction. This process continues indefinitely unless exception handling requires exceptions to be processed. The emulation API 58 protects the M68k emulator kernel 56 and provides an interface resembling the M68k microprocessor environment. Further specifics of the emulation system 50 and its operation will now be described.

Emulator Generator The emulator generator 52 works on the assumption that various code segments, each performing a specific function, can be integrated to create smoothly operating routines. To achieve this, recurring functionality was assigned to specific registers in the Intel space. The table below lists the "dedicated" registers and their assigned function.

Dedicated Intel Registers (size long) EAX = destination data EBX = pointer to destination data ECX = source data EDX = pointer to source data EBP = pointer to base memory Input Component Figures 5 and 6 better illustrate the input component 60 and as can be seen, the input component includes a number of functions, namely an initialize emulation function 100, an initialize static strings function 102 and a read operation format function 104. The initialize emulation function 100 pre-sets the emulation structure into a known state by setting pointers within the emulation structure to Null.

The initialize static strings function 102 initializes strings (i.e. emulation code segments) in the static string structure. The static string structure contains a significant number of strings containing just about all the required code segments to create all of the M68k instructions. The static string structure is filled during initialization. The fields that are available in the static string structure are described individually in the following sections.

paszOpMnemonics paszOpMnemonics [opMAX]; array is indexed by [operation enumeration: ABCD.B =O, ADD.B =I, etc.]; this field of the structure is an array of strings. Each strin contains the

C 9 mnemonic of an operation. The mnemonic string matches the value used in the frame format structure operation field to describe the operation. The index into this string is the operation number (which is a value from an enumerated list).

paszSrcAddrStr paszSreAddrStr [OP_SIZE-MAX][0100]; array is indexed by [operation size: byte, word, long] [operation address mode: (An), (d,6,An), (xxx.W), etc.]; The addressing mode is in octal format and adheres to the following standard:

for the range 000 to 067 (octal values) the value XY indicate the mode X is used to identify Y is used to identit, the addressing mode the register used in use 0 - Dn 1 -An 2 - (An) 3 - (An)+ 4 - -(An) - (d 1 6,An) 6 (d8,An,Yn) 6 The values in the 07z range - (xxx.W) 0 - 0 (such as DO or AO) 1 - 1 (such as D 1 or AI) 2 3 4 5 A7) 7 - 7 (such as D7 or indicate the following addressing modes:

12- 71 - (xxx.L) 72 - (d161PC) 73 - (djC,Xn) 74 - <data> 75 - (BYTE)data16 76 - <data 1 6> 77 - <data32> the array contains code segments used to support retrieving source data 10 when not directly from registers - i.e. utilizing memory addressing modes or special t> addressing modes. The code moves the data address into the Intel register reserved for source data address and correctly updates the emulated registers (i.e. for the modes W1 (An)+, -(An), etc.) paszReadSrcString paszReadSrc String [OP-SIZEMAX][0100]; array is indexed by [operation size: byte, word, long] [operation address mode: (An), (d16,An), (xxxM), etc.]-. (for details on operation addressing mode refer to pasrSrcAddrStr); the array contains code segments used to support retrieving source data. The code moves the data to the Intel register reserved for source data. This will vary depending on the addressing mode (for direct registers the data is taken from register, otherwise it is read from the address previously set-up). paszSrclmpliedAddrString paszSrcImpliedAddrString [0x100]; array is indexed by [implied number: 0-255]; the array contains code segments to support source implied address mode.

paw Write SrcString paszWrite Src String [OP-SIZE-MAXI[0100]; array is indexed by [operation size: byte, word, long] [operation address mode: (An), (d16,An), (xxx.'5, etc.]; (for details on operation addressing mode refer to section paszSrcAddrStr); the array contains code segments used to support updating source data following the execution of the instruction. The code moves the data from the Intel re-ister reserved for source data to the variable representing the Motorola register.

paszDstAddrStr paszDstAddrStr [OP_SIZE-MAX][0100]; same as paszSrcAddrStr description but for destination data.

paszReadDstString paszReadDstString [OP_SIZE-MAX][0100]; same as paszReadSreString description but for destination data.

paszWriteDstString paszWriteDstString [OP-SIZE-MAXI[0100]; same as paszWriteSrcString description but for destination data.

Z> paszOpCodeString paszOpCodeString [opMAX][OP-SIZE-MAX]; array is indexed by [operation enumeration: ABCD.B =0, ADD.B =1, 20 etc.] [operation size: byte, word, long]; A limited number of operations are recognized by the Emulator Generator as being the core operations and they all have supporting operation- specific code. All other functions can be generated using these base o erations. For example t> p ADD.B is a base operation, ADDA.W is a base operation, but ADDI.B is not and it can be aenerated using ADD.B. This array contains the code segments to support this c operation-specific functionality.

paszCcrString paszCcrString [cerMAX]; array is indexed by [ccr-operation enumeration: clear-C, clear-V, clear-Z, set-C, set-V,..., test-C,..etc.l; contains the code segments to support clearing, setting and testing of the Condition Code Registers.

ppszSrPackStruct code segment to pack the Status Register structure calls the PackSR routine of the Emulator (see reference document).

ppszSrUnpackStruct code segment to unpack the Status Register structure calls the UnpackSR routine of the Emulator (see reference document).

ppszCheckPcString code segment to test the Program Counter for an odd value if so cause an address error exception; following a change in PC by the instruction, the PC must be tested to ensure that it does not rest on an odd boundary as this would cause an address error; Note: the PC is incremented within the M68k Emulator Kernel (see Emulator reference) by incrementing its value to the next word boundary. An operation may require that the PC be modified further due to the presence of data followina the instruction. For example the data used in an ADD immediate follows the instruction, or the address information stored immediately following a branch instruction. In such cases the PC is modified accordingly within the code of the emulating routine. The information is contained within the paszOpCodeString field.

Z> ppszCheckPrivilegeString code segment to test the operating mode (supervisor or user) to determine if the operation can be executed. If operating mode is not supervisor, set a privilege violation exception; Some operations are allowed to be executed only while in supervisor mode due to their ability to affect a whole system (such as RTE, RESET, ORI to SR, MOVES, etc.).

ppsz VarDefinitionStilng code segment which contains a list of all the external variables used to emulate Motorola 68000 registers and other microprocessor functions.

As mentioned above, the initialize static strings function 102 initializes code segments stored in the static string structure by calling a number of routines (see t_5 C1 Fiaures 7 and 8) to perform the initialization. In particular, the initialize static strings function 102 initializes the code segments used for: reading source data from registers; reading the data usine, various forms of addressing; updating the destination data usine, various forms of addressing, etc. As part of the static string structure initialization, conditional code register (CCR) strings are also initialized with the code necessary to support clearing, setting and testing the C-carry, V- overflow, Z-zero, N negative and X-extend bits of the conditional code registers. Conditional code information is contained in bits within the status register as in the native M68k microprocessor as well as in separate conditional code variables, one variable per bit, for ease of processing.

The initialize static strings function 102 also initializes the strings required for the packing and unpacking of the status register (SR) structure entries, the strings required for testing instruction privilege (user or supervisor mode) and the code segments for testing possible address violations following modifications to the program counter (PC). In addition, the initialize static strings function 102 initializes the strings required for operation specific code.

To initialize the static string structure as described, the initialize static strings function includes a Load Instruction Mnemonics routine 102a; an Initialize Source Address routine 102b; an Initialize Source Read Register routine 102c; an Initialize Source Write Register routine 102d; an Initialize Destination Address routine 102e; an Initialize Destination Read Register routine 102f; an Initialize Destination Write Register routine 102g; an Initialize Operation Specific Code routine 102h; an Initialize Conditional Code Registers routine 102i; and an Initialize SR, PC, Privilege, Variable Strings routine 102j.

The Load Instruction Mnemonics routine 102a loads the mnemonics of the supported operations. The Initialize Source Address routine 102b initializes code segments to support address modes. The Initialize Source Read Register routine 120c initializes code segments to support reading from source registers. The Initialize Source Write Register routine 102d initializes code segments to support writing data to source following instruction. The Initialize Destination Address routine 102e initializes code segments to support destination address modes. The Initialize Destination Read Register routine 102f initializes code segments to support reading data from destination registers. The Initialize Destination Write Register routine 102g C1 initializes code segments to support writing data to destination following instruction.

The Initialize Operation Specific Code routine 102h initializes code segments supporting the specifics of the various operations. TheInitialize Conditional Code Registers routine 102i initializes code segments supporting setting, clearing and testincy CCRs. The Initialize SR, PC, Privilege, Variable strings routine 102j initializes code segments supporting the status register SR, tests for program counter PC, tests for Privilege and providing register Variable definitions.

The read operation format function 104 is called once the emulation structure and static string structure have been initialized and includes a read frame format routine 106 and a parse frame format routine 108. The read operation format function 104 retrieves frames from the external data-table 54 that are required for each emulation routine to be created. The steps performed by the read operation format function are better shown in Figures 9 and 10. As can be seen, when the read operation format function 104 is called, the read operation frame format routine 106 retrieves the frames from the external data-table 54 that are necessary for the M68k instruction to be carried out. As each frame is read from the external data-table 54, the read frame format routine 106 saves the information of the read frame as an entry in a format frame structure. The parse frame format routine 108 then acts on the saved information to remove spaces, tabs and comments from the entry. These steps are performed until all of the necessary frames have been read from the external data table 54.

The format frame structure contains the formatting information for all operations to be emulated. The format frame structure is filled with inforrriation from the external data-table 54. The fields that are available in the format frame structure are described individually in the following sections.

SYNTAX The syntax field provides an opportunity to define what operation is defined by the frame. The field is only used to differentiate the operations and for display purposes to ease trouble-shooting. The field entry consists of the operation and operation's use:

ADD.B <ea>,Dn ADD.B Dri, <ea> (two different operations).

or OPERATION A limited number of operations are recognized by the emulator generator 52 as being the core operations and they all have supporting operation- specific code. All other functions can be generated using these base operations. For example ADD.B is a base operation, ADDA.W is a base operation, but ADDI.B is not and it can be generated using ADD.B.

The field contains the operation whose code will be used to support the functionality.

A list of all base-operations is provided during initialization by the Load Instruction Mnemonics routine 102a.

SIZE size of the operation.... byte, word, long, unsized (for operations which are not affected by size like Upt, trap, rts or reset) or word:long (for operations in which the source is word but the destination is Ion. such as adda.w, cmpa.w, divs.w, muls.w, etc.).

FORMAT the instruction format, a binary representation of the 16-bit instruction.

It includes the fixed component of the operation as well as the source, destination or effective addressing modes. The fixed component is expressed using Os and Is, the source and destination modes are described using the following categories:

z ddd aaa rinn nnnnnnnn - source Dn - source An - source number 3) bit (1 -7 and 0 -> 8) - source number 8 bit NNNNN - source number 8 bit L255 (!= 0) nimmrrr - source Mode:Register DDD - destination Dn AAA - destination An MMMRRR - destination Mode:Register For example for the DIVS.W instruction:

format is: 1000 DDDO 1 Imm destination: DDD source: mrnmrrr SRC ADDRMODE describes the valid addressing modes for the source component using a 16-bit representation (unrelated to the format). The following addressing modes are supported:

0 1 2 3 25 with postincrement 4 with predecrement 5 with displacement Dri An (An) (An)+ -(An) - Data register direct - Address register direct Memory address - address register indirect - Memory address - address register indirect - Memory address - address register indirect (d,61An) Memory address - address register indirect t> (d,,An,Xn) - Memory address - address register indirect with index enable special addressing modes 8 (xxX.W) - Special - absolute short address 9 (xxx.L) - Special - absolute Ion. address C> (d16, PC) - Special - program counter with displacement I0 11 12 1 n 16 bit value) (djC,Xn) - Special - program counter with index <data> - Special - immediate data (BYTE) data16 - Special - immediate data (lower byte of 14 <data 1 6> - Special - immediate data (16 bits) <data32> - Special - immediate data (3)2 bits) The first number on the above table is the bit position representing the addressing mode (starting from the most significant bit!).

For example for the DIVS.W instruction:

source addressing mode 1011 1111 1111 1000 destination addr. mode 1000 0000 0000 0000 meaning the source supports Dri, all Memory address modes, and (xxx.W), (xxx.L), (d161PC), (djC,Xn) and <data> of the special modes. The destination only supports Dri mode.

DST ADDR MODE refer to the description in SRC-ADDR-MODE ( 0). CCR this 5 character field describes the effects of the conditional code registers and the required support. The characters represent: X (extend), N(negative),

0 Z(zero), V(overflow) and C (carry) in that order from left to right. The supported modes are:

for testing 0 for clear, 1 to set, and - and U to leave the register untouched is For example for the DIVS.W instruction:

_0 => indicates NZV to be tested/updated, C to always reset and X remains untouched.

SR PACK this field contains either a "yes" or "no" to indicate whether packing of the status register is required or not.

Packing or Unpacking of the status register is used when the operdtion leads to a change in the information contained in the status register (mode, trace, interrupt mask, conditional codes) or when the operation requires the information.

SR UNPACK this field contains either a "yes" or "no" to indicate whether unpacking of the status register is required or not.

Packing or Unpacking of the status register is used when the operation leads to a change in the information contained in the status register (mode, trace, interrupt mask, conditional codes) or when the operation requires the information.

PRIVILEGE this field contains either a "yes" or "no" to indicate whether the operation is restricted and as such must be executed exclusively under supervisor mode. (for example RTE, RESET, ORI to SR, etc.).

GET SRC this field contains either a "yes" or "no" to indicate whether the operation requires to collect source data. Most operations require source data, but some do not (such as TRAP, SF, RTS, etc.). Some require destination without source (such as SF).

GET DST this field contains either a "yes", 4'no" or "implied" to indicate whether the operation requires to collect destination data. Most operations require destination data, but some do not (such as TRAP, RTS, etc.). Some require destination without 5 source (such as SF).

SRC-ACTIVE field contains either a "yes" or "no" to indicate whether the source data is active - that is if it requires updating at the completion of the instruction (i.e. has been modified). For example the operation EX&W which exchanges the contents of

0 the two registers requires modification of the source. (For more information on the EXG operation consult the Motorola reference). DST ACTIVE field contains either a "yes", "no" or "implied" to indicate whether the destination data is active - that is if it requires updating at the completion of the

C5 instruction (i.e. has been modified). Many operations fall in this category... fo r example the operation MOVE.B requires modification of the destination.

F>C CHECK field contains either a "yes" or "no" to indicate whether the operation has modified the program counter (PC) and requires to test for possible address errors 20 (odd PC).

FIELD MAX this field is simply the last enumerator for the various fields. It is not modified.

Emulation Routine Generation Component Turning now to Figures 11 to 1 J3), the emulation routine generation component 62 is better illustrated. As can be seen, the emulation routine generation component includes a determine operation characteristic function 120, a determine source mask function 122, a determine destination mask function 124 and a fill emulation string table function 126. The determine operation characteristic function 120 accesses the format frame structure and the static string structure to determine the crucial characteristics for each operation to be performed to cam, out the M68k instruction and stores these operation characteristics in an operation characteristics structure.

enumerated list; paszOpCodeString field.

The fields that are available in the operation characteristics structure are described individually in the following sections.

nOperation operation number as given by the operation's position within an used as an index to retrieve information from the static string structure nSrcSize source operation-size as a number given by the size's position within is an enumerated list (i.e. byte = 0, word = 1, long = 2, etc.); the size is used as an index to retrieve information from various fields of the static string structure.

nDstSize destination operation-size as a number given by the size's position 20 within an enumerated list (i.e. byte = 0, word = 1, long = 2, etc.); the size is used as an index to retrieve information from various fields of the static strings structure.

Z:1 wlnstrMask operation mask; calculated fom the format frame structure format field; the operation mask is the fixed component of the instruction format. The fixed component of the binary representation of the 16-bit instruction (i. e. no source or destination permutations information).

For example for the DIVS.W instruction:

format is: 1000 DDDO llmm mrrr operation mask: 10000000 1100 0000 wSrcAddrMode source address mode; determined from the format frame format field; the source and destination modes are described below along with the corresponding enumerated "key" value (taken from a local list) which is used internally:

Mode Key - Data-Reg - Addr-Reg - Num_)Bit aaa nnn >8) nnnnnnnn - Num-8B it - source number 8 bit NNN'N - Num-8Bit-NortZero- source number 8 bit L.255 Address mode - source Dn - source An - source number 3 bit (1 -7 and 0 0) list) nIMMI1T - Mode-Reg DDD - Data-Reg AAA - Addr-Reg N - Mode-Reg RRRMW - Reg_Mode - source ModeRegister - destination Dn - destination An destination ModeRegister - destination Register:Mode For example for the DIVS.W operation:

format is: 1000 DDDO 11 mm mrrr wSrcAddrMode: Mode Ree, (actual value given by, enumeration - C CI wSrcAddrOffset offset of the source address mode; the distance (in bits) that the least significant bit of the value representing the address mode is located from the least sic ificant bit of the operation P format; For example for the DIVS.W operation: format is: wSrcAddrOffset:

1000 DDDO 11 mm mnr 0 wDstAddrOffset same as wSrcAddrMode but for destination address mode For example for the DIVS.W operation: format is: wDstAddrMode:

1000 DDDO 1 Imm = Data-Reg wDstAddrMode same as wSrcAddOffset but for destination address mode For example for the DIVS.W operation:

format is: 1000 DDDO 11 mm mrrr wDstAddrOffset: 9 abSrcPermission abSrcPermission [8]; array reflecting the various addressing modes available for source addressing. A mode is available if the respective byte is set (1), not available if reset (0); bytes 0 to 6 represent direct register and memory addressing modes, bits within byte 7 represent availability of special addressing modes; the supported addressing modes are: byte 0 1 2 indirect addressing mode Dn - Data register direct An Address register direct (An) - Memory address - address register 3 with 4 with predecrement 5 with displacement 6 with index displacement 3 4 5 byte of 16 bit value) (An)+ - Memory address - addr. regi. indirect postincrement -(An) - Memory address - addr. reg. indirect (d,61An) Memory address - addr. reg. indirect (d.,Ari,Xn) - Memory address - addr. reg. indirect bit of [7] addressing mode 1 (xxx.L) - Special - absolute Iona address 0 2 (d161 PC) - Special - program counter'sArith C> (djC,Xn) Special - program counter with index <data> Special - immediate data (BYTE) data 16 - Special - iinmediate data (lower 6 <data I 6> - Special immediate data (16 bits) 7 <data-'12> - Special - immediate data (3)2 bits) abDstPermission abDstPermission [8] same as abSrcPermission but for destination addressing modes; The source mask function 122 determines the source mask.and source mode register specific to the M68k instruction while the destination mask function 124 determines the destination mask and destination mode register specific to the instruction. Once the M68k instruction has been determined (block 128), the fill emulation string table function 126 populates an emulation string structure with the c> proper code segments taken from the static string structure. If the M68k instruction C> format specifies that the functionality is not required, then the entry in the emulation string structure is left void. The above steps are performed for each destination permutation, source permutation and operation (blocks 130 to 134 respectively). The fields that are available in the emulation string structure are registers).

code registers).

described individually in the following sections.

C> psz Operation String instruction's copy of information from paszOpMneumonics.

pszCheckPrivilege instruction's copy of information from ppszCheckPrivilege String.

pszGetSrcAddr instruction's copy of information from paszSrcAddrStr.

pszGetSrcData instruction's copy of information from paszReadSrcString.

pszGetDstAddr instruction's copy of information from paszDstAddrStr.

pszGetDstData instruction's copy of information from paszReadDstString.

pszOpCode instruction's copy of information from paszOpCode String.

pszSaveCCR code segment to save the Intel's flags (comparable to conditional code C> pszRestoreCCR code segment to restore the Intel's flags (comparable to conditional pszCcrX - instruction's copy of information frompaszCcrString.

pszSrPack instruction's copy of information from ppszSrPackStruct.

pszSrUnpack instruction's copy of information from ppszSrUnpackStruct.

pszPutSrcAddr instruction's copy of information from paszWriteSrcString.

pszPutDstAddr instruction's copy of information from paszWriteDstString.

pszCheckPc instruction's copy of information from ppszCheckP c String, When the deter-mine operation characteristic function accesses the format frame structure and the static string structure to determine the crucial characteristics for each operation to be performed, the operation characteristic function 120 determines the source addressing mode and the destination addressing mode (register direct, memory indirect, special modes, etc.) from the operation mask. The position of the addressing modes is also located within the 16-bit instruction format (i.e. the bits used to represent the permutation available to the instruction to indicate which addressing modes are being used). Knowing the location of the permutations determines how the modes are supported within the instruction format. Each operation has characteristics which determine what code segments are utilized to populate the emulation string structure. Some characteristics 0 ZZ> are also used to determine the source or destination masks. The operation characteristics function 120 therefore calls a number of routines to determine the code segments to be utilized as shown in Figures 14 and 15. Initially, the operation characteristics function 120 calls a Determine Operation routine 120a to determine what operation-specific code must be included. A Determine Operation Size routine 120b is then called to determine the size of the operation for both the source and the destination. In most cases this will be identical, but in a few instances, such as for operations which deal with addresses ADDA, the source might be different than the destination (word for source, long for destination). A Determine Operation Mask routine 120c is then called to determine the operations mask. It is important to know the operations mask as it describes the constant section of the 16-bit format. Get Source Addressing Mode and Get Destination Addressing Mode routines 120d and 120e respectively are then called to determine the source and destination address io modes and offsets from the operations format. For example, for the operation ABCD with format 1100 DDD 1 0000 Oddd, the following would be calculated: operations mask:

source mode:

destination mode:

1100 0001 0000 0000 DDD offset 0 (to indicate source from Dri registers) DDD offset 9 (to indicate destination from Dn registers) Get Source Permission and Get Destination Permission routines 120f and 120g respectively are then called to determine which of the addressing modes are supported by the operation (Dn, An, (An), (An)+, etc. ).

As mentioned previously, the fill emulation string table function 126 is responsible for populating the emulation string structure with correct code segments for each specified instruction. The fill emulation string table function 126 therefore calls a number of routines during population of the emulation string structure as shown in Figures 16 to 18. Firstly, when the fill emulation String table function 126 is invoked, it calls a Test For Collisions routine 126a which performs a test to ensure that no other operation has generated this particular instruction. A severe program error would result if this event were to occur. A Get Source String routine 126b is then called which determines the code segments necessary to support reading the source data taking the source address mode into consideration (i.e. retrieve data using various forms of addressing). This process is then repeated for the destination data by calling a Get Destination String routine 126c.

Some operations are only allowed to function under the supervisor mode of operation of the microprocessor. Thus, some operations require that the privilege of the operation be tested prior to performing the operation. The fill emulation string table function 126 therefore calls a Privilege String routine 120d to support the above. A Program Counter String routine 126e is then called to test for address errors in any operation that modifies the program counter (PC). A Conditional Code Register String routine 126f is then called to support conditional code registers CCRs. An Operation Specific Code routine 126g is then called to include the code specific to the operation and then an Update Source/Destination Code routine 126h is called to support any required updating of the source or destination data as a result of the operation.

Output Component Figures 19 to 21 better illustrate the output component 64 and as can be seen, it includes an emulaffin code function 150 and ajump-table information function 152. The emulation code function 150 pieces the code segments in the emulation string structure together to create emulation routines 66 and writes the emulation code segments to the emulation code structure.

The fields that are available in the emulation code structure are described individually in the following sections.

nSrcMask source mask - 16-bit value. a permutation of the source addressing component within the operation's format which specifies the instruction's characteristics. The value exists only if the addressing mode specified by the operation characteristics is supported. For example for the DIVS.W operation:

format is: 1000 DDDO 1 1= n= - -no - source addr. mode mmmrrr (this is a 6 bit field - covering 64

C> permutations) assume current source permutation is: 0 100 11 (binary) if this addressing mode (represented by the top 3 bits - 0 10 in this case => mode (An)) is supported by the operation (as determined by the source permission array abSrcPermission) then the source mask would be source mask:

0000 0000 0001 0011 nSrcModeReg source mode and register; the value (00 to 77 - octal) is a combination of the addressing mode (first octal digit) and the register implemented by that mode (second digit). The values of 070 to 077 represent the special addressing modes (thus no value for recriste nDstMask as in nSreMask but for destination field.

nDstModeReg as in nSrcModeReg but for destination field

The jump-table information function 152 creates the jump-tables 68 to allow the emulation routines to be accessed by providing linking addresses to the emulation routine using the M68k instruction number as an index.

Out of the possible 65,000 permutations available with a 16-bit frame, about 47,000 permutations identif valid M68k instructions. Considering that the emulation routines cover between 5 and 60 lines of code each, generating 47,000 emulation routines requires significant memory space. To limit assembly and link times, the emulation routines output by emulator generator 52 and stored in the emulation code structure are divided and stored into 16 assembly files. The value of the first nibble of the instruction is used to determine in which file the code of each emulation routine will be placed. File names are of the format 'Vxxx.asm", where ? refers to the value of the first nibble, For example, all routines emulating instructions starting with a high nibble value of 4 are placed in the file "i4xxx.asm" (instructions for xxx). Although all of the required information is placed into the emulation structure by the emulator generator 52, the emulation routines are not entities until the code segments are organized as they are written to file.

Generating the emulation routines by utilizing only the required components for each instruction is a task performed by a Write Single Instruction To File routine 154 called by the emulation code function 150. This routine calls a Print Data If Not Null routine 156 to print the information to file. The Write Single Instruction To File routine 154 organizes emulation code segments for given instructions and writes the information to file. The Print Data If Not Null routine 156 writes data to the file if the pointer to the data is valid, Forty-seven thousand instructions constitutes a considerable number of emulation routines to link. To provide quick access to the emulation routines, the jump-tables 68 are used. As each emulation routine is created, an entry in the jurriptables 68 is generated to provide the link address of an emulation routine by using the M68k instruction number as an index into the jump-table 68. That is, the jump-table is indexed with a 16-bit instruction and contains the starting address of the emulation routine. In practical terms, the jump-table 68 holds a label of the emulation routine. The label is resolved into the startinc, address of the emulation routine durina the linking stage. To limit link time and to reduce the size of the jump- table 68, the jumptable is also divided into 16 assembly files. The value of the first nibble of the instruction is used to determine in which assembly file the jump information is to be included. File names use the format "jmptable'>.asm", where ? refers to the value of the first nibble.

M68k Emulator Kernel Emulator Loop As mentioned earlier, the M68k emulator kernel 56 executes a continuous emulator loop 70 best seen in Figure 22 allowing emulation routines to be fetched and executed to carry out M68k instructions. Access to the main program of the emulator loop 70 is made via a call to Emu68000. When the call is made, access to memory 72 is prepared by setting the base pointer (block 180). The stack pointer that is to be used given the current operating mode (supervisor or user) is then determined (block 182). The UnpackSR routine is then invoked to update the Intel flags using the status register SR (block 184). Following this, the program counter is loaded and a M68k instruction is read from the memory 72. The program counter is then updated and the j ump-table 6 8 is used to find the address of the emulation routine in the emulation code structure to be run to carry out the read M68k instruction. A jump is then made to the emulation code allowing the emulation routine to be executed (blocks 186 and 188). Following this, the main program loop checks to determine if any exceptions have been received (blocks 190 to 194) or if any exceptions are pending (block 196). If no exceptions have been received or are pending, the main program returns to block 186. If an exception has been received or is pending, the emulator loop 70 is exited and control is passed to the exception detection function 74.

Exception Defection The exception detection function 74 includes two components, namely an ExceptionPending routine and an AutoVector routine. When control is passed to the exception detection function 74, the ExceptionPending routine is called (see Figure 23). The ExceptionPending routine firstly updates the flags register (InteISR) (block 200). Thereafter, the PackSR and UnpackSr routines are called (blocks 202 and 204). Following execution of the UnpackSR routine, the ExceptionPending routine determines whether the detected exception is a software exception (block 206), a hardware interrupt (block 208), a trace exception (block 2 10) or a system exception (block 212). This is necessary since each exception is treated differently.

If a software exception or a trace exception is detected, the ExceptionPending routine passes control to the Exception Handler function 76 so that the exceptions can be handled. If a hardware interrupt is detected, the ExceptionPending routine calls the AutoVector routine.

Referring now to Figure 24, when the AutoVector routine is called, the AutoVector routine checks to determine which hardware interrupt is set (blocks 220 to 232). Once the set hardware interrupt is known, the AutoVector routine sets the appropriate internal variables, namely the currentException, the interruptMask and the interruptMask bit SR-I (block 234). If the hardware interrupt cannot be determined, a spurious interrupt exception is set 236. Following this, the AutoVector routine calls the Exception Handler function 76.

Exception Handler When the Exception Handler function 76 is called, before the exception handling process is emulated, the exception handler function 76 saves the registers (block 240) and then checks to see if the exception is bound to routines to be executed in native Intel mode (block 242) (see Figure 25). This can be used for documentation of error, trigger for the execution of various processes etc. If a bound routine to the exception vector function table is present, it is executed (block 244). If a bound routine is not present or after the bound routine has been executed, the Exception Handler function 76 restores the registers (block 246). A check is then made to determine if the supervisor mode has been set (block 248). If not, the supervisor mode is set, the user stack pointer USP is saved and the supervisor stack pointer SSP is used (block 250). Thereafter, the Exception Handler function 76 prepares the M68k emulation kernel 56 to process the exception. In particular, the Exception Handler function 76 saves the status register, the program counter (prior to modification to support execution) and the stack format on the stack for retrieval at completion of the exception. The exception number is then used to index into the vector base table that contains the addresses of the exception handling routines. The program counter is updated, the exception variables are cleared and the M68k emulation kernel 56 returns to the emulator loop 70. Blocks 252 to 266 reflect the above steps.

PackSR and Unpack-SR The PackSR and UnpackSR routines are used extensively by the M68k emulation kernel 56 and emulation routines 66 and are responsible for transferring status flag information from the Intel platform to the Motorola platform (PackSR) and vice versa (UnpackSR). Theroutines ensure that the status flags are updated following the execution of emulation routines which modify their values. The packing routines also update some of the intermediate variables which are used by the emulation kernel 70 and are sometimes called to update changes to these intermediate variables into status flaus. The intermediate variables include conditional code register (CCR) values: Zero, eXtend, Negative, oVerflow and Carry flags CCR Z, io CCR-X, CCR-N, CCR-V and CCR-C respectively. The CCR variables are identified as a group of variables with the short form CCR-? where ? identifies the bit. The interrupt mask bit SR-I, the mode bit SR-S (supervisor/user) and the trace bit SR-T also exist. These variables are identified with the short form SR-? Where ? identified the bit. The bits are implemented as individual variables to reduce the processing required to support their functionality. To set, clear or test a variable requires less processing then having to isolate a given bit within a variable and then performing the same function on the resultant.

Referring now to Figure 26, the PackSr routine is better illustrated. As can be seen, when the PackSr routine is called, the conditional code variables CCR ? are updated and are given the status of their respective flags in Intel space (InteISR) (block 270). The status register is then updated given the status of the SR-? bits and the CCR-? variables (block 272).

Figure 27 best illustrates the UnpackSR routine and as can be seen, when this routine is called, the stack pointer is firstly saved (block 280). The status register SR is then used to update the SR-? and CCR-? variables (block 282). Following this, the interruptMask is updated (block 284) and the Intel flags are used to update the InteISR variable (block 286). The CCR bits in the InteISR variable are then cleared (block 288) and the InteISr variable is updated given the status of the CCR-? variables (block 290). The stack pointer is then retrieved (block 292) before the UnpackSr routine is exited.

Emulator Kernel The M68k emulator kernel 56 utilizes a handful of internal variables which are important to its operation. These variables include the interrupt request, the interrupt mask, the current exception and the program counter. The interrupt request variable is utilized to determine which exception is set. The variable is of type "long" and each bit represents an exception, either set or clear. The exceptions fall within the following groupings: hardware interrupts (7-1 bit each), software exceptions (single bit) and system exceptions (4-bits). The hardware interrupts are supported by bits 0-6 of the least significant byte (LSB). Bit 0 represents interrupt 1 and bit 6 represents interrupt 7, the other interrupts are arranged hierarcally between these two extremes. The software exceptions are supported by bit 7 of the LS13. The bit only indicates whether or not a software exception has been requested. Information on the specific exception is contained in the current exception variable. The system exceptions are supported with 4 bits in the high byte of the least significant word and are set out in the table below.

Bit Exception 9 Termination 13 DBErr 14 BGNI) Stop Description

Utilized to support the Step functionality performing a single instruction then returning to the system Double Bus Error Background - used to exit the Emulation Kernel and return to the system temporarily then returning to the Kernel. This can be used to support M68k code with code runnina in native Intel x86. Used to support the Stop functionality,

The interrupt mask is used to set the level of the current hardware interrupt being processed. This allows the interrupt hierarchy to be enforced. As in c the M68k microprocessor, level 7 interrupt is not maskable. The variable saves the level number using the same bit positions as those used by, the interrupt request Z> variable. The variable is also used to support the trace functionality by enabling a level 7 mask whenever the trace is to be started.

3 6 The software exception is flagged by setting bit 7 of the interrupt request variable. The software exception that actually has been triggered is specified by the current exception variable. The value stored corresponds to the exception assignments used by Motorola to determine the exception vector. For example, vector 9 is used to indicate that a trace exception has been triggered or requested. Vector number 8 corresponds to a privilege violation etc.

The program counter variable is responsible for keeping track of the program flow by storing the position in memory at which the program is executing. Once an M68k instruction has been read from memory 72 in the main program loop, the pro-ram counter is auamented by 2 bytes (minimum size of operation). However, an operation may require that the program counter be modified further to the presence of data following the instruction.

EmulatorAPI Control Component 80 The control component as mentioned previously includes initialization, destroy, run and step functionality. Each is described in one of the following sections. The initialization routine is responsible for presetting the environment as required by the M68k emulator kernel 56 prior to its invocation. The destroy routine on the other hand is responsible for freeing and cleaning-up any resources used by the M68k emulator kernel 56 once the requirement for the same has expired.

The M68k emulator kernel 56 can be run in two different modes, namely a step mode or a run mode. The step mode is entered by invoking an Emu68kStep routine (see Figure 30). The Emu68kStep routine when executed also transfers control to the emulator kernel 70 and allows execution of a sinale M68k instruction. The M68k emulator kernel 56 is exited once the instruction has been processed. Although slower for regular processing, the Emu68kStep routine offers opportunities for debugging when combined with the other interfaces (memory, registers and exceptions). The Emu68kStep routine also allows for analyzer functionality to be developed around the M68k emulator kernel 56. External looping with code or data breakpoints can be set up with minimum work.

To run a program, an Emu68kRun routine is invoked (see Figure 29).

When the Emu68kRun routine is invoked, control is transferred to the emulator kernel 70 which in turn emulates M68k instructions utilizing the emulator loop 70. After each instruction is emulated, the program counter is adjusted and the following instruction is emulated. The M68k emulation kernel 56 is exited only to support a system exception as will be described. The continuous looping bypasses the overhead incurred to setup the emulating environment. Programs run using the Emu68kRun routine execute approximately 18 times faster than those that utilize the Emu68kStep routine in an external loop.

Initialization of the M68k emulator kernel 56 enviromnent is required prior to operation. To initialize the M68k emulator kernel, an initialization Emu68kInitiazlize routine is called as shown in Ficrure 28. The Emu68kInitialize routine allocates the memory space utilized by the M68k emulator kernel by calling an Emu68k.ReserveMernory subroutine (block 300), presets some internal variables such as the status register, program counter, stack pointer, vector base register, and an internal mask for request values, initializes a vector table for support of exceptions in Intel space and allows for registration of support functions.

The M68k emulator kernel 56 provides for the ability to register functions to support particular operations. Specifically, functions can be registered to support a stop instruction, a background exception and a reset instruction. The stop instruction is supported as a default condition and is enabled unless a function is registered during initialization. In such a case, the new function is executed instead of the regular functionality (blocks 302 to -306). A routine is provided to take advantage of the stop instruction to exit gracefully from the M68k emulator kernel,

The background exception is provided to support an interface (a communication path) between the M68k code space and the Intel 80x86 native environment. The Emu681nitialize routine checks to see if the background exception

3 8 is supported. A stub is provided if the background exception is not implemented (blocks 308 to 312).

The reset instruction is used to trigger events in the Intel 80x86 native environment, hardware units, etc. The Emu68kInitialize routine also checks to see if the reset instruction is supported. A stub is provided if the reset instruction is not used (blocks 14 to 3 18).

Once the stop instruction, background exception and reset instruction have been supported, the M68k emulator kernel 56 executes an Emu68kInitExceptionsVectors routine (block 320). This routine offers the opportunity to bind to the M68k exception vectors and execute the bound functionality utilizing routines in Intel space. During initialization the vector table for these functions is cleared and initialized to a known state. Following this, an Emu68kSetupRequestMask routine and an Emu68kHwReset routine are executed (blocks 322 and 324) The clean-up of the M68k emulator kernel environment is performed by an Emu68kDestroy routine. This routine releases the memory spaces allocated to the M68k emulator kernel 56 at initialization. The M68k emulator kernel does not instantiate separate threads and thus, none must be closed during clean-up.

Memory Access Component During the start-up sequence of the M68k emulator kernel 56, the memory 72 is reserved and then the M68k instructions are loaded from file and stored into memory. The following sections describe the various functions available to interface to the M68k memory space.

The memory is reserved (and initialized to zero) during initialization of the M68k emulator kernel 56 by calling an Emu68kReserveMemory routine and is freed durina clean-up/destruction by calling an Emu68kReleaseMemory routine. The memory space is contiguous from the point of view of the M68k code. The memory may not, in fact, be physically contiguous, but Windows NT performs the background work to ensure that the virtual memory space as seen by the M68k emulator kernel 56 behaves as a contiguous section.

Amongst the differences in design of Motorola and Intel microprocessors one is of special concern, namely the big endian, little endian approach to memory usage. In the big endian scheme, data which must be stored using more than a single byte has its most significant byte stored first and the least significant byte stored last (with any intermediate bytes arranged in order between these two extremes). The little endian approach, of course, has the opposite arrangement. The least significant byte is stored first and the most significant byte is stored last. For both schemes, the bits of a byte are arranged identically. For example, a 3 2-bit integer with numerical value of 6, is represented by the bits 110 in byte 3) for a big endian scheme, but in byte 0 for a little endian scheme. Motorola microprocessors are based on the big endian scheme, while the Intel microprocessors C1 use the little endian scheme.

The data is stored in memory 72 following the big endian scheme (Motorola) and is utilized by the M68k emulator kernel 56 in little- endian scheme. Within the M68k emulator kernel, all instructions which access memory areas are generated with byte swapping algorithms if required. Various routines are provided for external programs to deal with reading and writing information to memory and automatically to take care of the endian concern by performing byte swapping where necessary. These routines include an Emu68k.ReadByte routine, an Emu68k.ReadWord routine, an Emu68kReadLong routine, an Emu68kWriteByte routine, an Emu68kWriteWord routine and an Emu68kWriteLong routine.

To copy, store or retrieve large quantities of data, two other routines are provided, namely an Emu68k.ReadArray routine, and an Emu68kWriteArray routine. These routines do not provide compensation for the endianconcern. When dealing with structures, it is impossible to know the format of the data within.

To provide yet another tool, an Emu68kGetNtMemoryPtr routine is provided to interface with the M68k memory space directly. This routine returns a pointer in NT space to a required memory address within the M68k memory space.

Copying and writing directly from and to the M68k memory space is available via this routine.

In order to write M68k code to the memory 72, an Emu68kWriteSRecord routine is called. When called, the Emu68kWriteSRecord stores M68k code in the memory 72 using the S-Record format. Only S2 and S3) formats are supported by the M68k emulator kernel 56. The format specifies where within the memory the M68k code must be positioned. Multiple code segments may be written to memory by calling the routine repeatedly.

Z> Figure 3 1 shows the Emu68kWriteSRecord routine and as can be seen, the routine employs subroutines to complete the work. The subroutines invoked by the Emu68k Write S-Record routine include an Emu68kProcessSRecord subroutine, an Emu68kGetByte subroutine, and a Emu68kWriteByte subroutine.

The Emu68kProcessSRecord subroutine is responsible for supporting the S-Record format and is best illustrated in Ficure 32. This routine reads the bytes contained in the S-Records utilizing the Emu68kGetByte subroutine and interprets them. Once the data section of the S-Record is interpreted, the information is written to memory 72 using the Emu68kWriteByte subroutine.

Each time the Emu68kGetByte subroutine is used to determine a field (could be multiple calls generating a single value such as a long), a test is performed to check the validity of the data. Should the function indicate that an error condition occurred, the Emu68kProcessSRecord subroutine returns passing along an error code.

The Emu68kProcessSRecord subroutine also returns due to errors in the case of a checksurn error (calculated does not match with value within record), in the case of bad data (error conditions during the Emu68kGetByte subroutine) or in the case where the address indicated in the S-Record exceeds the limit of the memory reserved during initialization.

Re,aisters Componen The M68k emulator kernel 56 is designed around the concept of replacing an actual microprocessor. The interfaces provided use global variables. A C) -41 protection layer should be provided around the M68k emulator kernel to ensure that rgisters, memory and other components are not loosely modified. As mentioned e., previously, a variety of M68k registers are supported and available for use and include the program counter (PC), the status register (SR), the user and supervisor stack pointets (USP& SSP respectively), the data registers (Dn), the address registers (An), the vector base register (VBR), the source function code (SFC), and the destination function code (DFC). All of the registers are available as variables of size long tz, (double word).

io Requests Componen Requests (software exceptions and hardware interrupts) are handled within the emulator kernel 70. These consist of either hardware interrupts (set externally) or software exceptions (the SX2000 code relies on the current handlers contained within its load such as those prepared to support the Low Level Debugger functionality). All M68k exceptions are supported. However, for expediency in processing, the seven hardware interrupt exceptions are treated as separate entities.

Along with the status of the hardware interrupts, the InterruptRequest variable (long) indicates the status of software and system exceptions. The requests covered by the InterruptRequest variable include 7 levels of hardware interrupts (1 to 7), software exceptions (used to flag and process the software exceptions - traps, etc.), a termination exception (used to step through the code one instruction at a time), a stop exception, and a background exception (band instruction is used as a system exception). Each exception and interrupt is represented by a bit in the InterTuptRequest variable.

During initialization, a request mask is set-up to allow use of enumerated defines to refer to the various exceptions. This is used to provide a layer of abstraction from the code allowing more flexibility when updating or modifying C> W code. The routine responsible for this is Emu68kSetupRequestMask.

In the M68k emulator kernel 56 there are effectively two types of requests, namely those that are available to anyone such as hardware interrupts and the termination exception and those that are of a restricted nature and limited to the M68k emulator kernel 56 such as software exceptions in progress, a stop exception, double bus error, etc.

Various routines are provided to set, clear and test the requests. These routines include an Emu68kRequestSet routine, an Emu68kInternalRequestSet routine, an Emu68kRequestClear routine, an Emu68klntemalRequestClear routine, an Emu68kRequestTest routine which tests if the desired request has been set, an Emu68kIntemalRequestTest routine, an Emu68kRequestTestEquality routine which tests if the desired request is the only one set, and an io Emu68kIntemalRequestTestEquality routine.

The "Emu68kIntemal..." routines are those used internally by the M68k emulator 56 and are not limited on the request to be set, cleared or tested. The other routines, which are available for external use, use these internal routines to perform the functionality, but first call an Emu68kRestrictRequest routine to restrict access to the hardware interrupts and the termination exception. An error is returned if the function is attempted on a restricted request.

Figure 33 shows a sample flow chart and sample data flow diagram of an "Emu68kRequest..." routine.

Although the M68k emulator kernel 56 is designed around the concept of replacing an actual microprocessor, the M68k emulator provides some enhancements. In particular, the M68k emulator kernel 56 provides the opportunity to set (i.e. trigger) some of the base exceptions. The supported base exceptions are bus error (vector 2), address error (vector 3), illegal instruction (vector 4), divide by zero (vector 5), CHK instruction (vector 6), TRAPV instruction (vector 7), and privilege violation (vector 8).

The interface provided allows internal M68k emulator kernel variables to be modified thus triggering an exception. Once the exception has been generated (this occurs in NT space), the exception is processed as soon as the emulator kernel 70 has a chance to execute Exceptions are set by passing the vector number (enumerated as above) to an Emu68kGenerateException routine. With a simple function call, the response to an address error, divide by zero, privilege violation, etc. can be tested without complicated steps in the emulated environment. An Emu68kRequestExitEmulator routine is also provided and sets a termination request and thus the termination of the main program loop. The routine can be called while servicing the background exception (or any other system exception that can be registered) to provide an organized exit form the emulator kernel 70.

The M68k emulator kemel environment provides possibilities not available in the native M68k microprocessor. The M68k emulator kernel can use the occurrence of exceptions in M68k space to trigger the execution of functions in NT space. This enables the exception to be debugged andlor logged in NT space. This has the advantage of being faster because code is executed in native Intel, and of becoming more integrated with the system using the emulation system.

Two routines are used to support binding exceptions, namely an Emu68kInitExceptionVectors routine, and an Emu68kBindExceptionVector routine.

Clearing and pre-setting the vector table occurs during initialization of the M68k emulator by calling an Emu68kInitExceptionVectors routine. This forces the vector table to a known state. Within the emulator kerriel, this state is used to indicate that no routines have been bound and that normal M68k exception processing should be performed. A function can be bound to any (or many) given exception vector by calling an Emu68kBindExceptionVector routine. The routine will then be executed when the exception occurs and it will be processed before normal M68k exception processing, Exceptions can be triggered externally to trace the execution flow or triggered internally to indicate that extemal processing is required. System exceptions exit from the M68k emulator kemel 56 (some temporarily) to the native system where they are processed and supported.

The M68k kernel 56 emulator supports a number of system exceptions, namely:

Termination (to perform a single instruction at a time and to exit emulator kernel); Stop (support stop instruction); DBErr (support a double bus error); and Background (used to remove control from the M68k emulator kernel

0 and return it to the calling function. This instruction has no relation to the BGINID instruction of the Motorola 68040.

System Exception Once a system exception is triggered, the emulator kernel 70 is exited and the Emu68kSystemExceptions routine (shown in Figure 34) is called to service the exception. A Debug exception is used to exit to the system. This system exception is only set by the Emu68kStep routine. It is used as a means of exiting, the emulation kernel and returning to the system. The availability of this exception makes the step functionality available.

The stop exception is used to support "STOP" instructions. The stop instruction prevents further processing, until a trace, interrupt or reset exception occurs. For interrupts, only those with a priority higher than that selected at the time the Stop instruction is called are considered.

The double-buss-error (DBErr) exception is used to indicate that a double bus error has occurred.

The background exception is used to exit from within the emulator kernel 70 and continue processing of specified functionality. The exception is triggered by a call from the M68k code to the band instruction (introduced into emulated environment for this purpose). Each M68k instruction must be emulated by a multitude of 80x86 instructions and requires a proportionately high CPU time to execute when compared to a single native 80x86 instruction. It is an advantage whenever possible to process functionality outside the M68k emulator 56 and directly on the 80x86 platform. This includes both re-coding current functionality and writing implementations for new processes. Also a good reason to trigger external processing 00 is the possibility to interface with PC hardware or to take advantage of Windows NT abilities or tools to communicate with other processes and/or threads.

The Emu68kSystemExceptions routine calls a number of subroutines to support these exceptions. Specifically, the Emu68kSystemExceptions routine calls s an Ernu68kServiceDBErr subroutine to support double bus exceptions, calls an Emu68kServiceStop subroutine to support stop exceptions and calls an Emu68kServiceBackground subroutine to support background exceptions.

A reset instruction makes a direct call to an Emu68kSoftwareReset routine which in turn calls whichever function has been set-up to support the reset 10 functionality (i.e. either the built-in stub function or a function registered during initialization).

As will be appreciated by those of skill in the art, the emulator generator design is based on a table-driven philosophy allowing the overall design to be examined without getting lost in details. Detailed information however is readily available by inspecting the tables. The emulator generator 52 prepares the emulation routines to emulate each M68k instruction and prepares a jump-table that provides linking addresses to the emulation routines prior to running the M68k emulator kernel 56. When the M68k emulator kernel reads M68k instructions, it can quickly access and execute the corresponding emulation routines using the jump-tables to carry out the M68k instructions. This of course allows legacy code to be executed at high speeds while providing access to new tools, applications and functionality.

Although a preferred embodiment of the present invention has been described, those of skill in the art will appreciate that variations and modifications may be made without departing from the spirit and scope thereof as defined by the appended claims.

46 APPENDIX A S-Record Format An S-record file consists of a sequence of specially formatted ASCII character strings. An S-record 0 will be less than or equal to 78 bytes in length. The order of S-records within a file is of no 0 significance and no particular order may be assumed. The general format of an S-record follows:

0 type 1 count addr dat Type A char[2] field. These characters describe the type of record (SO, S I, S2, S3, S5, S7, S8 or

S9) Count A char[2] field. These characters when paired and interpreted as an hexadecimal value, display the count of remaining character pairs in the record 0 Address A char[4, 6, or 8] field. These characters grouped and interpreted as an hexadecimal value, display the address at which the data field is to be loaded into memory. The length of the field depends on the number of bytes necessary to hold the address. A 2-byte address uses 4 characters, a 3- byte address uses 6 characters, and a 4-byte address uses 8 characters.

Data A char[O-64] field. These characters when paired and interpreted as hexadecimal values represent the memory loadable data or descriptive information.

Checksum A char[2] field. These characters when paired and interpreted as an hexadecimal value display the least significant byte of the ones complement of the sum of the byte values represented by the pairs of characters making up the count, the address, and the data field.

0 Each record is terTninated with a line feed. If any additional or different record terminators(s) or delay characters are needed durina the transmission to the target system it is the responsibility of the transmitting program to provide them.

SO record The type of the record is 'SO' (0x53,30). The address field is unused and will be filled with zeros (0x0000). The header information within the data field is divided into the following subfields:

mname - is char[20] and is the module name ver - is char[2] and is the version number rev - is char[2] and is the revision number description is char[0-36] and is a text comment Each of the subfields is composed of ASCII bytes whose associated characters, when paired, represent one byte hexadecimal values in the case of the version and revision numbers, o represent the hexadecimal value of the ASCII characters comprising the module name and description.

APPENDIX A - CON'T S 1 record The type of record is 'S 1' (0x533 1). The address f leld is interpreted as a 2-byte address.

The data field is composed of memory lodable data.

S2 record The type of record is 'S2' (0x5332). The address field is interpreted as a 3-byte address.

The data field is composed of memory lodable data.

S3 record The type of record is 'SY (0x5333). The address field is interpreted as a 4-byte address.

The data field is composed of memory lodable data.

S5 record The type of record is 'SY (0x5335). The address field is interpreted as a 2-byte value and contains the count of S 1, S2 and S3 records previously transmitted. There is no data field.

S7 record The type of record is 'P' (0x5337). The address field contains the starting execution address and is interpreted as a 4-byte address. There is no data field.

S8 record The type of record is 'SW (0x5338). The address field contains the starting execution address and is interpreted as a 3-byte address. There is no data field.

S9 record The type of record is 'S9' (0x53)39). The address field contains the starting execution address and is interpreted as a 2-byte address. There is no data field.

Example:

S00600004844521B S!130000285F245F2212226A000424290008237C2ASl!300100002000800082629001853812341001813 S113002041E900084E42234300182342000824A952 S107003000144ED492 S5030004F8 S9030000FC The file consists of one SO record, four S] records, one S5 record and a single S9 record.

Claims (1)

1. We Claim:

   1. An emulation system to allow code written for a specific computing environment to be run on a different microprocessor platform comprising:

   an emulation routine generator including a table storing code segments corresponding to instructions of said specific computing environment, said emulation routine generator creating said emulation routines written in code for said different microprocessor platform from selected code segments in said table, said emulation routines corresponding to instructions of said specific computing environment; :D 0 2. An emulation system as defined in claim 1 wherein said emulation routine generator creates an entry in a jump-table for each created emulation routine, each entry including linking addresses to said associated emulation routine.

   0 ZIP an emulator kernel to read instructions of said specific computing environment and access and execute emulation routines thereby to emulate and carry out said read instructions; and an interface resembling said specific computing, environment.

   cl An emulation system as defined in claim 2 wherein said emulation routine generator stores said emulation routines in an emulation code structure, said emulation code structure being divided in a plurality of assembly files.

   4.

   An emulation system as defined in claim 3 wherein a nibble of each instruction is used to determine the assembly file of said emulation code structure into 25 which the corresponding, emulation routine is stored.

   C) 5. An emulation system as defined in claim 4 wherein entries in said jump-table are stored in a plurality of assembly files.

   4 9 - 6. An emulation system as defined in claim 3) further including a data table storing information describing the characteristics of all instructions of said specific computing environment, said information beincr accessed by said emulation Z> 0 routine generator and used to select code segments from said table when creating said 0 emulation routines.

   7. An emulation system as defined in claim 6 wherein said emulation routine generator includes an input component to access said data-table; an emulation routine generation component responsive to said input component to select code segments from said table; and an output component to piece said code segments together and write said code segments to said emulation code structure to form said emulation routines, said output component also creating said jump-tables.

   0 8. An emulation system as defined in claim 7 wherein said emulator kernel is operable in a run mode, in said run mode said emulator kernel reading an instruction from said memory, executing the associated emulation routine and 7Z repeating the above steps for subsequent instructions in said memory.

   9.

   the form of an emulator API.

   An emulation system as defined in claim 8 wherein said interface is in 10. An emulation system as defined in claim 9 wherein said interface includes a control component operable to condition said emulator kernel to said run and step modes.

   11. An emulation system as defined in claim 10 wherein said interface further includes a requests component to generate said exceptions, a register 0 W component and a memory access component.

   so- 12. An emulator aenerator to cenerate emulation routines to be executed by an emulator r=ing on one microprocessor platform to emulate instructions of a different microprocessor platform comprising: a table storing code segments corresponding to instructions of said s different microprocessor platform; an emulation routine generation component creating emulation routines from selected code segments in said table, said emulation routine generation component further creating an entry in a jump-table for each created emulation routine, each said entry including linking addresses to said associated emulation 10 routine.

   An emulator generator as defined in claim 12 wherein said label is resolved into linking addresses for said emulation routine.

   14. An emulator zenerator as defined in claim 13 wherein said emulation routine generator stores said emulation routines in an emulation code structure, said emulation code structure being divided in a plurality of assembly files.

   0 15. An emulator aenerator as defined in claim 14 wherein a nibble of each 0 instruction is used to determine the assembly file of said emulation code structure into which the corresponding emulation routine is stored.

   zn 16. An emulator generator as defined in claim 15 wherein entries in said jump-table are stored in a plurality of assembly files.

   17. An emulator generator as defined in claim 16 further including a datatable storing information describing the characteristics of all instructions of said 1 1 specific computing environment, said information being accessed by said emulation routine aenerator and used to select code seaments from said table when creatine, said 0 emulation routines.

   18. An emulator (yenerator as defined in claim 17 wherein said emulation routine generator includes an input component to access said data-table; an emulation routine generation component responsive to said input component to select code segments from said table; and an output component to piece said code segments together and write said code segments to said emulation code structure to form said emulation routines, said output component also creating said jump-tables.