Method and Apparatus for on the Fly Descriptor Validation

This application is related to copending U.S. application Ser. No. 08/871,039, filed on Jun. 9, 1997 entitled "METHOD FOR FAST VALIDATION CHECKING FOR CODE AND DATA SEGMENT DESCRIPTOR LOADS" to Glenn Henry, Terry Parks.

1. Field of the Invention

This invention relates in general to the field of memory segmentation, and more particularly to an improved method for loading code and data segment descriptors.

2. Description of the Related Art

Memory management is a hardware mechanism which lets operating systems create simplified environments for running programs. For example, when several programs are running at the same time, they must each be given an independent address space. If they all had to share the same address space, each would have to perform difficult and time consuming checks to avoid interfering with the others.

Memory management consists of two methodologies called segmentation and paging. Segmentation is used to give each program several independent, protected address spaces. Paging is used to support an environment where large address spaces are simulated using a small amount of RAM and some disk storage. When several programs are running at the same time, either mechanism can be used to protect programs against interference from other programs. The present discussion will focus primarily on segmentation.

Segmentation organizes memory into a collection of variable-size units, called segments. Within x86 processors, a two-part address is utilized to calculate a linear memory address: a segment part and an offset part. The first part of the address, the segment part, defines a base address for a memory segment, and is stored in a segment descriptor within a segment register. The offset defines a particular memory location which is offset from the base address. For a general background on segmentation in x86 processors, please see U.S. Pat. No. 4,442,484 issued to Childs, Jr. et al.

Referring to FIG. 1, a block diagram 100 of a prior art multi-segmented memory is shown. The block diagram 100 includes segment registers 102 which contain segment descriptors 104. The segment registers 102 are located within a register file of a microprocessor, not shown. The segment descriptors 104 define the base address of a segment in a memory 106, the size or limit of the segment, and various access and protection privilege attributes of the memory segment. Reference to a memory location is then specified by referring to a particular segment register 102, and by providing an offset. Once the base address of a segment is known, a specific location can be determined by a relative offset from this base location.

To access data within a given memory segment, a program first loads a segment register 102 with a special value that identifies that segment. This special value is called a selector. Programs then reference memory by specifying, either implicitly, explicitly, or by default, the segment register 102 containing the selector for the segment part of the address, and by providing an offset from the base address.

More specifically, the selector is used to index into a one of a number of descriptor tables which contain, descriptors. Descriptors define a base address for each segment, the largest offset than can be used with the segment (the limit), and various attributes of the segment such as whether the segment can be read from, written to, or executed as a program, the privilege level of the segment, and whether the segment has been previously accessed. The descriptor tables are stored in memory.

When access to a particular memory segment is desired, a program must first load a selector which identifies the segment into a segment register. Commensurate with the loading of the selector, the descriptor which defines the segment is loaded into a hidden or shadow register termed the descriptor register, which is associated with the segment register. Future references to the segment can then utilize the base address, limit, and attributes of the segment by retrieving the descriptor directly from the segment register (an on-chip access which is fast), without requiring access to one of the descriptor tables in memory (an off-chip slow process).

It is known to utilize different types of descriptors depending on what type of memory segment is to be accessed. For example, memory segments are often classified as either code, data or system. Associated with each of these memory segment types are corresponding code, data or system descriptors, by which the memory segments are defined and accessed.

When loading a segment register with a selector, and its associated descriptor, the selector is first loaded into a temporary register. Several tests are performed on the selector to insure that it is valid, i.e., that it actually references a descriptor. If the selector is valid, the descriptor corresponding to the selector is retrieved and placed into a temporary register.

Tests are then performed on the descriptor to determine whether the descriptor is valid, prior to the descriptor being stored in the descriptor register. Only after the selector and descriptor have been validated and stored can they be used to reference a memory segment. However, since the base address, limit and privilege level information is now resident in the segment register, subsequent protection checks on the same segment can be performed without a performance penalty. A more thorough discussion of descriptor validity tests is provided below in the Detailed Description.

