Emulating operating system calls in an alternate instruction set using a modified code segment descriptor

Description Submit all comments and votes

BACKGROUND OF THE INVENTION--FIELD OF THE INVENTION

The present invention relates to a dual-instruction-set processor, and more particularly to a method and apparatus for emulating operating system calls using instructions from a second instruction set.

BACKGROUND OF THE INVENTION--DESCRIPTION OF THE RELATED ART

An enormous base of software has been written for existing operating systems such as the DOS.TM. and Windows.TM. operating systems produced by Microsoft Corporation of Redmond, Wash. However, these operating systems presently must be executed on x86 microprocessors manufactured by Intel Corporation of Santa Clara, Calif., and others. The x86 architecture is an old complex instruction set computer (CISC) architecture and is quite different from today's highly optimized reduced instruction set computers (RISCs).

It is greatly desired to use newer RISC processors since they are potentially less expensive and faster. The PowerPC.TM. architecture by IBM, Motorola and Apple Computer uses a RISC instruction set. However, the PowerPC.TM. cannot directly execute programs written for x86 CISC operating systems such as DOS.TM. and Windows.TM.. Emulation programs such as the SoftPC program by Insignia Corporation translate x86 CISC instructions to RISC instructions, but the performance is reduced relative to running x86 code directly.

A dual-instruction-set CPU was disclosed in the related application entitled "Dual-Instruction-Set Architecture CPU with Hidden Software Emulation Mode", filed Jan. 11, 1994, U.S. Ser. No. 08/179,926. That application is assigned to the same assignee as the present application. The dual-instruction set CPU contains hardware so that it can decode instructions from two entirely separate instruction sets.

What is desired is a method and apparatus to trigger a switch from one instruction set to another instruction set when a call to a support routine in an operating system is made.

SUMMARY OF THE INVENTION

The present invention allows code from a first instruction set to reside within a segment defined by a second instruction set. For example, RISC instruction code may reside within a CISC segment. The CISC architecture is extended to provide for segments that can hold RISC code or CISC code.

In a broad sense the present invention is directed toward a segment descriptor for a dual-instruction-set processor. The processor executes instructions from a first instruction set and a second instruction set that are substantially independent. The segment descriptor describes a segment in memory containing program code. The segment descriptor has a location indicating means for indicating a location of the segment in the memory; attribute indicating means for indicating attributes of access to the segment; and an instruction set indicating means for indicating that an instruction set of the program code located within the segment belongs to one of a first instruction set and a second instruction set.

The instruction set indicating means has a first state for indicating that the program code contains instructions from the first instruction set, and a second state for indicating that the program code contains instructions from the second instruction set. The program code in the segment contains instructions from one of the first instruction set and the second instruction set.

In another aspect of the present invention the first instruction set is a complex instruction set computer (CISC) instruction set while the second instruction set is a reduced instruction set computer (RISC) instruction set. The first instruction set has a first encoding of operations to opcodes, while the second instruction set has a second encoding of operations to opcodes. The first encoding of operations to opcodes is substantially independent from the second encoding of operations to opcodes. Thus the two instruction sets may be entirely separate and independent instruction sets.

An undefined or reserved bit within the segment descriptor is used for the instruction set indicating means to indicate which instruction set the program code in the segment is written in. The switch from CISC to RISC instruction decoding is triggered when control is transferred to a new segment, and the segment descriptor indicates that the code within the segment is written in the alternate instruction set.

The present invention allows an existing user program written in CISC code to call a service routine in an operating system that is written in RISC code. Thus existing CISC programs may be executed on a dual-instruction-set processor which can execute RISC code to emulate a CISC operating system.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 shows the steps to service an x86 hardware interrupt.

FIG. 2 is a CISC call gate descriptor.

FIG. 3 is a block diagram of a CPU with segmentation and paging.

FIG. 4 is a diagram of a CISC segment descriptor.

FIG. 5 is a block diagram of a dual-instruction-set CPU.

DETAILED DESCRIPTION

