Code segment default operation determination

[0002] 1. Field of the Invention

[0003] The invention relates generally to programming microprocessors and more particularly to a method for determining the default size of operations in a code segment using instructions which are available to multiple privilege levels in multiple operating modes.

[0004] 2. Description of the Relevant Art

[0005] One of the functions of an operating system in a computer is to provide a simplified environment in which a software application can be executed. In the x86 architecture, the memory management function of the operating system creates separate logical address spaces for each of the applications executing on the system. By doing so, the memory management mechanism eliminates the need for each of the applications to individually check its memory references in order to avoid using memory locations used by other applications. The applications are thus allowed to execute without interference from each other.

[0006] The x86 architecture implements separation of the address spaces for the respective programs using a memory model referred to as segmentation. Segmentation provides each of the applications with an address space having several separate, protected segments. The segments appear to the application to be contiguous so that there is no need for the programmer to write position-dependent code. Memory references to the individual segments may only refer to data in those segments so that, for example, a stack cannot grow into the code or data of an application. The limits of the segments are enforced by hardware in the computer system. (Particular segments can, however, be shared by more than one application.) Memory addresses which appear to an application to be fixed are referenced by the operating system as offsets from the beginning of one of the segments.

[0007] Referring to FIG. 1, a block diagram of a typical memory management model for a system having an x86 architecture is shown. The fixed, logical address used by an application is translated by the segmentation mechanism into a linear address. If the computer system does not have a paging mechanism, the linear address is also the physical address of the memory location. The paging mechanism swaps “pages” of memory between the memory and the system's hard disk or other persistent storage devices to simulate an address space which is larger than the available memory. If a paging mechanism is implemented, this mechanism translates the linear address into a physical address.

[0008] The operating system's memory management mechanism keeps track of the various segments by using segment descriptors. Segment descriptors contain data defining the size and location of the segments, as well as control and status information. The segment descriptors are stored in an array called the segment descriptor table. There are actually two types of segment descriptor table: the global descriptor table (GDT); and local descriptor tables (LDT). The GDT contains segment descriptors for all tasks (applications being executed.) There is an LDT for each task which includes descriptors for only that task. A descriptor table can have a variable length and, in the x86 architecture, may contain up to 8192 (2¹³) segment descriptors. The first entry in the GDT is a null descriptor which may be used to initialize segment registers. A memory reference to the null descriptor will generate an exception.

[0009] Referring to FIG. 2, a diagram illustrating the components of a segment descriptor is shown. Each segment descriptor contains information on one of the segments, including the size and location of the segment. The size and location are also referred to as the segment limit and base address, respectively. In the x86 architecture, the segment limit uses 20 bits of the descriptor. The descriptor also includes a granularity bit which, if set, scales the limit field by a factor of 4096 (2¹²). The base address uses 32 bits of the descriptor. The remaining bits of the descriptor comprise an S-bit (which identifies the segment as a code/data segment or a system segment), a D-bit/B-bit (which indicates the default length for operands and addresses in code/data segments), a type field, a descriptor-privilege-level bit and a segment-present bit.

[0010] A particular segment can be accessed by loading the appropriate segment selector into one of the six segment registers available in the x86 architecture. These registers store segment selectors for a code segment (CS), a stack segment (SS) and up to four data segments (DS, ES, FS, GS). While an application can have more than six segments, only six can occupy the segment registers, so only those six are ready for immediate use at any given time. The segment selector includes two bits which indicate the privilege level associated with the segment, a bit which indicates whether the segment descriptor is in the GDT or the LDT, and a 13-bit index into the respective descriptor table.

[0011] Occasionally, it may be necessary or useful for a programmer to determine the default execution mode of the current code segment. That is, the programmer may need to determine whether the default size of operands and instructions in the code segment is 16 bits or 32 bits. A programmer who is writing library routines for use by both 16-bit and 32-bit programs, for example, may need to incorporate code to determine the default operating mode. Determining the default operating mode is accomplished by accessing the D-bit/B-bit in the segment descriptor. As pointed out above, the D-bit/B-bit in a segment descriptor indicates the default length for operands and addresses in corresponding code/data segments In the prior art, the D-bit/B-bit could be accessed using the following code sequence:

[0012] This code sequence is illustrative of the numerous steps which must be taken simply to access the code segment's D-bit/B-bit. The code sequence represents the steps of:

[0013] (1) XORing the 32-bit EDX register with itself to zero each bit in the register;

[0014] (2) moving the 16-bit segment selector for the code segment into the DX register (which forms the lower 16 bits of EDX);

[0015] (3) zeroing the lower 3 bits of DX by ANDing the segment selector value with f8 (because the last three bits are used to indicate the privilege level and descriptor table, while the upper 13 bits form an index into the table);

[0016] (4) placing the address of the GDT in the variable gdt_loc (the SGDT instruction is protected and can only be executed by the operating system);