Checking of the selector/descriptor to determine whether they are valid is very time consuming for the processor. Such checking, albeit necessary, adds further delay to the selector/descriptor load operation, and therefore to the time required before the desired memory segment can be accessed. If the type of memory segment which is being referenced is a code or data segment, one set of validity tests are performed on the descriptor. If the type of memory segment which is being referenced is a system segment, a different, more time consuming set of validity tests are performed.

In the prior art, to allow access to a memory segment to occur as fast as possible, validation of segment descriptors was performed in hardware, typically using a programmed logic array (PLA) within a processor. The contents of the temporary register which held the descriptor would be provided to descriptor validation logic. The descriptor validation logic would then indicate whether the descriptor was valid, thereby allowing the selector/descriptor to be stored within a segment register, or indicate the descriptor was invalid, thereby preventing the selector/descriptor from being stored in the segment register.

However, as was mentioned above, the validation tests which are necessary varies depending on whether a descriptor references a code, data or system type memory segment. Therefore, to validate descriptors as fast as possible, at least two sets of descriptor validation logic have been included within processors. A code/data descriptor validation logic was provided to validate code and data segments. A system descriptor validation logic was provided to validate system segments. The code/data logic was placed in parallel with the system logic so that validation of a descriptor would occur in parallel, whether the descriptor referenced a code, data or system memory segment.

Several problems result from providing different validation logic for different descriptor types. First, each validation logic PLA requires valuable transistor real estate space on a microprocessor. And, increased transistor space adds to the cost and power requirements of a microprocessor.

Second, it is believed that prior art microprocessors contain both the code/data validation logic, and the system validation logic, to complete verification of a descriptor before it can be stored within a segment register. Since system descriptor validation is more complex, and thus more time consuming to perform, descriptors which reference code/data memory segments are not stored into a segment register until after system descriptor validation has been performed. This adds further delay to the descriptor load process.

What is needed is a method for loading a segment register which minimizes delays typically associated with performing system descriptor validation during code or data descriptor loads. More specifically, what is needed is a method which eliminates processing delays associated with validating system descriptors when the descriptor being loaded corresponds to either a data or code segment.

What is also needed is an apparatus which allows the less time consuming code/data descriptor validation to occur "on the fly" during a descriptor load. "On the fly" meaning that no additional time is required, for validation, between reading the descriptor from memory, and storing the descriptor in the register file.

In addition, what is needed is a method for validating code/data descriptors, and system descriptors, but which requires only one descriptor validation logic circuit, thereby reducing transistor real estate cost within a microprocessor.

To address the above-detailed deficiencies, it is an object of the present invention to provide a method for improving the speed at which code and data descriptors are loaded.

It is another object of the present invention to validate code and data descriptors during the write back cycle of a processor.

It is a further object of the present invention to perform a descriptor load using a single micro instruction.

It is yet another object of the present invention to read descriptors from memory, and store valid code and data descriptors directly into a register file, without requiring additional processor cycles to validate the descriptors.

Accordingly, in the attainment of the aforementioned objects, it is a feature of the present invention to provide a microprocessor, which loads a descriptor directly from a memory into a descriptor register, without requiring that the descriptor be temporarily stored in an intermediate test location. The microprocessor includes the following. First, the microprocessor has an instruction buffer, which temporarily holds a descriptor load instruction that directs the microprocessor to load a descriptor. Secondly, the microprocessor has a data stage, which is coupled to the instruction buffer, that addresses the memory, and that retrieves a descriptor from the memory as designated by the descriptor load instruction. Third, the microprocessor includes code/data descriptor validation logic, which is coupled to the data stage, that views the descriptor retrieved from the memory, and that provides a valid/invalid output signal, depending on whether the descriptor is valid or invalid, on an output line. Finally, the microprocessor includes a descriptor register file, which has a write/enable input coupled to the output line of the code/data descriptor validation logic, and which is coupled to the data stage, that receives the descriptor retrieved by the data stage, and that writes the descriptor into a descriptor register within the descriptor register file when the code/data descriptor validation logic provides the valid output signal to the write/enable input.