The present invention relates to an improvement in processing. The following description is presented to enable one of ordinary skill in the art to make and use the present invention as provided in the context of a particular application and its requirements. Various modifications to the preferred embodiment will be apparent to those with skill in the art, and the general principles defined herein may be applied to other embodiments. Therefore, the present invention is not intended to be limited to the particular embodiments shown and described, but is to be accorded the widest scope consistent with the principles and novel features herein disclosed.

A dual-instruction-set CPU was disclosed in the related application entitled "Dual-Instruction-Set Architecture CPU with Hidden Software Emulation Mode", filed Jan. 11, 1994, U.S. Ser. No. 08/179,926, hereby incorporated by reference. That application is assigned to the same assignee as the present application. The dual-instruction set CPU contains hardware so that it can decode instructions from two entirely separate instruction sets. A page fault or exception would cause the instruction set being decoded to switch. Thus if a page fault occurred when the CISC instruction set was being decoded, execution would switch to the RISC instruction set. CISC instructions that were not directly supported in hardware would also cause a switch to the RISC instruction set.

Although the related application works effectively for many applications, calls from user programs to support routines in the x86 CISC operating system do not normally cause an exception or page fault to occur. Thus the support routines in the operating system would be executed from x86 CISC code. Since RISC code is believed to be more efficient than x86 CISC code, it would be preferable to execute as much code as possible in RISC rather than in CISC. Because of the enormous number of user programs written in x86 CISC code, it is not feasible to convert each program over to RISC code. Indeed, it is highly desirable to be able to execute unmodified user programs. However, most of these user programs use (or call) support routines that are supplied by the operating system. Since DOS.TM. and Windows.TM. are by far the most widely used operating systems on personal computers (PC's), it is desired to write RISC code for emulating the support routines in these two operating systems. Thus when an x86 CISC user program calls a support routine in either the DOS.TM. or Windows.TM. operating systems, the support routine could be written in the RISC code, improving performance over the original support routine written in x86 code. However, a method is needed to trigger the switch from decoding CISC instructions to decoding RISC instructions when the support routine is called.

The operating system (O/S), or possibly the Basic Input/Output System (BIOS), may provide support routines that a user program may access. The user program may transfer control to the operating system in the following ways:

Exception

External Interrupt

Software Interrupt

Far Call or Far Jump.

Each of these methods to transfer control from a user program to the operating system will be discussed next.

EXCEPTIONS

An exception occurs when an instruction is executed that causes some sort of error. A divide instruction that attempts to divide by zero would cause a divide-by-zero exception, invoking a service routine in the operating system to handle the error. The service routine in this case would typically display an error message to the user and terminate the program.

Other causes of exceptions include attempting to execute an undefined or illegal opcode, reaching a program check or break point, attempting to access memory that is out of the bounds for the segment, writing to a read-only segment, or accessing a segment that is valid but is not currently present in the system RAM. Page faults, where the page of memory being accessed is not present in the main memory but only on the disk, can also cause an exception.

The proper service routine is determined by accessing an interrupt table or interrupt descriptor table to fetch the starting address for the service routine for the particular exception. When an exception occurs, control is transferred to a service routine for the particular exception. The processor itself, however, supplies an entry number for an interrupt table.

EXTERNAL INTERRUPTS

An external device may signal an interrupt to the processor. For example, a user may strike a key on the keyboard, which would generate a keyboard interrupt to the processor. The processor will perform an external interrupt acknowledge cycle to allow the external device to identify an interrupt number. The interrupt number identifies an entry in the interrupt table which points to a service routine in the operating system for the external device.

SOFTWARE INTERRUPTS

A wide variety of O/S support routines may be accessed by programming a software interrupt into the user code. A software interrupt is an instruction that emulates a hardware interrupt. The software interrupt instruction causes the interrupt table to be accessed. The software interrupt instruction has a parameter that specifies a unique entry in the interrupt table. When an interrupt is encountered, the interrupt table is consulted to determine the address where the interrupt service routine is located in memory. The processor loads this address and begins executing instructions from this address, the location of the service routine. Upon completion of the service routine, control is transferred or returned back to the user program. Application programs running under DOS typically use software interrupt instructions to invoke DOS routines.

FAR CALLS AND JUMPS

Application programs running under Windows.TM. occasionally use software interrupts to invoke operating system routines, but the bulk of the Windows.TM. operating system routines are invoked by a far call instruction. For example, a user application may call the "CreateWindow" command while running under Windows.TM. to have a new window opened. The user application program executes a far call instruction to transfer control to a different segment where the Windows.TM. CreateWindow routine is located. A far call is a transfer of control to code which resides in a different segment, which also saves the instruction pointer and code segment register onto a stack in memory. The CreateWindow routine returns to the application program by executing a far return instruction, which restores the instruction pointer and code segment from the stack.

A segment descriptor is accessed and examined when a far call occurs, because control is transferred to a new segment. However, no interrupt is signaled.

INTERRUPT SERVICE ROUTINES

Many support routines supplied by the operating system are accessed when an external hardware interrupt is signaled to the processor. FIG. 1 shows the steps to service an x86 hardware interrupt. In the x86 architecture, only one pin or input to the processor is provided for most interrupts. Therefore, the processor must determine what the cause of the external interrupt is by generating an interrupt acknowledge cycle, when the external devices send an interrupt number or vector back to the processor. The interrupt vector specifies the device causing the interrupt, for example the keyboard. The interrupt vector is also known as an entry number, which specifies an entry in an interrupt table stored in memory. In the x86 architecture, the entry number is multiplied by eight, since each entry in the interrupt table occupies eight address locations, to specify the address of the entry in the interrupt table in memory. The entry stored in the interrupt table is a starting address where a support routine to service the interrupt is stored. The starting address of the interrupt service routine is loaded into the processor's instruction pointer and code segment register, while the old values for the instruction pointer and code segment register, and the flags register, are stored on a stack in memory.

The support routine is then executed starting with the instruction fetched from the starting address stored in the entry in the interrupt table. The support routine, or interrupt service routine, is executed, and control is returned to the user program when the end of the service routine is reached, by retrieving the old values for the instruction pointer, code segment and flags registers from the stack.

As an example, the user may strike a key on the keyboard. The keyboard controller would signal to the processor an interrupt request over the shared interrupt input. The processor then "services" this interrupt. First, an interrupt acknowledge cycle is run when the keyboard's interrupt number, 09 hex, is supplied to the processor. The interrupt number is multiplied by 8 hex, and the result, 48 hex, is tadded to the interrupt descriptor table base register, yielding the address of the keyboard's entry in the interrupt table. A memory cycle is run at this address to fetch the contents of the interrupt descriptor table entry number at 48 hex, and the contents are stored in the processor. The old instruction pointer, code segment and flags registers are stored to the stack, and then the contents of the keyboard's entry from the interrupt table are loaded into the instruction pointer and code segment register. Execution then transfers to the keyboard interrupt service routine pointed to by the contents of the keyboard's entry from the interrupt table, which is a starting address for the keyboard service routine. This routine performs an I/O read of the keyboard to determine which key was struck, and then terminates and returns control to the user program by retrieving the old instruction pointer, code segment and flags registers from the stack.

To service an x86 software interrupt, the steps are similar to those for the hardware interrupt of FIG. 1 except that an external interrupt acknowledge cycle is not necessary because the software interrupt instruction specifies the interrupt number and entry.

INTERRUPT TABLE DESCRIPTORS

The entries in the interrupt descriptor table are descriptors, similar to descriptors for segments. An offset address in the interrupt descriptor provides the entry point within the code segment jumped to. A selector field in the interrupt descriptor identifies the segment the interrupt service routine is located in. Privilege and access checks are performed for the interrupt descriptor just as they are done for segment descriptors. The interrupt descriptor table may contain a special descriptor, called a task gate, which causes the interrupt service routine to run in a separate context.

CISC CONTROL TRANSFERS TO RISC

A signal is needed to cause the processor to switch the instruction set being decoded. An exception or interrupt can provide this signal, or a separate instruction can be defined to switch instruction sets. Jumping from a CISC user program to another segment written in RISC code without signaling an interrupt or exception could cause unpredictable results or even a system crash unless a method is employed to trigger the switch to