[0017] (5) placing the address of the GDT in register EAX (this must be done separately from the previous step because the GDT address can only be retrieved through the SGDT instruction);

[0018] (6) placing in register EBX the location of the base address of the first entry in the GDT;

[0019] (7) adding to EBX the index portion (scaled by 8) of the code segment selector (i.e., placing in EBX the location of the base address of the code segment entry in the GDT);

[0020] (8) moving into register EAX the upper 32 bits of the code segment descriptor;

[0021] (9) testing the 22^ndbit of the value in EAX (the D-bit/B-bit) to determine whether or not it is set,

[0022] (10) if the D-bit/B-bit is set, jumping to the label @32BIT.

[0023] This method of determining the default operating mode is direct in that it determines the mode from the bit which defines the mode. The method has several drawbacks, however. For example, the user application must be operating in Protected Mode (in which the full 32-bit architecture of the computer system is available to the user.) The method is also relatively time-consuming in that it requires ten instructions simply to determine the state of a single bit in the descriptor.

[0024] One or more of the problems outlined above may be solved by the method of the invention. This method determines the default operating mode of the code segment based on the variation of the results which are obtained upon execution of an instruction in each of the two operating modes.

[0025] An instruction which modifies one of the x86 registers is selected. The instruction has a corresponding opcode which is valid for execution in both the 32-bit mode and the 16-bit mode. In the 32-bit mode, the instruction causes the 32-bit value in the register to be modified. In the 16-bit mode, the instruction causes the value in the register to be modified, but the modification is contained within the lower 16 bits of the 32-bit register—the lower 16 bits correspond to the 16-bit version of the register. The upper 16 bits of the 32-bit register remain unchanged by the instruction. The operands for the instruction are selected so that, if the instruction is executed in the 32-bit mode, the upper 16 bits of the 32-bit register will be altered by the instruction. After the instruction is executed, the 32-bit value contained in the register is examined to determine whether the upper 16 bits were altered by the instruction. If the upper 16 bits were modified, the default mode of the code segment is 32-bit. If the upper 16 bits were not modified, the default mode of the code segment is 16-bit.