An advantage of the present invention is that providing a fast validation circuit which can validate a code/data descriptor during a write cycle, and using a descriptor valid signal as the write enable to the register file, no additional processor cycles are required for validation of descriptors during a descriptor load.

In another aspect, it is a feature of the present invention to provide a method which loads a descriptor into a descriptor register within a microprocessor. The method includes reading a descriptor from memory, writing the descriptor to a descriptor register, and while writing the descriptor to the descriptor register, validating the descriptor. If the descriptor is valid, the step of writing the descriptor is enabled to allow the descriptor to be written into the descriptor register. If the descriptor is not valid, the step of writing the descriptor is disabled to prevent the descriptor from being written into the descriptor register.

These and other objects, features, and advantages of the present invention will become better understood with regard to the following description, and accompanying drawings where:

FIG. 1 is a block diagram of a prior art multi-segment memory model.

FIG. 2 is a flow chart illustrating a prior art method for loading a descriptor.

FIG. 3 is a block diagram of data, code and system segment descriptors, and a 32-bit call gate.

FIG. 4 is a table defining the segment types for data and code descriptors.

FIG. 5 is a table defining the segment types for system descriptors.

FIG. 6 is a block diagram of a portion of a pipeline processor which contains hardware validation logic for both system descriptors and code/data descriptors.

FIG. 7 is a block diagram of a portion of a pipeline processor, according to the present invention, which contains hardware validation logic for code/data descriptors.

FIG. 8 is a flow chart illustrating a method for validating a descriptor, according to the present invention.

FIG. 9 is a flow chart illustrating the parallel nature of the validation and store operations during a descriptor load according to the present invention.

As mentioned above, before data in a memory segment can be accessed by a program, the segment must be made addressable by loading the selector/descriptor for the segment into a segment register. A general description of how a segment register is loaded, including how the segment descriptor is loaded into the associated shadow descriptor register will be provided below with reference to FIG. 2.

As an overview, when a selector is loaded, it is first checked for validity. If these checks fail, an exception is raised and the segment register is not modified. If the selector is valid and not null, the corresponding descriptor is retrieved from the memory resident segment descriptor table, and another set of checks is applied. If these checks fail, an exception is raised and the segment register is not modified. If the descriptor checks pass, an access bit in the descriptor is set, the descriptor is written back into the descriptor table, and the descriptor is stored into the corresponding shadow registers. Then, when the segment register is specified in an address, the descriptor is available on-chip in special registers for efficient processing.

Referring to FIG. 2, a flowchart 200 is shown which illustrates a method for loading a segment register. Program flow begins at step 202. At step 204, a selector is read, either from memory, or from a general purpose register within a register file. The selector is placed within a temporary register, both for testing, and to prevent the destination segment register from being overwritten prior to complete validation of the new memory segment. The selector is tested to determine whether it is null.

One skilled in the art should appreciate that a null selector is a selector having a value of three or less, which is used to determine whether any subsequent memory reference uses the segment. A null selector is only valid for loading into the DS, ES, FS, and GS registers, but not SS or CS. If the selector is null, instruction flow proceeds to step 218.

At step 218, the processor determines whether the selector is being loaded into either the stack segment register (SS) or the code segment register (CS). If it is, the processor proceeds to block 220 and generates an exception.

If the null selector is to be loaded into one of the other segment registers, the processor, at block 222, invalidates the hidden descriptor in the descriptor register. Then any subsequent memory reference that uses the segment register will raise an exception. The processor then proceeds to block 214 and writes the selector into the segment register.

If at block 204 the processor determines, that the selector is not null, the processor proceeds to block 206. At block 206 the processor determines the address of the descriptor. This involves extracting the TI bit from the selector to determine which descriptor table applies, GDT or LDT, and utilizing the descriptor index to determine the location within the descriptor table of the desired descriptor. The processor then proceeds to block 208.

At block 208, the processor has calculated the address of the descriptor using the descriptor index in the selector, and the base address of the descriptor table, stored in either the GDTR or the LDTR. The processor then loads the descriptor into a temporary (invisible) memory space within the processor. The processor then proceeds to block 210.

