Patent Application
20060168485
The present disclosure is generally related to computer processors and, more particularly, is related to an improved system and method for updating an instruction fault status register in a computer processor.
Processors (e.g., microprocessors) running code are well known and used in a wide variety of products and applications, from desktop computers to portable electronic devices, such as cellular phones and PDAs (personal digital assistants).
There are many architectures used to process instructions in a processor. Each architecture handles problems or faults introduced in the code it is running in different ways. An important feature of each of the architectures is how the problem, or fault, is reported and handled. The terms “fault” and “abort” are used interchangeably in this disclosure.
In a non-limiting example, in a three stage pipeline architecture, as in many processor architectures, when a code instruction is fetched, if a fault is detected, a Fault Status Register (FSR) will be updated with information indicating the type of fault that has been detected. However, the processor does not immediately take any action with respects to the associated instruction while it is in the fetch stage. Instead, the instruction moves to the next stage, the decode stage, and then on to the next subsequent stage, the execute stage. It is not until the execute stage that the fault is actually acknowledged by the processor and the processor vectors to an abort handler to handle the fault. In this particular implementation, it will take at least three clock cycles before the fault is acknowledged. As a result, prior to the instruction and its fault being executed and acknowledged, two more instructions may be fetched by the fetch stage of the processor.
This can be better understood by examining fault handling in a pipeline architecture in more detail. A first instruction is fetched and a fault is detected. The cause of the fault is recorded in the instruction FSR. When the first instruction moves to the decode stage of the processor's pipeline, a second instruction is fetched and a fault may also be detected in association with this second instruction fetch. If this occurs then the cause of the second instruction's fault will be recorded in the FSR, overwriting the fault status information associated with the first instruction. Aborts can occur sequentially; but usually they are for the same reason. In these instances, successive faults are not problematic. Subsequently, the first instruction will move to the execute stage, the second instruction will move to the decode stage and a third instruction will be fetched. When the first instruction is executed in the execute stage, the abort will be recognized and cause the processor to vector to its abort handler. Once in the abort handler the processor will read its instruction FSR to determine the cause of the fault associated with the first instruction; the fault cause will determine what actions the processor will take to resolve the associated problem. Thus it is important that the cause of the associated fault is correct, otherwise the processor may not take the proper corrective actions.
In some instances, however, there are problems when waiting until the execute stage to handle aborts. For example, if two instructions are fetched, the first may abort for reason A, and the second may abort for a different reason B. When the first instruction moves to the decode stage, the second instruction is fetched and updates the instruction FSR with the reason for its abort, reason B. Then when the first instruction moves to the execute stage, it will cause the processor to vector to the abort handler, which may read the instruction FSR and the wrong abort reason (reason B instead of reason A) will be read from the FSR.
Since the abort reason in the FSR cannot be relied upon, a more complicated abort handler routine is necessary to determine the cause of the fault. This makes supporting more sophisticated memory management operating systems more complicated and reduces their performance. A memory management operating system uses the concept of virtual memory in its operation. A virtual memory implementation is used in situations where a user has a small amount of physical memory, but the user wants to force the software code to run as if there is more memory. This virtual memory is achieved through the operating system (OS). When the software tries to access memory that is not really there, the virtual memory, a fault will be detected and the process interrupted by subsequently vectoring to the abort handler as described previously. In the abort handler, the OS may manipulate the memory by transferring information between a hard drive, for example, and the physical memory available. The code is then restarted at the point that it was interrupted. The memory location that the code is addressing now appears to be present.
For example, a first Linux operating system (a master OS) may be running the PC that is in control of the hardware and that keeps track of the actual configuration of the hardware. But a user can boot a second version of Linux within that master Linux operating system such that it thinks it controls all the hardware when it really does not. The master Linux operating system is controlling it. Then a user can, in parallel, boot Windows XP. A user can also boot Windows 98. So under the first Linux operating system, there may be three other operating systems that each operate as if it is in complete control of the display, the hard disk drive, etc. But, in reality, each has no control at all. The master OS asserts control for them. Although there may be a performance penalty, this implementation allows a user who runs most applications in Linux, because it is more expedient or because most of the applications the user wants to run are only available on Linux, to bring Windows up under a Linux master OS to run some application that is only available in Windows. It also allows a user to bring up multiple versions of Linux when, even though the user may not need each version all the time, one version has advantages over another.
An operating system must know which instruction was interrupted and why it was interrupted. In prior art systems, this information may not be accessible. In this regard, prior art systems determine and set a reason for a fault at the fetch stage. If faults are encountered in successive instructions, then the value stored in the fault status register is no longer reliable when the first faulted instruction reaches the executed stage. That is, if another abort has occurred for a different reason, during the progression from the fetch stage to the execute stage, the operating system may not be able to determine the cause of the abort from the FSR and will have to determine the cause of the fault by manually reading the associated memory management page tables. This manual reading of the associated memory management tables adds complexity to the OS and consumes more processor time. As a result, what is desired is an implementation whereby the OS may always rely on the validity of the information it reads from the FSR, which in turn will reduce the complexity of the OS needed and improve processor performance.
Embodiments of the present disclosure provide improved systems and methods for updating an instruction fault status register so that accurate fault information is provided to an execute unit, even if multiple, successive faults are encountered.
Briefly described, in architecture, one embodiment of the system, among others, can be implemented as follows. A system for updating an instruction fault status register with a fetching stage; a decoding stage communicatively coupled to the fetching stage; an executing stage communicatively coupled to the decoding stage; a Memory Management Unit or Protection Unit (MMU/PU) for determining a fault in an instruction, the MMU/PU communicatively coupled to the fetching stage; fault communication logic communicatively coupled to the MMU/PU; and an instruction fault status register communicatively coupled to the fault communication logic.
One embodiment of such a method, among others, can be broadly summarized by the following steps: fetching an instruction; determining if the instruction is faulty;
decoding the instruction; and executing the instruction, wherein, if the instruction is faulty an indication that the instruction is faulty and the reason it is faulty is passed with the instruction to the decoded and execute stages.
Other systems, methods, features, and advantages of the present disclosure will be or become apparent to one with skill in the art upon examination of the following drawings and detailed description. It is intended that all such additional systems, methods, features, and advantages be included within this description, be within the scope of the present disclosure, and be protected by the accompanying claims.
Many aspects of the disclosure can be better understood with reference to the following drawings. The components in the drawings are not necessarily to scale, emphasis instead being placed upon clearly illustrating the principles of the present disclosure. Moreover, in the drawings, like reference numerals designate corresponding parts throughout the several views.
Disclosed herein are systems and methods for updating a fault status register in a pipelined processor. To facilitate description of the inventive systems, an example system that can be used to implement the systems and methods for updating a fault status register is discussed with reference to the figures. Although this system is described in detail, it will be appreciated that this system is provided for purposes of illustration only and modifications are feasible without departing from the inventive concept.
Referring now and in more detail to the drawings in which like numerals indicate corresponding parts through the several views, this disclosure describes a system for updating a fault status. It describes how the system is configured and how it operates.
As shown in the block diagram of
At a very high level, the fetch/execute portion of a processor includes fetch logic 100 for fetching an encoded instruction and decoder logic 102 for decoding the instruction. As mentioned above, the decoder 102 operates to decode an encoded instruction into a plurality of signal lines, which are used to control and carry out the execution of the encoded instruction. In this regard, the outputs from the decoder 102 are signal lines that are used as inputs and/or control signals for other circuit components within an execution unit (not shown) of the processor, and the execution unit carries out the functional operations specified by the encoded instructions. This basic operation is well known, and need not be described further herein.
In the exemplary embodiment illustrated in
As provided above, the fault status register, FSR, provides an indicator of the type of abort or fault that has occurred in an instruction. The term “abort” and “fault” are used interchangeably in this disclosure. Based on the information concerning the abort in the FSR, a correcting action can be performed.
There are several reasons that an abort can occur. Non-limiting examples include table aborts in memory and external aborts through hardware. There can be MMU first page aborts, and second page aborts among others. An abort may occur because the application is trying to access a memory address that is not valid. There may be an external bus abort. There may be an abort because parity does not match.
There may also be an abort because the system is a virtual memory system and the memory image being accessed is not mapped in memory, but it may exist. It may presently be on the hard disk drive.
In the prior art, as provided in
To solve this problem, in
In
Referring to the example as shown in
So, the instruction is not passed through the pipeline alone. The decode stage actually passes much more. An exemplary embodiment passes the bits corresponding to the reason for the abort along with the instruction and loads them in the instruction FSR 314 when the abort is acknowledged at the execute stage 304. When the abort handler is called, it is passed the abort reason for the instruction currently in the execute stage. In this exemplary embodiment, since the abort reason is passed along with the instruction, the abort handler may rely on the validity of the abort reason recorded in the instruction FSR 314. As a result the abort handler may be simplified, allowing it to be performed more efficiently.
Another alternative embodiment of fault communication logic 301 is provided in
An alternative embodiment combines the FIFO 307 and instruction FSR 314. The FSR 314 is an actual FIFO in this example. Whenever a fault occurs, the MMU/PU 312 loads the fault information into the FSR/FIFO 314/307. When the instruction reaches the execute stage 304, the fault information is retrieved from the FSR/FIFO 314/307. Since the fault information is loaded into the FIFO stack, any previous fault is not overwritten and the abort handler processes the appropriate fault information.
Having described certain features and architectural implementations of certain embodiments of the present invention, reference is now made to
It should be emphasized that the above-described embodiments of the present disclosure, particularly, any “preferred” embodiments, are merely possible examples of implementations, merely set forth for a clear understanding of the principles of the disclosure. Many variations and modifications may be made to the above-described embodiment(s) of the disclosure without departing substantially from the spirit and principles of the disclosure. All such modifications and variations are intended to be included herein within the scope of this disclosure and the present disclosure and protected by the following claims.