[0026] In one embodiment, a general register such as the EAX register is zeroed (i.e., each of the bits is set to 0.) A move instruction specifying an immediate operand to be stored in the register is then executed. (The operand is one which does not have all 0's in the upper 16 bits.) The 32-bit operand is then compared to the 32-bit value in the register and, if they are the same, the instruction is known to have executed in 32-bit mode. Otherwise, the instruction is known to have executed in a 16-bit mode.

[0027] The inventive method requires less instructions than the prior art code sequence above and, accordingly, should execute in less time. The inventive method does not use protected instructions such as the SGDT instruction and can consequently be used in applications executing at all privilege levels. The method may also be used in modes other than protected mode.

[0028] Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:

[0029] FIG. 1 is a block diagram of a typical memory management model for a system having an x86 architecture.

[0030] FIG. 2 is a diagram illustrating the components of a segment descriptor in an x86 architecture.

[0031] FIG. 3 is a flow diagram illustrating the steps of one embodiment of the invention.

[0032] FIG. 4 is a diagram illustrating the relationship of 16-bit register AX to 32-bit register EAX.

[0033] While the invention is susceptible to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawing and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.

[0034] One embodiment of the inventive method is described in detail below. The method is used to determine the default operating mode of the current code segment. The default operating mode determines the default size of instructions and operands in the code segment. The method makes use of instructions which are available to all privilege levels (i.e., rings 0-3) and which can be executed in modes other than the protected mode.

[0035] An instruction is selected and executed to perform an operation on one of the 32-bit general registers. The selected instruction is one that has an opcode representation which is identical in both the 16-bit default operating mode and the 32-bit default operating mode. In the 16-bit default operating mode, the instruction can modify only the lower 16 bits of the register. In the 32-bit default operating mode, the instruction can modify both the upper 16 bits and the lower 16 bits.

[0036] The register is first set to a known state. An operand is selected for the instruction such that the execution of the instruction in the 32-bit operating mode will modify one or more of the upper 16 bits in the register. The instruction is executed and the register is subsequently examined to determine whether the upper 16 bits of the register have been modified. If these bits have been modified, the default operating mode is 32-bit. If the upper 16 bits have not been modified, the default operating mode is 16-bit.

[0037] In one embodiment, the method is implemented using a move instruction to modify the contents of a selected register. The instruction will move a specified immediate value into the register. The register will first be loaded with zeros by performing an exclusive OR (XOR) operation on the selected register. The move instruction will then be executed and the full 32-bit contents of the register will be compared to the 32-bit immediate operand value. A match indicates that the default operating mode is 32-bit.

[0038] This embodiment utilizes the following instructions:

[0039] The operation of these instructions is illustrated in FIG. 3. Referring to the figure, the method includes the steps of: zeroing the EAX register; attempting to move the value 90909090h into the EAX register; comparing the contents of the register to 90909090h; and executing instructions for 32-bit mode if the register contains 90909090h. If the register does not contain 90909090h, instructions for 16-bit mode are executed.

[0040] The “DB 0B8h” and “DD 90909090h” lines, respectively, actually comprise the first and second halves of the move instruction. (These two lines are therefore collectively referred to herein as a move instruction.) “DB” indicates that the following data byte (“B8”) should be entered in the instruction sequence. B8 is the one-byte hexadecimal opcode for a move instruction that stores an immediate value in the EAX or AX register. (If the default mode is 32-bit, the B8 opcode is recognized as a move to 32-bit register EAX; if the default mode is 16-bit, the opcode is recognized as a move to 16-bit register AX.) The line “DB 0B8h” in the program code therefore places the opcode B8 in the instruction sequence.

[0041] This opcode, however, requires an immediate value which is to be placed in the register, so the immediate value is inserted in the instruction sequence via the line “DD 90909090h”. “DD” indicates that the following data doubleword (“90909090h”) should be entered in the instruction sequence. This line thus places the four-byte (doubleword) value 90909090 (hexadecimal) in the instruction sequence.

[0042] Together, these two lines in the program code cause the five-byte sequence B8 90 90 90 90 to be placed in the instruction sequence. Depending on the default operating mode, these bytes will be interpreted in one of two ways. If the default mode is 32-bit, the sequence will be interpreted as a 32-bit immediate move to EAX followed by the immediate value 90909090. If the default mode is 16-bit, the sequence will be interpreted as a 16-bit immediate move to AX, followed by the immediate value 9090. The two bytes “9090” will then be treated as subsequent instructions. More specifically, they will be treated as two no-ops (each having the one-byte opcode 90). The immediate value 90909090 was selected for this implementation of the method because the portion of the value which is not used as the operand for the move instruction (the no-ops) can be executed without having any effect on the results of the move or the operation of the microprocessor.

[0043] As mentioned above, the method does not attempt to directly access the D-bit/B-bit which defines the default operating mode. Instead, it takes advantage of the fact that the move instruction achieves a different result in the 16-bit mode than it does in the 32-bit mode. In the 32-bit mode, the move instruction places the 32-bit value 90909090 (hexadecimal) into the EAX register. In the 16-bit mode, only the first 16 bits of the 32-bit immediate value are used, so the instructions move the 16-bit value 9090h into the AX register. As shown in FIG. 4, which illustrates the structure of register EAX, register AX forms the low-order 16 bits of EAX. Therefore, in 16-bit mode, 9090h is moved into the low-order 16 bits of EAX, while the high-order 16 bits of EAX are left unchanged. Thus, when the contents of EAX are compared to the immediate operand 90909090h, it can be determined whether the entire 32-bit value, or simply half of the value (16 bits), was moved into the register.

[0044] The method may utilize various instructions other than those described above. For example, the XOR instruction may be replaced with a move, an AND, or any other instruction or series of instructions which set the register to a known value. Likewise, the move instruction can be replaced with a move to a different register (in which case the preceding instructions would be chosen to manipulate the same register) or any other instruction which has the same opcode in both default modes, but only operates on half of the register in one of the modes. Further, although the embodiment described above is implemented in an x86 architecture, it is contemplated that the teachings of this disclosure can be extended to other architectures.

[0045] This method uses non-privileged instructions. (“Non-privileged” as used here means the instructions can be executed at any privilege level.) Because the present method does not use the SGDT instruction or other protected instructions, it can be implemented in software which does not execute in privilege level 0 (also known as ring-0 or kernel mode).

[0046] The method described above can also be used in modes other than protected mode. The method does not attempt to examine the D-bit/B-bit of the code segment descriptor, and consequently does not require manipulation of the 32-bit GDT location to get the address of the code segment descriptor from which the D-bit/B-bit is read. Because there is no need to manipulate these 32-bit values, the method is not restricted to the protected mode, which uses 32 bits, in order to preserve the 32-bit values. The method is therefore available to be used in real or virtual modes.

[0047] The method described above requires only four instructions (remember that the DB and DD assembly code instructions are actually halves of the same move instruction). The method may therefore execute more quickly than methods which use more instructions. As a result, the efficiency of the software which uses the method of this embodiment may be improved over those having more instructions.

[0048] The method is implemented via instructions which may be included in various software applications or library routines and may be embodied in magnetic disks or other storage media known in the art.

[0049] While the present invention has been described with reference to particular embodiments, it will be understood that the embodiments described above are illustrative and that the scope of the invention is not limited to these embodiments. Many variations, modifications, additions and improvements to the described embodiments are possible. These variations, modifications, additions and improvements are intended to be within the scope of the invention as detailed within the following claims.