At block 210, the processor checks the descriptor to determine whether it is valid. Descriptor load validity checking assures that the selected descriptor corresponds to a segment which may lawfully be accessed via the segment register type and is accessible from the current privilege level.

As was mentioned in the Background, the type of validity checks which are performed on a descriptor depend on whether the descriptor corresponds to code or data segments, or special system segments or gates. System segments or gates are used for managing tasks, exceptions and interrupts. And, in the case of gates, the descriptors hold pointers to procedure entry points rather than defining segments.

If the descriptor refers to a code or data segment, the descriptor can be found invalid for a number of reasons. First, a privilege level test is performed to ensure that the requesting program has sufficient privilege to access the desired segment. Second, a segment with execute/read access can be loaded into the DS, ES, FS, or GS registers, but not SS. Third, a type field within the descriptor is checked to ensure that it is appropriate for the designated segment register. For example, a load into the SS register requires that the segment be typed as a read/write segment. Loads into the CS register require that the segment be typed as execute or execute/read. Loads into the other segment registers only require that the segment be readable.

Failure of any of these tests will result in an immediate protection violation exception, illustrated by block 224. If the descriptor passes the checks, the processor proceeds to block 211.

At block 211, the processor performs a test on the descriptor to determine whether the access bit in the descriptor has been set. The processor performs a modify on the descriptor, to set the access bit==1, and writes the updated descriptor back into the descriptor table. The descriptor may then be tested by a later program to determine whether access to the memory segment has been attempted. Program flow then proceeds to block 212. Note: updating the Access bit in the middle of a descriptor load routine is very time consuming for the processor. An improved method for updating the Access bit during a descriptor load is described in co-pending U.S. patent application Ser. No. (Docket--IDT:1238) entitled "METHOD FOR IMPROVED UPDATING OF DESCRIPTOR ACCESS BIT", to Glenn Henry and Terry Parks.

At block 212, the processor stores the descriptor into the hidden descriptor register associated with the selector segment. The processor then proceeds to block 214.

By the time the processor reaches block 214, the descriptor has been determined, checked, and stored into the hidden register associated with the selector segment. The processor now stores the selector in the segment register. The segment selector/descriptor is now ready to be referenced by another instruction in a program. The process is complete as shown by block 216.

As mentioned above, the validity tests which are performed on a descriptor depend on the type of descriptor, whether code, data or system. Referring to FIG. 3, a diagram 300 is shown which illustrates descriptor formats for code, data, system and gate descriptors. The code and data descriptor formats are essentially the same, distinguished primarily by bit 11 of the upper word, which if set, indicates that the descriptor type is a form of execute. For a list of code and data descriptor types, please refer to FIG. 4.

The format for a system descriptor is similar to that of the code and data descriptors, except that bit 12 of the upper word is cleared to indicate that the descriptor is a system descriptor. In addition, the Type field (bits 8-11 of the upper word) are defined differently. For a list of system descriptor types, please refer to FIG. 5.

The format for a gate descriptor is very different from that of code and data descriptors. In x86 processors, there are four kinds of gate descriptors: Call gates; Trap gates; Interrupt gates; and Task gates. Task gates are used for task switching. Trap and Interrupt gates are used for exceptions and interrupts. And, Call gates are used to control transfers between different privilege levels. The selector and offset fields of a gate form a pointer to an entry point of a procedure. A call gate guarantees that all control transfers to other segments go to a valid entry point. Rather than the providing a selector and an offset as operands, the segment selector for a call gate points to a gate descriptor, and the offset is not used, because the offset is stored within bits 31:16 of the upper word of the gate descriptor.

The above discussion with reference to FIGS. 3-5 is intended to illustrate the differences between code/data descriptors, and system descriptors (including gates). One skilled in the art well appreciates that the differences in the descriptor types requires validity checking during a load that is particular to the type of descriptor which is being loaded.

Now referring to FIG. 6, a block diagram of a pipeline processor 600 is shown. The pipeline processor 600 contains six processing stages through which instructions pass. The stages include: 1) Fetch; 2) Translate/Decode; 3) Register access; 4) Address calculation; 5) Data access/store/computation; and 6) Write Back. One skilled in the art will appreciate that these stages are illustrative only, and may be combined or altered by a designer.

The processor 600 includes an instruction cache 602 for storing macro instructions for execution. The instruction cache 602 provides the macro instructions to an instruction buffer 604 which temporarily stores the instructions before they are decoded by a translator 606. The translator 606 decodes each macro instruction into a sequence of micro instructions by addressing a micro instruction sequence within a control ROM 608 pertaining to each macro instruction. The control ROM 608 provides the addressed micro instruction sequence to an instruction register 610 for execution by the processor 600. Shown within the control ROM 608 is a descriptor load sequence 609. The descriptor load sequence 609 is a micro instruction sequence which instructs the processor 600 to load a segment register with a selector/descriptor from memory.

The instruction register 610 also contains operand locations 612, 614 which are used to designate operands applicable to a particular macro instruction. Operands are retrieved from a register file 618 and provided to temporary registers 622, 624 for use in later stages in the pipeline. In addition, a segment register may be defined for a macro instruction by specifying the segment register within a location 616. By specifying a segment register within location 616, a descriptor corresponding to the specified segment register may be retrieved from the descriptor file, and placed in a temporary register 626 to be used as part of an address calculation in a later stage in the pipeline.

The contents of the temporary registers 622, 624 and 626 are provided to an address stage within the pipeline processor. The address stage includes an ALU circuit 628 which is used to add the base address (from the descriptor temporary register 626) to an offset defined by temporary registers 622, 624. The result from the ALU 628 is provided to a temporary register 630 which is used to access a memory location in a data stage of the pipeline processor 600. Operands from temporary registers 622, 624 may also be provided to temporary registers 632, 634 for use in later pipeline stages.

In the data stage, the address in temporary register 630 is used to access a memory location in a data cache 640, or if not present in the data cache 640, to access a memory location in a memory 642. The result from the data access may be stored in a result register 638. In the alternative, an ALU 636 may be used to calculate a result based on the contents of temporary registers 632, 634. The contents of the result register 638 are written to the memory 642, the register file 618, or the descriptor file 620 upon completion of an instruction.

When a macro instruction requests a segment register to be loaded, the macro instruction is provided to the translator 606 via the instruction buffer 604. The translator 606 decodes the macro instruction and addresses the descriptor load sequence 609 from the control ROM 608 to be provided to the instruction register 610 for execution. The instruction sequence flows down through the pipeline until it reaches the data stage. At this point, the address of the descriptor has been calculated, and is stored in the address buffer 630. This address is used to retrieve the desired descriptor from the memory 642. The descriptor is retrieved from the memory 642, and is placed within the result register 638. However, prior to writing the retrieved descriptor into the descriptor file 620, the descriptor must be validated.

Below the result register are shown two validation blocks for descriptors. A system descriptor check block 660, and a code/data descriptor check block 662 are coupled to the result register 638. Each block reads the contents of the result register 638, during a descriptor load operation, and performs a set a validation checks on the descriptor. If the descriptor passes the validation checks, the descriptor is written into the descriptor file 620. If the descriptor does not pass the validation checks, an exception is generated by either of the system descriptor check block 660 or the code/data descriptor check block 662.

Use of a system descriptor check block 660 and a code/data descriptor check block 662, to validate a descriptor, may adequately validate descriptors, but as explained above, requires costly additional circuitry for the processor 600, and may add significant delay in writing a code/data descriptor into the descriptor file 620.

Now referring to FIG. 7, a pipeline processor 700 is shown which is similar to that shown in FIG. 6. Like elements are indicated with like numbers, with the hundreds digit replaced by 7 instead of 6.

Missing from the pipeline processor 700 is a system descriptor check block 660. Rather, the processor 700 presumes that if a descriptor is being loaded, that the descriptor refers to a code or data segment. Therefore, only a code/data descriptor validation block 762 is provided, coupled to the result register 738.

In addition, rather than placing the code/data descriptor check block 762 between the result register 738, and the descriptor file 720, the result register 738 is coupled directly to the descriptor file 720. The code/data descriptor validation block 762 is also coupled to the result register 738. The validation block 762 performs code/data validation on the contents of the result register 738 in parallel with the write back cycle of the processor 700.

Since validation occurs in parallel with the descriptor load operation, a single micro instruction may be used to instruct the processor to load/validate/store a descriptor. In one embodiment, this instruction is identified as XLDESC 709. Although shown stored within the control ROM 708, one skilled in the art will appreciate that this instruction could also be provided directly by the translator 706.

If the descriptor in the result register 738, that is being provided to the descriptor file 720, is a valid code/data descriptor, then the validation block 762 provides a valid output signal, on line 766, to a write/enable input 767 on the descriptor file 720. This allows code/data descriptors to be validated "on the fly" during the write back stage of the processor 700.

If the descriptor being loaded is in fact a valid code/data descriptor, no additional processing time is required to validate the descriptor. Rather, the descriptor is moved immediately from the result register 738, to the descriptor file 720.

If the descriptor which is being loaded is an invalid code/data descriptor, or if the descriptor is a system descriptor, the code/data descriptor check block 762 generates an exception on error line 764. This causes the processor 700 to jump to an exception handler sequence 711 which is stored within the control ROM 708. In addition, an invalid signal on line 766 appears at the write/enable input 767 of the descriptor file 720, which prevents the descriptor in the result register 738 from being written into the descriptor file 720.

The exception handler sequence 711 reads the contents of the result register 738 and determines whether the retrieved descriptor is invalid, or whether the retrieved descriptor is actually a system descriptor. If the retrieved descriptor is a system descriptor, validation checks on the descriptor are performed in software, rather than in hardware, by the exception handler 711. If the descriptor is valid, the exception handler 711 causes the contents of the result register 738 to be stored in the descriptor file 720. If, on the other hand, the descriptor is either not a system descriptor, or is an invalid system descriptor, an exception 764 is indicated, and the descriptor is not written into the descriptor file 720.

To better illustrate the process for validating a descriptor, according to the present invention, attention is directed to FIG. 8. A flow chart 800 is provided which begins at block 802. Program flow proceeds to block 804.

At block 804, a selector is read to determine whether it is null. If the selector is null, flow proceeds to block 818. If the selector is not null, flow proceeds to block 806.

At block 818, it is determined whether the selector is to be stored in the CS or SS register. If so, then an exception is generated at block 820. If not, then the descriptor is marked as invalid, and the load is complete, at block 816.

At block 806, the address of the descriptor is determined. Flow then proceeds to block 808.

At block 808, the descriptor is loaded from memory. This step corresponds to the data stage within the processor 700. The descriptor is read from the memory 742 and placed into the result register 738. Flow proceeds to decision block 810.

At decision block 810, the descriptor is checked to determine whether it is valid. This corresponds to the write back stage in the processor 700. More specifically, the descriptor is provided to the code/data descriptor check block 762 for validation. If the descriptor is a valid code/data descriptor, flow proceeds to block 811 where the descriptor is stored in the descriptor file 720, and the selector is stored in the register file 718, at block 814. At this point, the descriptor load operation is complete.

If, at block 810, the descriptor is found invalid by the code/data descriptor check block 762, then an exception is generated, in block 824, shown by line 764, causing the processor 700 to branch to an exception handler. Flow proceeds to decision block 826.

At decision block 826, the exception handler checks the descriptor to determine whether the descriptor is a system descriptor. If not, then the exception is handled, at block 828.

If the descriptor is a system descriptor, flow proceeds to block 830. Block 830 executes a sequence of instructions which validates the system descriptor. If the system descriptor is valid, program flow proceeds to block 811 where the descriptor is stored into the descriptor file 720. If the system descriptor is found invalid, the exception is handled, at block 828.

Now referring to FIG. 9, a flow chart 900 is shown which illustrates steps 808, 810 and 811 of FIG. 8 in a slightly different fashion. Beginning at execution block 908, a descriptor is loaded from memory, and placed into the result register 738. At this point, the contents of the result register 738 are available as inputs to the descriptor file 720, and may be written into the descriptor file 720 during the write back stage of the XLDESC micro instruction.

Instruction flow therefore proceeds to block 911 where the descriptor is to be stored in the descriptor file 720. However, in parallel with the store operation, decision block 910 illustrates the operation of the code/data descriptor validation block 762. Validation block 762 operates within the time constraints of the write back stage of the processor 700. Therefore, the validation block 762 either enables the write of the descriptor to the descriptor file 720, or disables the write, and generates an exception. If an exception is generated, flow proceeds to block 924.

One skilled in the art will appreciate that the method for loading a descriptor, as illustrated by FIGS. 7-9, presumes that during a descriptor load operation, the descriptor which is being loaded refers to a code or data segment. In such instances, the code or data descriptor is validated by a hardware block 764, and if valid, is allowed to be written into the descriptor file 720. If the descriptor is invalid, then an exception is generated which determines whether the segment is actually invalid, or whether it refers to a system segment. If the descriptor refers to a system segment, then validation checks are performed in software, rather than requiring a dedicated system descriptor validation circuit. If the descriptor is a valid system descriptor, the descriptor is stored into the descriptor file.

By presuming that a descriptor load is going to load a code or data segment, validation circuitry can be made very fast, and can therefore validate and store a code or data descriptor in a descriptor file much faster than if system validation checks are also performed. In addition, hardware typically associated with validating system descriptors has been eliminated.

Furthermore, by removing hardware checks for system descriptors, and by using code/data validation logic in parallel with the write back stage of the processor, processing delays associated with validating code/data descriptors can be eliminated.

In the case where a system segment is being loaded, the code/data validation checks indicate that the descriptor is invalid, which causes an exception. The exception handler then determines that the descriptor is in fact a system descriptor, and performs the validation checks in software.

Thus, if the majority of segment loads refer to code or data segments (which is the case in most operating environments), significant processing time is saved by not performing system descriptor validation checks during a descriptor load. And, by validating the descriptor "on the fly", no processing delays are required in between the load and store operations. This allows the descriptor to be stored, and subsequently used by a program much faster than if system validation checks are performed, or if code/data validation is performed serially, rather than in parallel. In the rarer case where a descriptor load operation refers to a system segment, the validation of the system descriptor is performed in software.

Although the present invention and its objects, features, and advantages have been described in detail, other embodiments are within the mind of the inventors. For example, it is anticipated that a test could be performed by the code/data validation block to determine whether the descriptor is a system descriptor, during the code/data validation checks. If the test indicates that the descriptor is a system descriptor, a signal could be generated to the processor which indicates that system descriptor validation checks need to be performed. The signal could be used to branch to an exception routine, or could simply set a bit within the processor which caused a system descriptor validation sequence to be provided by a control ROM.

In fact, a check to determine whether a descriptor is a code/data descriptor, or a system descriptor, may be accomplished by a separate hardware circuit coupled to the result register, which generates an exception, or otherwise notifies the processor that the descriptor being loaded refers to a system segment. Fast validation checking of code/data segments is a key feature of the present invention, while validation of system segments may be performed via software in an exception handler, software within a control ROM, or some other software/hardware arrangement.

Furthermore, an embodiment described above used a valid/invalid signal from the code/data validation block as a write/enable input to the descriptor file. It should be appreciated that the write/enable signal may in fact be coupled to the general register file, and not directly to the descriptor file. Furthermore, intermediate logic may be used between the validation block and the register file which controls whether the contents of the result register are to be written into the register file. The embodiment described with reference to FIG. 7 is intended to particularly illustrate that validation of the descriptor is performed in parallel with the writing of the descriptor into the register file. Utilization of the valid signal as a write enable is merely one method of accomplishing this objective.

Those skilled in the art should appreciate that they can readily use the disclosed conception and specific embodiments as a basis for designing or modifying other structures for carrying out the same purposes of the present invention without departing from the spirit and scope of the invention as defined by the appended claims.