Architecture for Programmers Volume II - Introduction to the MIPS 32 Architecture | CS 1541, Papers of Computer Science

Download Architecture for Programmers Volume II - Introduction to the MIPS 32 Architecture | CS 1541 and more Papers Computer Science in PDF only on Docsity! Document Number: MD00090 Revision 2.00 June 9, 2003 MIPS Technologies, Inc. 1225 Charleston Road Mountain View, CA 94043-1353 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. MIPS32™ Architecture For Programmers Volume III: The MIPS32™ Privileged Resource Architecture Copyright © 2001-2003 MIPS Technologies, Inc. All rights reserved. Unpublished rights (if any) are reserved under the Copyright Laws of the United States of America. If this document is provided in source format (i.e., in a modifiable form such as in FrameMaker or Microsoft Word format), then its use and distribution is subject to a written agreement with MIPS Technologies, Inc. ("MIPS Technologies"). UNDER NO CIRCUMSTANCES MAY A DOCUMENT PROVIDED IN SOURCE FORMAT BE DISTRIBUTED TO A THIRD PARTY WITHOUT THE EXPRESS WRITTEN CONSENT OF MIPS TECHNOLOGIES. This document contains information that is proprietary to MIPS Technologies. Any copying, reproducing, modifying, or use of this information (in whole or in part) which is not expressly permitted in writing by MIPS Technologies or a contractually-authorized third party is strictly prohibited. At a minimum, this information is protected under unfair competition and copyright laws. Violations thereof may result in criminal penalties and fines. MIPS Technologies or any contractually-authorized third party reserves the right to change the information contained in this document to improve function, design or otherwise. MIPS Technologies does not assume any liability arising out of the application or use of this information, or of any error of omission in such information. Any warranties, whether express, statutory, implied or otherwise, including but not limited to the implied warranties of merchantability or fitness for a particular purpose, are excluded. Any license under patent rights or any other intellectual property rights owned by MIPS Technologies or third parties shall be conveyed by MIPS Technologies or any contractually-authorized third party in a separate license agreement between the parties. The information contained in this document shall not be exported or transferred for the purpose of reexporting in violation of any U.S. or non-U.S. regulation, treaty, Executive Order, law, statute, amendment or supplement thereto. The information contained in this document constitutes one or more of the following: commercial computer software, commercial computer software documentation or other commercial items. If the user of this information, or any related documentation of any kind, including related technical data or manuals, is an agency, department, or other entity of the United States government (“Government”), the use, duplication, reproduction, release, modification, disclosure, or transfer of this information, or any related documentation of any kind, is restricted in accordance with Federal Acquisition Regulation 12.212 for civilian agencies and Defense Federal Acquisition Regulation Supplement 227.7202 for military agencies. The use of this information by the Government is further restricted in accordance with the terms of the license agreement(s) and/or applicable contract terms and conditions covering this information from MIPS Technologies or any contractually-authorized third party. MIPS®, R3000®, R4000®, R5000® and R10000® are among the registered trademarks of MIPS Technologies, Inc. in the United States and certain other countries, and MIPS16™, MIPS16e™, MIPS32™, MIPS64™, MIPS-3D™, MIPS-based™, MIPS I™, MIPS II™, MIPS III™, MIPS IV™, MIPS V™, MDMX™, MIPSsim™, MIPSsimCA™, MIPSsimIA™, QuickMIPS™, SmartMIPS™, MIPS Technologies logo, 4K™, 4Kc™, 4Km™, 4Kp™, 4KE™, 4KEc™, 4KEm™, 4KEp™, 4KS™, 4KSc™, M4K™, 5K™, 5Kc™, 5Kf™, 20K™, 20Kc™, 25Kf™, R4300™, ASMACRO™, ATLAS™, BusBridge™, CoreFPGA™, CoreLV™, EC™, JALGO™, MALTA™, MGB™, PDtrace™, SEAD™, SEAD-2™, SOC-it™, The Pipeline™, and YAMON™ are among the trademarks of MIPS Technologies, Inc. All other trademarks referred to herein are the property of their respective owners. Template: B1.06, Build with Conditional Tags: 2B ARCH MIPS32 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.22 Exception Program Counter (CP0 Register 14, Select 0) .......................................................................................... 91 8.22.1 Special Handling of the EPC Register in Processors That Implement the MIPS16e ASE.............................. 91 8.23 Processor Identification (CP0 Register 15, Select 0) ................................................................................................. 92 8.24 EBase Register (CP0 Register 15, Select 1) .............................................................................................................. 93 8.25 Configuration Register (CP0 Register 16, Select 0) .................................................................................................. 95 8.26 Configuration Register 1 (CP0 Register 16, Select 1) ............................................................................................... 97 8.27 Configuration Register 2 (CP0 Register 16, Select 2) ............................................................................................. 101 8.28 Configuration Register 3 (CP0 Register 16, Select 3) ............................................................................................. 104 8.29 Reserved for Implementations (CP0 Register 16, Selects 6 and 7) ......................................................................... 106 8.30 Load Linked Address (CP0 Register 17, Select 0) .................................................................................................. 107 8.31 WatchLo Register (CP0 Register 18)....................................................................................................................... 108 8.32 WatchHi Register (CP0 Register 19) ....................................................................................................................... 110 8.33 Reserved for Implementations (CP0 Register 22, all Select values) ....................................................................... 112 8.34 Debug Register (CP0 Register 23)........................................................................................................................... 113 8.35 DEPC Register (CP0 Register 24) ........................................................................................................................... 114 8.35.1 Special Handling of the DEPC Register in Processors That Implement the MIPS16e ASE......................... 114 8.36 Performance Counter Register (CP0 Register 25) ................................................................................................... 115 8.37 ErrCtl Register (CP0 Register 26, Select 0)............................................................................................................. 118 8.38 CacheErr Register (CP0 Register 27, Select 0)........................................................................................................ 119 8.39 TagLo Register (CP0 Register 28, Select 0, 2) ........................................................................................................ 120 8.40 DataLo Register (CP0 Register 28, Select 1, 3)....................................................................................................... 121 8.41 TagHi Register (CP0 Register 29, Select 0, 2) ........................................................................................................ 122 8.42 DataHi Register (CP0 Register 29, Select 1, 3) ....................................................................................................... 123 8.43 ErrorEPC (CP0 Register 30, Select 0) ..................................................................................................................... 124 8.43.1 Special Handling of the ErrorEPC Register in Processors That Implement the MIPS16e ASE ................... 124 8.44 DESAVE Register (CP0 Register 31)...................................................................................................................... 125 Appendix A Alternative MMU Organizations........................................................................................................................ 127 A.1 Fixed Mapping MMU ............................................................................................................................................... 127 A.1.1 Fixed Address Translation .............................................................................................................................. 127 A.1.2 Cacheability Attributes ................................................................................................................................... 130 A.1.3 Changes to the CP0 Register Interface ........................................................................................................... 131 A.2 Block Address Translation ........................................................................................................................................ 131 A.2.1 BAT Organization........................................................................................................................................... 131 A.2.2 Address Translation ........................................................................................................................................ 132 A.2.3 Changes to the CP0 Register Interface .......................................................................................................... 133 Appendix B Revision History ................................................................................................................................................. 135MIPS32™ Architecture For Programmers Volume III, Revision 2.00 iii Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. iv MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. List of Figures Figure 4-1: Virtual Address Space ............................................................................................................................................. 12 Figure 4-2: References as a Function of Operating Mode ......................................................................................................... 14 Figure 4-3: Contents of a TLB Entry ......................................................................................................................................... 17 Figure 5-1: Interrupt Generation for Vectored Interrupt Mode.................................................................................................. 28 Figure 5-2: Interrupt Generation for External Interrupt Controller Interrupt Mode .................................................................. 30 Figure 8-1: Index Register Format ............................................................................................................................................. 57 Figure 8-2: Random Register Format......................................................................................................................................... 58 Figure 8-3: EntryLo0, EntryLo1 Register Format in Release 1 of the Architecture.................................................................. 59 Figure 8-4: EntryLo0, EntryLo1 Register Format in Release 2 of the Architecture.................................................................. 60 Figure 8-5: Context Register Format ......................................................................................................................................... 63 Figure 8-6: PageMask Register Format ..................................................................................................................................... 64 Figure 8-7: PageGrain Register Format ..................................................................................................................................... 66 Figure 8-8: Wired And Random Entries In The TLB ................................................................................................................ 68 Figure 8-9: Wired Register Format ............................................................................................................................................ 68 Figure 8-10: HWREna Register Format..................................................................................................................................... 69 Figure 8-11: BadVAddr Register Format................................................................................................................................... 70 Figure 8-12: Count Register Format .......................................................................................................................................... 71 Figure 8-13: EntryHi Register Format ....................................................................................................................................... 72 Figure 8-14: Compare Register Format ..................................................................................................................................... 74 Figure 8-15: Status Register Format .......................................................................................................................................... 75 Figure 8-16: IntCtl Register Format........................................................................................................................................... 82 Figure 8-17: SRSCtl Register Format ........................................................................................................................................ 84 Figure 8-18: SRSMap Register Format...................................................................................................................................... 86 Figure 8-19: Cause Register Format .......................................................................................................................................... 87 Figure 8-20: EPC Register Format............................................................................................................................................. 91 Figure 8-21: PRId Register Format ............................................................................................................................................ 92 Figure 8-22: EBase Register Format .......................................................................................................................................... 93 Figure 8-23: Config Register Format ......................................................................................................................................... 95 Figure 8-24: Config1 Register Format ....................................................................................................................................... 97 Figure 8-25: Config2 Register Format ..................................................................................................................................... 101 Figure 8-26: Config3 Register Format ..................................................................................................................................... 104 Figure 8-27: LLAddr Register Format ..................................................................................................................................... 107 Figure 8-28: WatchLo Register Format ................................................................................................................................... 108 Figure 8-29: WatchHi Register Format.................................................................................................................................... 110 Figure 8-30: Performance Counter Control Register Format................................................................................................... 115 Figure 8-31: Performance Counter Counter Register Format .................................................................................................. 117 Figure 8-32: ErrorEPC Register Format .................................................................................................................................. 124 Figure 8-33: Memory Mapping when ERL = 0 ....................................................................................................................... 129 Figure 8-34: Memory Mapping when ERL = 1 ....................................................................................................................... 130 Figure 8-35: Config Register Additions................................................................................................................................... 131 Figure 8-36: Contents of a BAT Entry..................................................................................................................................... 132 List of Tables Table 1-1: Symbols Used in Instruction Operation Statements .................................................................................................. 2 Table 4-1: Virtual Memory Address Spaces ............................................................................................................................. 13 Table 4-2: Address Space Access as a Function of Operating Mode ....................................................................................... 15 Table 4-3: Address Translation and Cache Coherency Attributes for the kseg0 and kseg1 Segments .................................... 16 Table 4-4: Physical Address Generation................................................................................................................................... 22 Table 5-1: Interrupt Modes ....................................................................................................................................................... 24 Table 5-2: Request for Interrupt Service in Interrupt Compatibility Mode .............................................................................. 25 Table 5-3: Relative Interrupt Priority for Vectored Interrupt Mode ......................................................................................... 27 Table 5-4: Exception Vector Offsets for Vectored Interrupts................................................................................................... 32 Table 5-5: Exception Vector Base Addresses ........................................................................................................................... 33 Table 5-6: Exception Vector Offsets......................................................................................................................................... 33 Table 5-7: Exception Vectors.................................................................................................................................................... 34 Table 5-8: Value Stored in EPC, ErrorEPC, or DEPC on an Exception................................................................................... 35 Table 6-1: Instructions Supporting Shadow Sets ...................................................................................................................... 48 Table 7-1: Execution Hazards ................................................................................................................................................... 49 Table 7-2: Instruction Hazards .................................................................................................................................................. 50 Table 7-3: Hazard Clearing Instructions ................................................................................................................................... 51 Table 8-1: Coprocessor 0 Registers in Numerical Order .......................................................................................................... 53 Table 8-2: Read/Write Bit Field Notation................................................................................................................................. 56 Table 8-3: Index Register Field Descriptions ........................................................................................................................... 57 Table 8-4: Random Register Field Descriptions ....................................................................................................................... 58 Table 8-5: EntryLo0, EntryLo1 Register Field Descriptions in Release 1 of the Architecture ............................................... 59 Table 8-6: EntryLo0, EntryLo1 Register Field Descriptions in Release 2 of the Architecture ............................................... 60 Table 8-7: EntryLo Field Widths as a Function of PABITS...................................................................................................... 61 Table 8-8: Cache Coherency Attributes .................................................................................................................................... 61 Table 8-9: Context Register Field Descriptions ........................................................................................................................ 63 Table 8-10: PageMask Register Field Descriptions .................................................................................................................. 64 Table 8-11: Values for the Mask and MaskX1 Fields of the PageMask Register..................................................................... 64 Table 8-12: PageGrain Register Field Descriptions.................................................................................................................. 66 Table 8-13: Wired Register Field Descriptions......................................................................................................................... 68 Table 8-14: HWREna Register Field Descriptions ................................................................................................................... 69 Table 8-15: BadVAddr Register Field Descriptions ................................................................................................................. 70 Table 8-16: Count Register Field Descriptions......................................................................................................................... 71 Table 8-17: EntryHi Register Field Descriptions...................................................................................................................... 72 Table 8-18: Compare Register Field Descriptions .................................................................................................................... 74 Table 8-19: Status Register Field Descriptions......................................................................................................................... 75 Table 8-20: IntCtl Register Field Descriptions ......................................................................................................................... 82 Table 8-21: SRSCtl Register Field Descriptions....................................................................................................................... 84 Table 8-22: Sources for new SRSCtlCSS on an Exception or Interrupt .................................................................................... 85 Table 8-23: SRSMap Register Field Descriptions .................................................................................................................... 86 Table 8-24: Cause Register Field Descriptions......................................................................................................................... 87 Table 8-25: Cause Register ExcCode Field .............................................................................................................................. 90 Table 8-26: EPC Register Field Descriptions ........................................................................................................................... 91 Table 8-27: PRId Register Field Descriptions .......................................................................................................................... 92 Table 8-28: EBase Register Field Descriptions ........................................................................................................................ 93 Table 8-29: Conditions Under Which EBase15..12 Must Be Zero........................................................................................... 94 Table 8-30: Config Register Field Descriptions ....................................................................................................................... 95 Table 8-31: Config1 Register Field Descriptions ..................................................................................................................... 97 Table 8-32: Config2 Register Field Descriptions ................................................................................................................... 101 Table 8-33: Config3 Register Field Descriptions ................................................................................................................... 104MIPS32™ Architecture For Programmers Volume III, Revision 2.00 v Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 1 About This Book1.2 UNPREDICTABLE and UNDEFINED The terms UNPREDICTABLE and UNDEFINED are used throughout this book to describe the behavior of the processor in certain cases. UNDEFINED behavior or operations can occur only as the result of executing instructions in a privileged mode (i.e., in Kernel Mode or Debug Mode, or with the CP0 usable bit set in the Status register). Unprivileged software can never cause UNDEFINED behavior or operations. Conversely, both privileged and unprivileged software can cause UNPREDICTABLE results or operations. 1.2.1 UNPREDICTABLE UNPREDICTABLE results may vary from processor implementation to implementation, instruction to instruction, or as a function of time on the same implementation or instruction. Software can never depend on results that are UNPREDICTABLE. UNPREDICTABLE operations may cause a result to be generated or not. If a result is generated, it is UNPREDICTABLE. UNPREDICTABLE operations may cause arbitrary exceptions. UNPREDICTABLE results or operations have several implementation restrictions: • Implementations of operations generating UNPREDICTABLE results must not depend on any data source (memory or internal state) which is inaccessible in the current processor mode • UNPREDICTABLE operations must not read, write, or modify the contents of memory or internal state which is inaccessible in the current processor mode. For example, UNPREDICTABLE operations executed in user mode must not access memory or internal state that is only accessible in Kernel Mode or Debug Mode or in another process • UNPREDICTABLE operations must not halt or hang the processor 1.2.2 UNDEFINED UNDEFINED operations or behavior may vary from processor implementation to implementation, instruction to instruction, or as a function of time on the same implementation or instruction. UNDEFINED operations or behavior may vary from nothing to creating an environment in which execution can no longer continue. UNDEFINED operations or behavior may cause data loss. UNDEFINED operations or behavior has one implementation restriction: • UNDEFINED operations or behavior must not cause the processor to hang (that is, enter a state from which there is no exit other than powering down the processor). The assertion of any of the reset signals must restore the processor to an operational state 1.3 Special Symbols in Pseudocode Notation In this book, algorithmic descriptions of an operation are described as pseudocode in a high-level language notation resembling Pascal. Special symbols used in the pseudocode notation are listed in Table 1-1. Table 1-1 Symbols Used in Instruction Operation Statements Symbol Meaning ← Assignment =, ≠ Tests for equality and inequality || Bit string concatenation xy A y-bit string formed by y copies of the single-bit value x2 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 1.3 Special Symbols in Pseudocode Notationb#n A constant value n in base b. For instance 10#100 represents the decimal value 100, 2#100 represents the binary value 100 (decimal 4), and 16#100 represents the hexadecimal value 100 (decimal 256). If the "b#" prefix is omitted, the default base is 10. xy..z Selection of bits y through z of bit string x. Little-endian bit notation (rightmost bit is 0) is used. If y is less than z, this expression is an empty (zero length) bit string. +, − 2’s complement or floating point arithmetic: addition, subtraction ∗, × 2’s complement or floating point multiplication (both used for either) div 2’s complement integer division mod 2’s complement modulo / Floating point division < 2’s complement less-than comparison > 2’s complement greater-than comparison ≤ 2’s complement less-than or equal comparison ≥ 2’s complement greater-than or equal comparison nor Bitwise logical NOR xor Bitwise logical XOR and Bitwise logical AND or Bitwise logical OR GPRLEN The length in bits (32 or 64) of the CPU general-purpose registers GPR[x] CPU general-purpose register x. The content of GPR[0] is always zero. SGPR[s,x] In Release 2 of the Architecture, multiple copies of the CPU general-purpose registers may be implemented.SGPR[s,x] refers to GPR set s, register x. GPR[x] is a short-hand notation for SGPR[ SRSCtlCSS, x]. FPR[x] Floating Point operand register x FCC[CC] Floating Point condition code CC. FCC[0] has the same value as COC[1]. FPR[x] Floating Point (Coprocessor unit 1), general register x CPR[z,x,s] Coprocessor unit z, general register x, select s CP2CPR[x] Coprocessor unit 2, general register x CCR[z,x] Coprocessor unit z, control register x CP2CCR[x] Coprocessor unit 2, control register x COC[z] Coprocessor unit z condition signal Xlat[x] Translation of the MIPS16e GPR number x into the corresponding 32-bit GPR number BigEndianMem Endian mode as configured at chip reset (0 →Little-Endian, 1 → Big-Endian). Specifies the endianness of the memory interface (see LoadMemory and StoreMemory pseudocode function descriptions), and the endianness of Kernel and Supervisor mode execution. BigEndianCPU The endianness for load and store instructions (0 → Little-Endian, 1 → Big-Endian). In User mode, this endianness may be switched by setting the RE bit in the Status register. Thus, BigEndianCPU may be computed as (BigEndianMem XOR ReverseEndian). Table 1-1 Symbols Used in Instruction Operation Statements Symbol MeaningMIPS32™ Architecture For Programmers Volume III, Revision 2.00 3 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 1 About This Book1.4 For More Information Various MIPS RISC processor manuals and additional information about MIPS products can be found at the MIPS URL: http://www.mips.com ReverseEndian Signal to reverse the endianness of load and store instructions. This feature is available in User mode only, and is implemented by setting the RE bit of the Status register. Thus, ReverseEndian may be computed as (SRRE and User mode). LLbit Bit of virtual state used to specify operation for instructions that provide atomic read-modify-write. LLbit is set when a linked load occurs; it is tested and cleared by the conditional store. It is cleared, during other CPU operation, when a store to the location would no longer be atomic. In particular, it is cleared by exception return instructions. I:, I+n:, I-n: This occurs as a prefix to Operation description lines and functions as a label. It indicates the instruction time during which the pseudocode appears to “execute.” Unless otherwise indicated, all effects of the current instruction appear to occur during the instruction time of the current instruction. No label is equivalent to a time label of I. Sometimes effects of an instruction appear to occur either earlier or later — that is, during the instruction time of another instruction. When this happens, the instruction operation is written in sections labeled with the instruction time, relative to the current instruction I, in which the effect of that pseudocode appears to occur. For example, an instruction may have a result that is not available until after the next instruction. Such an instruction has the portion of the instruction operation description that writes the result register in a section labeled I+1. The effect of pseudocode statements for the current instruction labelled I+1 appears to occur “at the same time” as the effect of pseudocode statements labeled I for the following instruction. Within one pseudocode sequence, the effects of the statements take place in order. However, between sequences of statements for different instructions that occur “at the same time,” there is no defined order. Programs must not depend on a particular order of evaluation between such sections. PC The Program Counter value. During the instruction time of an instruction, this is the address of the instruction word. The address of the instruction that occurs during the next instruction time is determined by assigning a value to PC during an instruction time. If no value is assigned to PC during an instruction time by any pseudocode statement, it is automatically incremented by either 2 (in the case of a 16-bit MIPS16e instruction) or 4 before the next instruction time. A taken branch assigns the target address to the PC during the instruction time of the instruction in the branch delay slot. PABITS The number of physical address bits implemented is represented by the symbol PABITS. As such, if 36 physicaladdress bits were implemented, the size of the physical address space would be 2PABITS = 236 bytes. FP32RegistersMode Indicates whether the FPU has 32-bit or 64-bit floating point registers (FPRs). In MIPS32, the FPU has 32 32-bit FPRs in which 64-bit data types are stored in even-odd pairs of FPRs. In MIPS64, the FPU has 32 64-bit FPRs in which 64-bit data types are stored in any FPR. In MIPS32 implementations, FP32RegistersMode is always a 0. MIPS64 implementations have a compatibility mode in which the processor references the FPRs as if it were a MIPS32 implementation. In such a case FP32RegisterMode is computed from the FR bit in the Status register. If this bit is a 0, the processor operates as if it had 32 32-bit FPRs. If this bit is a 1, the processor operates with 32 64-bit FPRs. The value of FP32RegistersMode is computed from the FR bit in the Status register. InstructionInBranchD elaySlot Indicates whether the instruction at the Program Counter address was executed in the delay slot of a branch or jump. This condition reflects the dynamic state of the instruction, not the static state. That is, the value is false if a branch or jump occurs to an instruction whose PC immediately follows a branch or jump, but which is not executed in the delay slot of a branch or jump. SignalException(exce ption, argument) Causes an exception to be signaled, using the exception parameter as the type of exception and the argument parameter as an exception-specific argument). Control does not return from this pseudocode function - the exception is signaled at the point of the call. Table 1-1 Symbols Used in Instruction Operation Statements Symbol Meaning4 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 2 The MIPS32 Privileged Resource Architecture 2.1 Introduction The MIPS32 Privileged Resource Architecture (PRA) is a set of environments and capabilities on which the Instruction Set Architecture operates. The effects of some components of the PRA are user-visible, for instance, the virtual memory layout. Many other components are visible only to the operating system kernel and to systems programmers. The PRA provides the mechanisms necessary to manage the resources of the CPU: virtual memory, caches, exceptions and user contexts. This chapter describes these mechanisms. 2.2 The MIPS Coprocessor Model The MIPS ISA provides for up to 4 coprocessors. A coprocessor extends the functionality of the MIPS ISA, while sharing the instruction fetch and execution control logic of the CPU. Some coprocessors, such as the system coprocessor and the floating point unit are standard parts of the ISA, and are specified as such in the architecture documents. Coprocessors are generally optional, with one exception: CP0, the system coprocessor, is required. CP0 is the ISA interface to the Privileged Resource Architecture and provides full control of the processor state and modes. 2.2.1 CP0 - The System Coprocessor CP0 provides an abstraction of the functions necessary to support an operating system: exception handling, memory management, scheduling, and control of critical resources. The interface to CP0 is through various instructions encoded with the COP0 opcode, including the ability to move data to and from the CP0 registers, and specific functions that modify CP0 state. The CP0 registers and the interaction with them make up much of the Privileged Resource Architecture. 2.2.2 CP0 Registers The CP0 registers provide the interface between the ISA and the PRA. The CP0 registers are described in Chapter 8.MIPS32™ Architecture For Programmers Volume III, Revision 2.00 7 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 2 The MIPS32 Privileged Resource Architecture8 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 3 MIPS32 Operating Modes The MIPS32 PRA requires two operating mode: User Mode and Kernel Mode. When operating in User Mode, the programmer has access to the CPU and FPU registers that are provided by the ISA and to a flat, uniform virtual memory address space. When operating in Kernel Mode, the system programmer has access to the full capabilities of the processor, including the ability to change virtual memory mapping, control the system environment, and context switch between processes. In addition, the MIPS32 PRA supports the implementation of two additional modes: Supervisor Mode and EJTAG Debug Mode. Refer to the EJTAG specification for a description of Debug Mode. In Release 2 of the Architecture, support was added for 64-bit coprocessors (and, in particular, 64-bit floating point units) with 32-bit CPUs. As such, certain floating point instructions which were previously enabled by 64-bit operations on a MIPS64 processor are now enabled by a new 64-bit floating point operations enabled. 3.1 Debug Mode For processors that implement EJTAG, the processor is operating in Debug Mode if the DM bit in the CP0 Debug register is a one. If the processor is running in Debug Mode, it has full access to all resources that are available to Kernel Mode operation. 3.2 Kernel Mode The processor is operating in Kernel Mode when the DM bit in the Debug register is a zero (if the processor implements Debug Mode), and any of the following three conditions is true: • The KSU field in the CP0 Status register contains 2#00 • The EXL bit in the Status register is one • The ERL bit in the Status register is one The processor enters Kernel Mode at power-up, or as the result of an interrupt, exception, or error. The processor leaves Kernel Mode and enters User Mode or Supervisor Mode when all of the previous three conditions are false, usually as the result of an ERET instruction. 3.3 Supervisor Mode The processor is operating in Supervisor Mode (if that optional mode is implemented by the processor) when all of the following conditions are true: • The DM bit in the Debug register is a zero (if the processor implements Debug Mode) • The KSU field in the Status register contains 2#01 • The EXL and ERL bits in the Status register are both zeroMIPS32™ Architecture For Programmers Volume III, Revision 2.00 9 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 4 Virtual Memory4.3 Virtual Address Spaces The MIPS32 virtual address space is divided into five segments as shown in Figure 4-1. Each Segment of an Address Space is classified as “Mapped” or “Unmapped”. A “Mapped” address is one that is translated through the TLB or other address translation unit. An “Unmapped” address is one which is not translated through the TLB and which provides a window into the lowest portion of the physical address space, starting at physical address zero, and with a size corresponding to the size of the unmapped Segment. Additionally, the kseg1 Segment is classified as “Uncached”. References to this Segment bypass all levels of the cache hierarchy and allow direct access to memory without any interference from the caches. Table 4-1 lists the same information in tabular form. Figure 4-1 Virtual Address Space 16#FFFF FFFF Kernel Mappedkseg3 16#E000 0000 16#DFFF FFFF Supervisor Mappedksseg 16#C000 0000 16#BFFF FFFF Kernel Unmapped Uncachedkseg1 16#A000 0000 16#9FFF FFFF Kernel Unmappedkseg0 16#8000 0000 16#7FFF FFFF User Mapped useg 16#0000 000012 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 4.3 Virtual Address SpacesEach Segment of an Address Space is associated with one of the three processor operating modes (User, Supervisor, or Kernel). A Segment that is associated with a particular mode is accessible if the processor is running in that or a more privileged mode. For example, a Segment associated with User Mode is accessible when the processor is running in User, Supervisor, or Kernel Modes. A Segment is not accessible if the processor is running in a less privileged mode than that associated with the Segment. For example, a Segment associated with Supervisor Mode is not accessible when the processor is running in User Mode and such a reference results in an Address Error Exception. The “Reference Legal from Mode(s)” column in Table 4-2 lists the modes from which each Segment may be legally referenced. If a Segment has more than one name, each name denotes the mode from which the Segment is referenced. For example, the Segment name “useg” denotes a reference from user mode, while the Segment name “kuseg” denotes a reference to the same Segment from kernel mode. Figure 4-2 shows the Address Space as seen when the processor is operating in each of the operating modes. Table 4-1 Virtual Memory Address Spaces VA31..29 Segment Name(s) Address Range Associated with Mode Reference Legal from Mode(s) Actual Segment Size 2#111 kseg3 16#FFFF FFFF through 16#E000 0000 Kernel Kernel 229 bytes 2#110 ssegksseg 16#DFFF FFFF through 16#C000 0000 Supervisor SupervisorKernel 2 29 bytes 2#101 kseg1 16#BFFF FFFF through 16#A000 0000 Kernel Kernel 229 bytes 2#100 kseg0 16#9FFF FFFF through 16#8000 0000 Kernel Kernel 229 bytes 2#0xx useg suseg kuseg 16#7FFF FFFF through 16#0000 0000 User User Supervisor Kernel 231 bytesMIPS32™ Architecture For Programmers Volume III, Revision 2.00 13 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 4 Virtual Memory4.4 Compliance A MIPS32 compliant processor must implement the following Segments: • useg/kuseg • kseg0 • kseg1 In addition, a MIPS32 compliant processor using the TLB-based address translation mechanism must also implement the kseg3 Segment. 4.5 Access Control as a Function of Address and Operating Mode Table 4-2 enumerates the action taken by the processor for each section of the 32-bit Address Space as a function of the operating mode of the processor. The selection of TLB Refill vector and other special-cased behavior is also listed for each reference. Figure 4-2 References as a Function of Operating Mode User Mode References Supervisor Mode References Kernel Mode References 16#FFFF FFFF Address Error 16#FFFF FFFF Address Error 16#FFFF FFFF Kernel Mappedkseg3 16#E000 0000 16#E000 0000 16#DFFF FFFF Supervisor Mapped 16#DFFF FFFF Supervisor Mappedsseg ksseg 16#C000 0000 16#C000 0000 16#BFFF FFFF Address Error 16#BFFF FFFF Kernel Unmapped Uncachedkseg1 16#A000 0000 16#9FFF FFFF Kernel Unmappedkseg0 16#8000 0000 16#8000 0000 16#8000 0000 16#7FFF FFFF User Mapped 16#7FFF FFFF User Mapped 16#7FFF FFFF User Mapped useg suseg kuseg 16#0000 0000 16#0000 0000 16#0000 000014 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 4.9 TLB-Based Virtual Address Translationaddress with all processes. To address this need, the TLB includes a global (G) bit which over-rides the ASID comparison during translation. 4.9.2 TLB Organization The TLB is a fully-associative structure which is used to translate virtual addresses. Each entry contains two logical components: a comparison section and a physical translation section. The comparison section includes the virtual page number (VPN2 and, in Release 2, VPNX) (actually, the virtual page number/2 since each entry maps two physical pages) of the entry, the ASID, the G(lobal) bit and a recommended mask field which provides the ability to map different page sizes with a single entry. The physical translation section contains a pair of entries, each of which contains the physical page frame number (PFN), a valid (V) bit, a dirty (D) bit, and a cache coherency field (C), whose valid encodings are given in Table 8-8 on page 61. There are two entries in the translation section for each TLB entry because each TLB entry maps an aligned pair of virtual pages and the pair of physical translation entries corresponds to the even and odd pages of the pair. Figure 4-3 shows the logical arrangement of a TLB entry, including the optional support added in Release 2 of the Architecture for 1KB page sizes. Light grey fields denote extensions to the right that are required to support 1KB page sizes. This extension is not present in an implementation of Release 1 of the Architecture. The fields of the TLB entry correspond exactly to the fields in the CP0 PageMask, EntryHi, EntryLo0 and EntryLo1 registers. The even page entries in the TLB (e.g., PFN0) come from EntryLo0. Similarly, odd page entries come from EntryLo1. 4.9.3 TLB Initialization In many processor implementations, software must initialize the TLB during the power-up process. In processors that detect multiple TLB matches and signal this via a machine check assumption, software must be prepared to handle such an exception or use a TLB initialization algorithm that minimizes or eliminates the possibility of the exception. In Release 1 of the Architecture, processor implementations could detect and report multiple TLB matches either on a TLB write (TLBWI or TLBWR instructions) or a TLB read (TLB access or TLBR or TLBP instructions). In Release 2 of the Architecture, processor implentations are limited to reporting multiple TLB matches only on TLB write, and this is also true of most implementations of Release 1 of the Architecture. Figure 4-3 Contents of a TLB Entry Mask MaskX VPN2 VPN2X G ASID PFN0 C0 D0 V0 PFN1 C1 D1 V1 Fields marked with this color are optional Release 2 features required to support 1KB pagesMIPS32™ Architecture For Programmers Volume III, Revision 2.00 17 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 4 Virtual MemoryThe following code example shows a TLB initialization routine which, on implementations of Release 2 of the Architecture, eliminates the possibility of reporting a machine check during TLB initialization. This example has equivalent effect on implementations of Release 1 of the Architecture which report multiple TLB exceptions only on a TLB write, and minimizes the probability of such an exception occuring on other implementations. /* * InitTLB * * Initialize the TLB to a power-up state, guaranteeing that all entries * are unique and invalid. * * Arguments: * a0 = Maximum TLB index (from MMUSize field of C0_Config1) * * Returns: * No value * * Restrictions: * This routine must be called in unmapped space * * Algorithm: * va = kseg0_base; * for (entry = max_TLB_index; entry >= 0, entry--) { * while (TLB_Probe_Hit(va)) { * va += Page_Size; * } * TLB_Write(entry, va, 0, 0, 0); * } * * Notes: * - The Hazard macros used in the code below expand to the appropriate * number of SSNOPs in an implementation of Release 2 of the * Architecture, and to an ehb in an implementation of Release 2 of * the Architecture. See Chapter 7, “CP0 Hazards,” on page 49 for * more additional information. */ InitTLB: /* * Clear PageMask, EntryLo0 and EntryLo1 so that valid bits are off, PFN values * are zero, and the default page size is used. */ mtc0 zero, C0_EntryLo0 /* Clear out PFN and valid bits */ mtc0 zero, C0_EntryLo1 mtc0 zero, C0_PageMask /* Clear out mask register * /* Start with the base address of kseg0 for the VA part of the TLB */ la t0, A_K0BASE /* A_K0BASE == 16#8000.0000 */18 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 4.9 TLB-Based Virtual Address Translation/* * Write the VA candidate to EntryHi and probe the TLB to see if if is * already there. If it is, a write to the TLB may cause a machine * check, so just increment the VA candidate by one page and try again. */ 10: mtc0 t0, C0_EntryHi /* Write VA candidate */ TLBP_Write_Hazard() /* Clear EntryHi hazard (ssnop/ehb in R1/2) */ tlbp /* Probe the TLB to check for a match */ TLBP_Read_Hazard() /* Clear Index hazard (ssnop/ehb in R1/2) */ mfc0 t1, C0_Index /* Read back flag to check for match */ bgez t1, 10b /* Branch if about to duplicate an entry */ addiu t0, (1<<S_EntryHiVPN2) /* Add 1 to VPN index in va */ /* * A write of the VPN candidate will be unique, so write this entry * into the next index, decrement the index, and continue until the * index goes negative (thereby writing all TLB entries) */ mtc0 a0, C0_Index /* Use this as next TLB index */ TLBW_Write_Hazard() /* Clear Index hazard (ssnop/ehb in R1/2) */ tlbwi /* Write the TLB entry */ bne a0, zero, 10b /* Branch if more TLB entries to do */ addiu a0, -1 /* Decrement the TLB index /* * Clear Index and EntryHi simply to leave the state constant for all * returns */ mtc0 zero, C0_Index mtc0 zero, C0_EntryHi jr ra /* Return to caller */ nop 4.9.4 Address Translation Release 2 of the Architecture introduced support for 1KB pages. For clarity in the discussion below, the following terms should be taken in the general sense to include the new Release 2 features: When an address translation is requested, the virtual page number and the current process ASID are presented to the TLB. All entries are checked simultaneously for a match, which occurs when all of the following conditions are true: • The current process ASID (as obtained from the EntryHi register) matches the ASID field in the TLB entry, or the G bit is set in the TLB entry. Term Used Below Release 2 Substitution Comment VPN2 VPN2 || VPN2X Release 2 implementations that support 1KB pages concatenate the VPN2 and VPN2X fields to form the virtual page number for a 1KB page Mask Mask || MaskX Release 2 implementations that support 1KB pages concatenate the Mask and MaskX fields to form the don’t care mask for 1KB pagesMIPS32™ Architecture For Programmers Volume III, Revision 2.00 19 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 4 Virtual Memoryfound ← 1 break endif endfor if found = 0 then SignalException(TLBMiss, reftype) endif Table 4-4 demonstrates how the physical address is generated as a function of the page size of the TLB entry that matches the virtual address. The “Even/Odd Select” column of Table 4-4 indicates which virtual address bit is used to select between the even (EntryLo0) or odd (EntryLo1) entry in the matching TLB entry. The “PA(PABITS-1)..0 Generated From” columns specify how the physical address is generated from the selected PFN and the offset-in-page bits in the virtual address. In this column, PFN is the physical page number as loaded into the TLB from the EntryLo0 or EntryLo1 registers, and has one of two bit ranges: PFN Range PA Range Comment PFN(PABITS-1)-12..0 PAPABITS-1..12 Release 1 implementation, or Release 2 implementation without support for 1KB pages PFN(PABITS-1)-10..0 PAPABITS-1..10 Release 2 implementation with support for 1KB pages enabled Table 4-4 Physical Address Generation Page Size Even/Odd Select PA(PABITS-1)..0 Generated From: Release 1 or Release 2 with 1KB Page Support Disabled Release 2 with 1KB Page Support Enabled 1K Bytes VA10 Not Applicable PFN(PABITS-1)-10..0 || VA9..0 4K Bytes VA12 PFN(PABITS-1)-12..0 || VA11..0 PFN(PABITS-1)-10..2 || VA11..0 16K Bytes VA14 PFN(PABITS-1)-12..2 || VA13..0 PFN(PABITS-1)-10..4 || VA13..0 64K Bytes VA16 PFN(PABITS-1)-12..4 || VA15..0 PFN(PABITS-1)-10..6 || VA15..0 256K Bytes VA18 PFN(PABITS-1)-12..6 || VA17..0 PFN(PABITS-1)-10..8 || VA17..0 1M Bytes VA20 PFN(PABITS-1)-12..8 || VA19..0 FN(PABITS-1)-10..10 || VA19..0 4M Bytes VA22 PFN(PABITS-1)-12..10 || VA21..0 PFN(PABITS-1)-10..12 || VA21..0 16M Bytes VA24 PFN(PABITS-1)-12..12 || VA23..0 PFN(PABITS-1)-10..14 || VA23..0 64MBytes VA26 PFN(PABITS-1)-12..14 || VA25..0 PFN(PABITS-1)-10..16 || VA25..0 256MBytes VA28 PFN(PABITS-1)-12..16 || VA27..0 PFN(PABITS-1)-10..18 || VA27..022 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and Exceptions Release 2 of the Architecture added the following features related to the processing of Exceptions and Interrupts: • The addition of the Coprocessor 0 EBase register, which allows the exception vector base address to be modified for exceptions that occur when StatusBEV equals 0. The EBase register is required. • The extension of the Release 1 interrupt control mechanism to include two optional interrupt modes: • Vectored Interrupt (VI) mode, in which the various sources of interrupts are prioritized by the processor and each interrupt is vectored directly to a dedicated handler. When combined with GPR shadow registers, introduced in the next chapter, this mode significantly reduces the number of cycles required to process an interrupt. • External Interrupt Controller (EIC) mode, in which the definition of the coprocessor 0 register fields associated with interrupts changes to support an external interrupt controller. This can support many more prioritized interrupts, while still providing the ability to vector an interrupt directly to a dedicated handler and take advantage of the GPR shadow registers. • The ability to stop the Count register for highly power-sensitive applications in which the Count register is not used, or for reduced power mode. This change is required. • The addition of the DI and EI instructions which provide the ability to atomically disable or enable interrupts. Both instructions are required. • The addition of the TI and PCI bits in the Cause register to denote pending timer and performance counter interrupts. This change is required. 5.1 Interrupts Release 1 of the Architecture included support for two software interrupts, six hardware interrupts, and two special-purpose interrupts: timer and performance counter. The timer and performance counter interrupts were combined with hardware interrupt 5 in an implementation-dependent manner. Interrupts were handled either through the general exception vector (offset 16#180) or the special interrupt vector (16#200), based on the value of CauseIV. Software was required to prioritize interrupts as a function of the CauseIP bits in the interrupt handler prologue. Release 2 of the Architecture adds an upward-compatible extension to the Release 1 interrupt architecture that supports vectored interrupts. In addition, Release 2 adds a new interrupt mode that supports the use of an external interrupt controller by changing the interrupt architecture. Although a Non-Maskable Interrupt (NMI) includes “interrupt” in its name, it is more correctly described as an NMI exception because it does not affect, nor is it controlled by the processor interrupt system. An interrupt is only taken when all of the following are true: • A specific request for interrupt service is made, as a function of the interrupt mode, described below. • The IE bit in the Status register is a one. • The DM bit in the Debug register is a zero (for processors implementing EJTAG) • The EXL and ERL bits in the Status register are both zero.MIPS32™ Architecture For Programmers Volume III, Revision 2.00 23 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and ExceptionsLogically, the request for interrupt service is ANDed with the IE bit of the Status register. The final interrupt request is then asserted only if both the EXL and ERL bits in the Status register are zero, and the DM bit in the Debug register is zero, corresponding to a non-exception, non-error, non-debug processing mode, respectively. 5.1.1 Interrupt Modes An implementation of Release 1 of the Architecture only implements interrupt compatibility mode. An implementation of Release 2 of the Architecture may implement up to three interrupt modes: • Interrupt compatibility mode, which acts identically to that in an implementation of Release 1 of the Architecture. This mode is required. • Vectored Interrupt (VI) mode, which adds the ability to prioritize and vector interrupts to a handler dedicated to that interrupt, and to assign a GPR shadow set for use during interrupt processing. This mode is optional and its presence is denoted by the VInt bit in the Config3 register. • External Interrupt Controller (EIC) mode, which redefines the way in which interrupts are handled to provide full support for an external interrupt controller handling prioritization and vectoring of interrupts. This mode is optional and its presence is denoted by the VEIC bit in the Config3 register. A compatible implementation of Release 2 of the Architecture must implement interrupt compatibility mode, and may optionally implement one or both vectored interrupt modes. Inclusion of the optional modes may be done selectively in the implementation of the processor, or they may always be inculcated and be dynamically enabled based on coprocessor 0 control bits. The reset state of the processor is to interrupt compatibility mode such that an implementation of Release 2 of the Architecture is fully compatible with implementations of Release 1 of the Architecture. Table 5-1 shows the current interrupt mode of the processor as a function of the coprocessor 0 register fields that can affect the mode. 5.1.1.1 Interrupt Compatibility Mode This is the only interrupt mode for a Release 1 processor and the default interrupt mode for a Release 2 processor. This mode is entered when a Reset exception occurs. In this mode, interrupts are non-vectored and dispatched though Table 5-1 Interrupt Modes St at us B E V C au se IV In tC tl V S C on fig 3 V IN T C on fig 3 V E IC Interrupt Mode 1 x x x x Compatibly x 0 x x x Compatibility x x =0 x x Compatibility 0 1 ≠0 1 0 Vectored Interrupt 0 1 ≠0 x 1 External Interrupt Controller 0 1 ≠0 0 0 Can’t happen - IntCtlVS can not be non-zero if neither Vectored Interrupt nor External Interrupt Controller mode is implemented. “x” denotes don’t care24 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5.1 Interrupts */ /* * To complete interrupt processing, the saved values must be restored * and the original interrupted code restarted. */ di /* Disable interrupts - may not be required */ lw k0, StatusSave /* Get saved Status (including EXL set) */ lw k1, EPCSave /* and EPC */ mtc0 k0, C0_Status /* Restore the original value */ mtc0 k1, C0_EPC /* and EPC */ /* Restore GPRs and software state */ eret /* Dismiss the interrupt */ 5.1.1.2 Vectored Interrupt Mode Vectored Interrupt mode builds on the interrupt compatibility mode by adding a priority encoder to prioritize pending interrupts and to generate a vector with which each interrupt can be directed to a dedicated handler routine. This mode also allows each interrupt to be mapped to a GPR shadow set for use by the interrupt handler. Vectored Interrupt mode is in effect if all of the following conditions are true: • Config3VInt = 1 • Config3VEIC = 0 • IntCtlVS ≠ 0 • CauseIV = 1 • StatusBEV = 0 In VI interrupt mode, the six hardware interrupts are interpreted as individual hardware interrupt requests. The timer and performance counter interrupts are combined in an implementation-dependent way with the hardware interrupts (with the interrupt with which they are combined indicated by IntCtlIPTI and IntCtlIPPCI, respectively) to provide the appropriate relative priority of these interrupts with that of the hardware interrupts. The processor interrupt logic ANDs each of the CauseIP bits with the corresponding StatusIM bits. If any of these values is 1, and if interrupts are enabled (StatusIE = 1, StatusEXL = 0, and StatusERL = 0), an interrupt is signaled and a priority encoder scans the values in the order shown in Table 5-3. Table 5-3 Relative Interrupt Priority for Vectored Interrupt Mode Relative Priority Interrupt Type Interrupt Source Interrupt Request Calculated From Vector Number Generated by Priority Encoder Highest Priority Hardware HW5 CauseIP7 and StatusIM7 7 HW4 CauseIP6 and StatusIM6 6 HW3 CauseIP5 and StatusIM5 5 HW2 CauseIP4 and StatusIM4 4 HW1 CauseIP3 and StatusIM3 3 HW0 CauseIP2 and StatusIM2 2 Software SW1 CauseIP1 and StatusIM1 1 Lowest Priority SW0 CauseIP0 and StatusIM0 0MIPS32™ Architecture For Programmers Volume III, Revision 2.00 27 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and ExceptionsThe priority order places a relative priority on each hardware interrupt and places the software interrupts at a priority lower than all hardware interrupts. When the priority encoder finds the highest priority pending interrupt, it outputs an encoded vector number that is used in the calculation of the handler for that interrupt, as described below. This is shown pictorially in Figure 5-1. Note that an interrupt request may be deasserted between the time the processor detects the interrupt request and the time that the software interrupt handler runs. The software interrupt handler must be prepared to handle this condition by simply returning from the interrupt via ERET. A typical software handler for vectored interrupt mode bypasses the entire sequence of code following the IVexception label shown for the compatibility mode handler above. Instead, the hardware performs the prioritization, dispatching directly to the interrupt processing routine. Unlike the compatibility mode examples, a vectored interrupt handler may take advantage of a dedicated GPR shadow set to avoid saving any registers. As such, the SimpleInterrupt code shown above need not save the GPRs. A nested interrupt is similar to that shown for compatibility mode, but may also take advantage of running the nested exception routine in the GPR shadow set dedicated to the interrupt or in another shadow set. Such a routine might look as follows: NestedException: /* * Nested exceptions typically require saving the EPC, Status and SRSCtl registers, * setting up the appropriate GPR shadow set for the routine, disabling * the appropriate IM bits in Status to prevent an interrupt loop, putting * the processor in kernel mode, and re-enabling interrupts. The sample code * below can not cover all nuances of this processing and is intended only * to demonstrate the concepts. */ /* Use the current GPR shadow set, and setup software context */ mfc0 k0, C0_EPC /* Get restart address */ sw k0, EPCSave /* Save in memory */ IP7 IP6 IP5 IP4 IP3 IP2 IP1 IP0 IM7 IM6 IM5 IM4 IM3 IM2 IM1 IM0 Pr io ri ty E nc od e HW5 HW4 HW3 HW2 HW1 HW0 C om bi ne CauseTI CausePCI StatusIE Interrupt Request Vector Number Latch Mask Encode Figure 5-1 Interrupt Generation for Vectored Interrupt Mode Any Request O ff se t G en er at or IntCtlVS Exception Vector Offset Generate SRSMap Shadow Set Number IntCtlIPPCI IntCtlIPTI28 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5.1 Interruptsmfc0 k0, C0_Status /* Get Status value */ sw k0, StatusSave /* Save in memory */ mfc0 k0, C0_SRSCtl /* Save SRSCtl if changing shadow sets */ sw k0, SRSCtlSave li k1, ~IMbitsToClear /* Get Im bits to clear for this interrupt */ /* this must include at least the IM bit */ /* for the current interrupt, and may include */ /* others */ and k0, k0, k1 /* Clear bits in copy of Status */ /* If switching shadow sets, write new value to SRSCtlPSS here */ ins k0, zero, S_StatusEXL, (W_StatusKSU+W_StatusERL+W_StatusEXL) /* Clear KSU, ERL, EXL bits in k0 */ mtc0 k0, C0_Status /* Modify mask, switch to kernel mode, */ /* re-enable interrupts */ /* * If switching shadow sets, clear only KSU above, write target * address to EPC, and do execute an eret to clear EXL, switch * shadow sets, and jump to routine */ /* Process interrupt here, including clearing device interrupt */ /* * To complete interrupt processing, the saved values must be restored * and the original interrupted code restarted. */ di /* Disable interrupts - may not be required */ lw k0, StatusSave /* Get saved Status (including EXL set) */ lw k1, EPCSave /* and EPC */ mtc0 k0, C0_Status /* Restore the original value */ lw k0, SRSCtlSave /* Get saved SRSCtl */ mtc0 k1, C0_EPC /* and EPC */ mtc0 k0, C0_SRSCtl /* Restore shadow sets */ ehb /* Clear hazard */ eret /* Dismiss the interrupt */ 5.1.1.3 External Interrupt Controller Mode External Interrupt Controller Mode redefines the way that the processor interrupt logic is configured to provide support for an external interrupt controller. The interrupt controller is responsible for prioritizing all interrupts, including hardware, software, timer, and performance counter interrupts, and directly supplying to the processor the vector number of the highest priority interrupt. EIC interrupt mode is in effect if all of the following conditions are true: • Config3VEIC = 1 • IntCtlVS ≠ 0 • CauseIV = 1 • StatusBEV = 0 In EIC interrupt mode, the processor sends the state of the software interrupt requests (CauseIP1..IP0), the timer interrupt request (CauseTI), and the performance counter interrupt request (CausePCI) to the external interrupt controller, where it prioritizes these interrupts in a system-dependent way with other hardware interrupts. The interrupt controller can be a hard-wired logic block, or it can be configurable based on control and status registers. This allows the interrupt controller to be more specific or more general as a function of the system environment and needs. The external interrupt controller prioritizes its interrupt requests and produces the vector number of the highest priority interrupt to be serviced. The vector number, called the Requested Interrupt Priority Level (RIPL), is a 6-bit encodedMIPS32™ Architecture For Programmers Volume III, Revision 2.00 29 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and ExceptionsThe general equation for the exception vector offset for a vectored interrupt is: vectorOffset ← 16#200 + (vectorNumber × (IntCtlVS || 2#00000)) 5.2 Exceptions Normal execution of instructions may be interrupted when an exception occurs. Such events can be generated as a by-product of instruction execution (e.g., an integer overflow caused by an add instruction or a TLB miss caused by a load instruction), or by an event not directly related to instruction execution (e.g., an external interrupt). When an exception occurs, the processor stops processing instructions, saves sufficient state to resume the interrupted instruction stream, enters Kernel Mode, and starts a software exception handler. The saved state and the address of the software exception handler are a function of both the type of exception, and the current state of the processor. 5.2.1 Exception Vector Locations The Reset, Soft Reset, and NMI exceptions are always vectored to location 16#BFC0.0000. EJTAG Debug exceptions are vectored to location 16#BFC0.0480, or to location 16#FF20.0200 if the ProbTrap bit is zero or one, respectively, in the EJTAG_Control_register. Addresses for all other exceptions are a combination of a vector offset and a vector base address. In Release 1 of the architecture, the vector base address was fixed. In Release 2 of the architecture, software is allowed to specify the vector base address via the EBase register for exceptions that occur when StatusBEV equals 0. Table 5-5 gives the vector base address as a function of the exception and whether the BEV bit is set in the Status register. Table 5-6 gives the offsets from the vector base address as a function of the exception. Note that the IV bit in the Cause register causes Interrupts Table 5-4 Exception Vector Offsets for Vectored Interrupts Vector Number Value of IntCtlVS Field 2#00001 2#00010 2#00100 2#01000 2#10000 0 16#0200 16#0200 16#0200 16#0200 16#0200 1 16#0220 16#0240 16#0280 16#0300 16#0400 2 16#0240 16#0280 16#0300 16#0400 16#0600 3 16#0260 16#02C0 16#0380 16#0500 16#0800 4 16#0280 16#0300 16#0400 16#0600 16#0A00 5 16#02A0 16#0340 16#0480 16#0700 16#0C00 6 16#02C0 16#0380 16#0500 16#0800 16#0E00 7 16#02E0 16#03C0 16#0580 16#0900 16#1000 • • • 61 16#09A0 16#1140 16#2080 16#3F00 16#7C00 62 16#09C0 16#1180 16#2100 16#4000 16#7E00 63 16#09E0 16#11C0 16#2180 16#4100 16#800032 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5.2 Exceptionsto use a dedicated exception vector offset, rather than the general exception vector. For implementations of Release 2 of the Architecture, Table 5-4 gives the offset from the base address in the case where StatusBEV = 0 and CauseIV = 1. For implementations of Release 1 of the architecture in which CauseIV = 1, the vector offset is as if IntCtlVS were 0. Table 5-7 combines these two tables into one that contains all possible vector addresses as a function of the state that can affect the vector selection. To avoid complexity in the table, the vector address value assumes that the EBase register, as implemented in Release 2 devices, is not changed from its reset state and that IntCtlVS is 0. In Release 2 of the Architecture, software must guarantee that EBase15..12 contains zeros in all bit positions less than or equal to the most significant bit in the vector offset. This situation can only occur when a vector offset greater than 16#FFF is generated when an interrupt occurs with VI or EIC interrupt mode enabled. The operation of the processor is UNDEFINED if this condition is not met. Table 5-5 Exception Vector Base Addresses Exception StatusBEV 0 1 Reset, Soft Reset, NMI 16#BFC0.0000 EJTAG Debug (with ProbEn = 0 in the EJTAG_Control_register) 16#BFC0.0480 EJTAG Debug (with ProbEn = 1 in the EJTAG_Control_register) 16#FF20.0200 Cache Error For Release 1 of the architecture: 16#A000.0000 For Release 2 of the architecture: EBase31..30 || 1 || EBase28..12 || 16#000 Note that EBase31..30 have the fixed value 2#10 16#BFC0.0300 Other For Release 1 of the architecture: 16#8000.0000 For Release 2 of the architecture: EBase31..12 || 16#000 Note that EBase31..30 have the fixed value 2#10 16#BFC0.0200 Table 5-6 Exception Vector Offsets Exception Vector Offset TLB Refill, EXL = 0 16#000 Cache error 16#100 General Exception 16#180 Interrupt, CauseIV = 1 16#200 (In Release 2 implementations, this is the base of the vectored interrupt table when StatusBEV = 0) Reset, Soft Reset, NMI None (Uses Reset Base Address)MIPS32™ Architecture For Programmers Volume III, Revision 2.00 33 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and Exceptions5.2.2 General Exception Processing With the exception of Reset, Soft Reset, NMI, cache error, and EJTAG Debug exceptions, which have their own special processing as described below, exceptions have the same basic processing flow: • If the EXL bit in the Status register is zero, the EPC register is loaded with the PC at which execution will be restarted and the BD bit is set appropriately in the Cause register (see Table 8-24 on page 87). The value loaded into the EPC register is dependent on whether the processor implements the MIPS16 ASE, and whether the instruction is in the delay slot of a branch or jump which has delay slots. Table 5-8 shows the value stored in each of the CP0 PC registers, including EPC. For implementations of Release 2 of the Architecture if StatusBEV = 0, the CSS field in the SRSCtl register is copied to the PSS field, and the CSS value is loaded from the appropriate source. If the EXL bit in the Status register is set, the EPC register is not loaded and the BD bit is not changed in the Cause register. For implementations of Release 2 of the Architecture, the SRSCtl register is not changed. Table 5-7 Exception Vectors Exception StatusBEV StatusEXL CauseIV EJTAG ProbEn Vector For Release 2 Implementations, assumes that EBase retains its reset state and that IntCtlVS = 0 Reset, Soft Reset, NMI x x x x 16#BFC0.0000 EJTAG Debug x x x 0 16#BFC0.0480 EJTAG Debug x x x 1 16#FF20.0200 TLB Refill 0 0 x x 16#8000.0000 TLB Refill 0 1 x x 16#8000.0180 TLB Refill 1 0 x x 16#BFC0.0200 TLB Refill 1 1 x x 16#BFC0.0380 Cache Error 0 x x x 16#A000.0100 Cache Error 1 x x x 16#BFC0.0300 Interrupt 0 0 0 x 16#8000.0180 Interrupt 0 0 1 x 16#8000.0200 Interrupt 1 0 0 x 16#BFC0.0380 Interrupt 1 0 1 x 16#BFC0.0400 All others 0 x x x 16#8000.0180 All others 1 x x x 16#BFC0.0380 ‘x’ denotes don’t care34 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5.2 Exceptions• The Wired register is initialized to zero. • The Config, Config1, Config2, and Config3 registers are initialized with their boot state. • The RP, BEV, TS, SR, NMI, and ERL fields of the Status register are initialized to a specified state. • Watch register enables and Performance Counter register interrupt enables are cleared. • The ErrorEPC register is loaded with the restart PC, as described in Table 5-8. Note that this value may or may not be predictable if the Reset Exception was taken as the result of power being applied to the processor because PC may not have a valid value in that case. In some implementations, the value loaded into ErrorEPC register may not be predictable on either a Reset or Soft Reset Exception. • PC is loaded with 16#BFC0 0000. Cause Register ExcCode Value None Additional State Saved None Entry Vector Used Reset (16#BFC0 0000) Operation Random ← TLBEntries - 1 Wired ← 0 Config ← ConfigurationState ConfigK0 ← 2 # Suggested - see Config register description Config1 ← ConfigurationState Config2 ← ConfigurationState # if implemented Config3 ← ConfigurationState # if implemented StatusRP ← 0 StatusBEV ← 1 StatusTS ← 0 StatusSR ← 0 StatusNMI ← 0 StatusERL ← 1 WatchLo[n]I ← 0 # For all implemented Watch registers WatchLo[n]R ← 0 # For all implemented Watch registers WatchLo[n]W ← 0 # For all implemented Watch registers PerfCnt.Control[n]IE ← 0 # For all implemented PerfCnt registers if InstructionInBranchDelaySlot then ErrorEPC ← restartPC # PC of branch/jump else ErrorEPC ← restartPC # PC of instruction endif PC ← 16#BFC0 0000 5.2.5 Soft Reset Exception A Soft Reset Exception occurs when the Reset signal is asserted to the processor. This exception is not maskable. When a Soft Reset Exception occurs, the processor performs a subset of the full reset initialization. Although a Soft Reset Exception does not unnecessarily change the state of the processor, it may be forced to do so in order to place the processor in a state in which it can execute instructions from uncached, unmapped address space. Since bus, cache, or other operations may be interrupted, portions of the cache, memory, or other processor state may be inconsistent.MIPS32™ Architecture For Programmers Volume III, Revision 2.00 37 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and ExceptionsThe primary difference between the Reset and Soft Reset Exceptions is in actual use. The Reset Exception is typically used to initialize the processor on power-up, while the Soft Reset Exception is typically used to recover from a non-responsive (hung) processor. The semantic difference is provided to allow boot software to save critical coprocessor 0 or other register state to assist in debugging the potential problem. As such, the processor may reset the same state when either reset signal is asserted, but the interpretation of any state saved by software may be very different. In addition to any hardware initialization required, the following state is established on a Soft Reset Exception: • The RP, BEV, TS, SR, NMI, and ERL fields of the Status register are initialized to a specified state. • Watch register enables and Performance Counter register interrupt enables are cleared. • The ErrorEPC register is loaded with the restart PC, as described in Table 5-8. • PC is loaded with 16#BFC0 0000. Cause Register ExcCode Value None Additional State Saved None Entry Vector Used Reset (16#BFC0 0000) Operation ConfigK0 ← 2 # Suggested - see Config register description StatusRP ← 0 StatusBEV ← 1 StatusTS ← 0 StatusSR ← 1 StatusNMI ← 0 StatusERL ← 1 WatchLo[n]I ← 0 # For all implemented Watch registers WatchLo[n]R ← 0 # For all implemented Watch registers WatchLo[n]W ← 0 # For all implemented Watch registers PerfCnt.Control[n]IE ← 0 # For all implemented PerfCnt registers if InstructionInBranchDelaySlot then ErrorEPC ← restartPC # PC of branch/jump else ErrorEPC ← restartPC # PC of instruction endif PC ← 16#BFC0 0000 5.2.6 Non Maskable Interrupt (NMI) Exception A non maskable interrupt exception occurs when the NMI signal is asserted to the processor. Although described as an interrupt, it is more correctly described as an exception because it is not maskable. An NMI occurs only at instruction boundaries, so does not do any reset or other hardware initialization. The state of the cache, memory, and other processor state is consistent and all registers are preserved, with the following exceptions: • The BEV, TS, SR, NMI, and ERL fields of the Status register are initialized to a specified state. • The ErrorEPC register is loaded with restart PC, as described in Table 5-8. • PC is loaded with 16#BFC0 0000.38 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5.2 ExceptionsCause Register ExcCode Value None Additional State Saved None Entry Vector Used Reset (16#BFC0 0000) Operation StatusBEV ← 1 StatusTS ← 0 StatusSR ← 0 StatusNMI ← 1 StatusERL ← 1 if InstructionInBranchDelaySlot then ErrorEPC ← restartPC # PC of branch/jump else ErrorEPC ← restartPC # PC of instruction endif PC ← 16#BFC0 0000 5.2.7 Machine Check Exception A machine check exception occurs when the processor detects an internal inconsistency. The following conditions cause a machine check exception: • Detection of multiple matching entries in the TLB in a TLB-based MMU. Cause Register ExcCode Value MCheck (See Table 8-25 on page 90) Additional State Saved Depends on the condition that caused the exception. See the descriptions above. Entry Vector Used General exception vector (offset 16#180) 5.2.8 Address Error Exception An address error exception occurs under the following circumstances: • An instruction is fetched from an address that is not aligned on a word boundary. • A load or store word instruction is executed in which the address is not aligned on a word boundary. • A load or store halfword instruction is executed in which the address is not aligned on a halfword boundary. • A reference is made to a kernel address space from User Mode or Supervisor Mode. • A reference is made to a supervisor address space from User Mode. Note that in the case of an instruction fetch that is not aligned on a word boundary, the PC is updated before the condition is detected. Therefore, both EPC and BadVAddr point at the unaligned instruction address.MIPS32™ Architecture For Programmers Volume III, Revision 2.00 39 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and Exceptions5.2.12 Cache Error Exception A cache error exception occurs when an instruction or data reference detects a cache tag or data error, or a parity or ECC error is detected on the system bus when a cache miss occurs. This exception is not maskable. Because the error was in a cache, the exception vector is to an unmapped, uncached address. Cause Register ExcCode Value N/A Additional State Saved Entry Vector Used Cache error vector (offset 16#100) Operation CacheErr ← ErrorState StatusERL ← 1 if InstructionInBranchDelaySlot then ErrorEPC ← restartPC # PC of branch/jump else ErrorEPC ← restartPC # PC of instruction endif if StatusBEV = 1 then PC ← 16#BFC0 0200 + 16#100 else PC ← 16#A000 0000 + 16#100 endif 5.2.13 Bus Error Exception A bus error occurs when an instruction, data, or prefetch access makes a bus request (due to a cache miss or an uncacheable reference) and that request is terminated in an error. Note that parity errors detected during bus transactions are reported as cache error exceptions, not bus error exceptions. Cause Register ExcCode Value IBE: Error on an instruction reference DBE: Error on a data reference See Table 8-25 on page 90. Additional State Saved None Entry Vector Used General exception vector (offset 16#180) Register State Value CacheErr Error state ErrorEPC Restart PC42 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5.2 Exceptions5.2.14 Integer Overflow Exception An integer overflow exception occurs when selected integer instructions result in a 2’s complement overflow. Cause Register ExcCode Value Ov (See Table 8-25 on page 90) Additional State Saved None Entry Vector Used General exception vector (offset 16#180) 5.2.15 Trap Exception A trap exception occurs when a trap instruction results in a TRUE value. Cause Register ExcCode Value Tr (See Table 8-25 on page 90) Additional State Saved None Entry Vector Used General exception vector (offset 16#180) 5.2.16 System Call Exception A system call exception occurs when a SYSCALL instruction is executed. Cause Register ExcCode Value Sys (See Table 8-24 on page 87) Additional State Saved None Entry Vector Used General exception vector (offset 16#180) 5.2.17 Breakpoint Exception A breakpoint exception occurs when a BREAK instruction is executed. Cause Register ExcCode Value Bp (See Table 8-25 on page 90) Additional State Saved NoneMIPS32™ Architecture For Programmers Volume III, Revision 2.00 43 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 5 Interrupts and ExceptionsEntry Vector Used General exception vector (offset 16#180) 5.2.18 Reserved Instruction Exception A Reserved Instruction Exception occurs if any of the following conditions is true: • An instruction was executed that specifies an encoding of the opcode field that is flagged with “∗” (reserved), “β” (higher-order ISA), or an unimplemented “ε” (ASE). • An instruction was executed that specifies a SPECIAL opcode encoding of the function field that is flagged with “∗” (reserved), or “β” (higher-order ISA). • An instruction was executed that specifies a REGIMM opcode encoding of the rt field that is flagged with “∗” (reserved). • An instruction was executed that specifies an unimplemented SPECIAL2 opcode encoding of the function field that is flagged with an unimplemented “θ” (partner available), or an unimplemented “σ” (EJTAG). • An instruction was executed that specifies a COPz opcode encoding of the rs field that is flagged with “∗” (reserved), “β” (higher-order ISA), or an unimplemented “ε” (ASE), assuming that access to the coprocessor is allowed. If access to the coprocessor is not allowed, a Coprocessor Unusable Exception occurs instead. For the COP1 opcode, some implementations of previous ISAs reported this case as a Floating Point Exception, setting the Unimplemented Operation bit in the Cause field of the FCSR register. • An instruction was executed that specifies an unimplemented COP0 opcode encoding of the function field when rs is CO that is flagged with “∗” (reserved), or an unimplemented “σ” (EJTAG), assuming that access to coprocessor 0 is allowed. If access to the coprocessor is not allowed, a Coprocessor Unusable Exception occurs instead. • An instruction was executed that specifies a COP1 opcode encoding of the function field that is flagged with “∗” (reserved), “β” (higher-order ISA), or an unimplemented “ε” (ASE), assuming that access to coprocessor 1 is allowed. If access to the coprocessor is not allowed, a Coprocessor Unusable Exception occurs instead. Some implementations of previous ISAs reported this case as a Floating Point Exception, setting the Unimplemented Operation bit in the Cause field of the FCSR register. Cause Register ExcCode Value RI (See Table 8-25 on page 90) Additional State Saved None Entry Vector Used General exception vector (offset 16#180) 5.2.19 Coprocessor Unusable Exception A coprocessor unusable exception occurs if any of the following conditions is true: • A COP0 or Cache instruction was executed while the processor was running in a mode other than Debug Mode or Kernel Mode, and the CU0 bit in the Status register was a zero • A COP1, LWC1, SWC1, LDC1, SDC1 or MOVCI (Special opcode function field encoding) instruction was executed and the CU1 bit in the Status register was a zero. • A COP2, LWC2, SWC2, LDC2, or SDC2 instruction was executed, and the CU2 bit in the Status register was a zero. • A COP3 instruction was executed, and the CU3 bit in the Status register was a zero.44 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 6 GPR Shadow Registers The capability in this chapter is targeted at removing the need to save and restore GPRs on entry to high priority interrupts or exceptions, and to provide specified processor modes with the same capability. This is done by introducing multiple copies of the GPRs, called shadow sets, and allowing privileged software to associate a shadow set with entry to Kernel Mode via an interrupt vector or exception. The normal GPRs are logically considered shadow set zero. The number of GPR shadow sets is implementation dependent and may range from one (the normal GPRs) to an architectural maximum of 16. The highest number actually implemented is indicated by the SRSCtlHSS field. If this field is zero, only the normal GPRs are implemented. 6.1 Introduction to Shadow Sets Shadow sets are new copies of the GPRs that can be substituted for the normal GPRs on entry to Kernel Mode via an interrupt or exception. Once a shadow set is bound to a Kernel Mode entry condition, reference to GPRs work exactly as one would expect, but they are redirected to registers that are dedicated to that condition. Privileged software may need to reference all GPRs in the register file, even specific shadow registers that are not visible in the current mode. The RDPGPR and WRPGPR instructions are used for this purpose. The CSS field of the SRSCtl register provides the number of the current shadow register set, and the PSS field of the SRSCtl register provides the number of the previous shadow register set (that which was current before the last exception or interrupt occurred). If the processor is operating in VI interrupt mode, binding of a vectored interrupt to a shadow set is done by writing to the SRSMap register. If the processor is operating in EIC interrupt mode, the binding of the interrupt to a specific shadow set is provided by the external interrupt controller, and is configured in an implementation-dependent way. Binding of an exception or non-vectored interrupt to a shadow set is done by writing to the ESS field of the SRSCtl register. When an exception or interrupt occurs, the value of SRSCtlCSS is copied to SRSCtlPSS, and SRSCtlCSS is set to the value taken from the appropriate source. On an ERET, the value of SRSCtlPSS is copied back into SRSCtlCSS to restore the shadow set of the mode to which control returns. More precisely, the rules for updating the fields in the SRSCtl register on an interrupt or exception are as follows: 1. No field in the SRSCtl register is updated if any of the following conditions is true. In this case, steps 2 and 3 are skipped. • The exception is one that sets StatusERL: NMI or cache error. • The exception causes entry into EJTAG Debug Mode • StatusBEV = 1 • StatusEXL = 1 2. SRSCtlCSS is copied to SRSCtlPSS 3. SRSCtlCSS is updated from one of the following sources: • The appropriate field of the SRSMap register, based on IPL, if the exception is an interrupt, CauseIV = 1, Config3VEIC = 0, and Config3VInt = 1. These are the conditions for a vectored interrupt. • The EICSS field of the SRSCtl register if the exception is an interrupt, CauseIV = 1 and Config3VEIC = 1. These are the conditions for a vectored EIC interrupt. • The ESS field of the SRSCtl register in any other case. This is the condition for a non-interrupt exception, or a non-vectored interrupt.MIPS32™ Architecture For Programmers Volume III, Revision 2.00 47 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 6 GPR Shadow RegistersSimilarly, the rules for updating the fields in the SRSCtl register at the end of an exception or interrupt are as follows: 1. No field in the SRSCtl register is updated if any of the following conditions is true. In this case, step 2 is skipped. • A DERET is executed • An ERET is executed with StatusERL = 1 or StatusBEV = 1 2. SRSCtlPSS is copied to SRSCtlCSS These rules have the effect of preserving the SRSCtl register in any case of a nested exception or one which occurs before the processor has been fully initialize (StatusBEV = 1). Privileged software may switch the current shadow set by writing a new value into SRSCtlPSS, loading EPC with a target address, and doing an ERET. 6.2 Support Instructions Table 6-1 Instructions Supporting Shadow Sets Mnemonic Function MIPS64 Only? RDPGPR Read GPR From Previous Shadow Set No WRPGPR Write GPR to Shadow Set No48 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 7 CP0 Hazards 7.1 Introduction Because resources controlled via Coprocessor 0 affect the operation of various pipeline stages of a MIPS32 processor, manipulation of these resources may produce results that are not detectable by subsequent instructions for some number of execution cycles. When no hardware interlock exists between one instruction that causes an effect that is visible to a second instruction, a CP0 hazard exists. In Release 1 of the MIPS32™ Architecture, CP0 hazards were relegated to implementation-dependent cycle-based solutions, primarily based on the SSNOP instruction. Since that time, it has become clear that this is an insufficient and error-prone practice that must be addressed with a firm compact between hardware and software. As such, new instructions have been added to Release 2 of the architecture which act as explicit barriers that eliminate hazards. To the extent that it was possible to do so, the new instructions have been added in such a way that they are backward-compatible with existing MIPS processors. 7.2 Types of Hazards In privileged software, there are two different types of hazards: execution hazards and instruction hazards. Both are defined below. In Table 7-1 and Table 7-2 below, the final column lists the “typical” spacing required in implementations of Release 1 of the Architecture to allow the consumer to eliminate the hazard. The “typical” value shown in these tables represent spacing that is in common use by operating systems today. An implementation of Release 1 of the Architecture which requires less spacing to clear the hazard (including one which has full hardware interlocking) should operate correctly with an operating system which uses this hazard table. An implementation of Release 1 of the Architecture which requires more spacing to clear the hazard incurs the burden of validating kernel code against the new hazard requirements. Note that, for superscalar MIPS implementations, the number of instructions issued per cycle may be greater than one, and thus that the duration of the hazard in instructions may be greater than the duration in cycles. It is for this reason that MIPS32 Release 1 defines the SSNOP instruction to convert instruction issues to cycles in a superscalar design. 7.2.1 Execution Hazards Execution hazards are those created by the execution of one instruction, and seen by the execution of another instruction. Table 7-1 lists execution hazards. Table 7-1 Execution Hazards Producer → Consumer Hazard On “Typical” Spacing (Cycles) TLBWR, TLBWI → TLBP, TLBR TLB entry 3 Load/store using new TLB entry TLB entry 3 MTC0 → Load/store affected by new state EntryHiASID WatchHi WatchLo 3 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 49 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 7 CP0 Hazards52 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 8 Coprocessor 0 Registers The Coprocessor 0 (CP0) registers provide the interface between the ISA and the PRA. Each register is discussed below, with the registers presented in numerical order, first by register number, then by select field number. 8.1 Coprocessor 0 Register Summary Table 8-1 lists the CP0 registers in numerical order. The individual registers are described later in this document. If the compliance level is qualified (e.g., “Required (TLB MMU)”), it applies only if the qualifying condition is true. The Sel column indicates the value to be used in the field of the same name in the MFC0 and MTC0 instructions. Table 8-1 Coprocessor 0 Registers in Numerical Order Register Number Sel1 Register Name Function Reference Compliance Level 0 0 Index Index into the TLB array Section 8.3 onpage 57 Required (TLB MMU); Optional (others) 1 0 Random Randomly generated index into the TLB array Section 8.4 onpage 58 Required (TLB MMU); Optional (others) 2 0 EntryLo0 Low-order portion of the TLB entry foreven-numbered virtual pages Section 8.5 on page 59 Required (TLB MMU); Optional (others) 3 0 EntryLo1 Low-order portion of the TLB entry forodd-numbered virtual pages Section 8.5 on page 59 Required (TLB MMU); Optional (others) 4 0 Context Pointer to page table entry in memory Section 8.6 onpage 63 Required (TLB MMU); Optional (others) 4 1 ContextConfig Context and XContext register configuration SmartMIPS ASE Specification Required (SmartMIPS ASE Only) 5 0 PageMask Control for variable page size in TLB entries Section 8.7 onpage 64 Required (TLB MMU); Optional (others) 5 1 PageGrain Control for small page support Section 8.8 on page 66 and SmartMIPS ASE Specification Required (SmartMIPS ASE); Optional (Release 2) 6 0 Wired Controls the number of fixed (“wired”) TLBentries Section 8.9 on page 68 Required (TLB MMU); Optional (others)MIPS32™ Architecture For Programmers Volume III, Revision 2.00 53 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. Chapter 8 Coprocessor 0 Registers7 0 HWREna Enables access via the RDHWR instruction toselected hardware registers Section 8.10 on page 69 Required (Release 2) 7 1-7 Reserved for future extensions Reserved 8 0 BadVAddr Reports the address for the most recentaddress-related exception Section 8.11 on page 70 Required 9 0 Count Processor cycle count Section 8.12 onpage 71 Required 9 6-7 Available for implementation dependent user Section 8.13 onpage 71 Implementation Dependent 10 0 EntryHi High-order portion of the TLB entry Section 8.14 onpage 72 Required (TLB MMU); Optional (others) 11 0 Compare Timer interrupt control Section 8.15 onpage 74 Required 11 6-7 Available for implementation dependent user Section 8.16 onpage 74 Implementation Dependent 12 0 Status Processor status and control Section 8.17 onpage 75 Required 12 1 IntCtl Interrupt system status and control Section 8.18 onpage 82 Required (Release 2) 12 2 SRSCtl Shadow register set status and control Section 8.19 onpage 84 Required (Release 2) 12 3 SRSMap Shadow set IPL mapping Section 8.20 onpage 86 Required (Release 2 and shadow sets implemented) 13 0 Cause Cause of last general exception Section 8.21 onpage 87 Required 14 0 EPC Program counter at last exception Section 8.22 onpage 91 Required 15 0 PRId Processor identification and revision Section 8.23 onpage 92 Required 15 1 EBase Exception vector base register Section 8.24 onpage 93 Required (Release 2) 16 0 Config Configuration register Section 8.25 onpage 95 Required 16 1 Config1 Configuration register 1 Section 8.26 onpage 97 Required 16 2 Config2 Configuration register 2 Section 8.27 onpage 101 Optional 16 3 Config3 Configuration register 3 Section 8.28 onpage 104 Optional 16 6-7 Available for implementation dependent user Section 8.29 onpage 106 Implementation Dependent Table 8-1 Coprocessor 0 Registers in Numerical Order Register Number Sel1 Register Name Function Reference Compliance Level54 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.3 Index Register (CP0 Register 0, Select 0) MIPS32™ Architecture For Programmers Volume III, Revision 2.00 57 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.3 Index Register (CP0 Register 0, Select 0) Compliance Level: Required for TLB-based MMUs; Optional otherwise. The Index register is a 32-bit read/write register which contains the index used to access the TLB for TLBP, TLBR, and TLBWI instructions. The width of the index field is implementation-dependent as a function of the number of TLB entries that are implemented. The minimum value for TLB-based MMUs is Ceiling(Log2(TLBEntries)). For example, six bits are required for a TLB with 48 entries). The operation of the processor is UNDEFINED if a value greater than or equal to the number of TLB entries is written to the Index register. Figure 8-1 shows the format of the Index register; Table 8-3 describes the Index register fields. Figure 8-1 Index Register Format 31 n n-1 0 P 0 Index Table 8-3 Index Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits P 31 Probe Failure. Hardware writes this bit during execution of the TLBP instruction to indicate whether a TLB match occurred: R Undefined Required 0 30..n Must be written as zero; returns zero on read. 0 0 Reserved Index n-1..0 TLB index. Software writes this field to provide the index to the TLB entry referenced by the TLBR and TLBWI instructions. Hardware writes this field with the index of the matching TLB entry during execution of the TLBP instruction. If the TLBP fails to find a match, the contents of this field are UNPREDICTABLE. R/W Undefined Required Encoding Meaning 0 A match occurred, and the Index field contains the index of the matching entry 1 No match occurred and the Index field is UNPREDICTABLE 58 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.4 Random Register (CP0 Register 1, Select 0) Compliance Level: Required for TLB-based MMUs; Optional otherwise. The Random register is a read-only register whose value is used to index the TLB during a TLBWR instruction. The width of the Random field is calculated in the same manner as that described for the Index register above. The value of the register varies between an upper and lower bound as follow: • A lower bound is set by the number of TLB entries reserved for exclusive use by the operating system (the contents of the Wired register). The entry indexed by the Wired register is the first entry available to be written by a TLB Write Random operation. • An upper bound is set by the total number of TLB entries minus 1. Within the required constraints of the upper and lower bounds, the manner in which the processor selects values for the Random register is implementation-dependent. The processor initializes the Random register to the upper bound on a Reset Exception, and when the Wired register is written. Figure 8-2 shows the format of the Random register; Table 8-4 describes the Random register fields. Figure 8-2 Random Register Format 31 n n-1 0 0 Random Table 8-4 Random Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits 0 31..n Must be written as zero; returns zero on read. 0 0 Reserved Random n-1..0 TLB Random Index R TLB Entries - 1 Required 8.5 EntryLo0, EntryLo1 (CP0 Registers 2 and 3, Select 0)8.5 EntryLo0, EntryLo1 (CP0 Registers 2 and 3, Select 0) Compliance Level: EntryLo0 is Required for a TLB-based MMU; Optional otherwise. Compliance Level: EntryLo1 is Required for a TLB-based MMU; Optional otherwise. The pair of EntryLo registers act as the interface between the TLB and the TLBP, TLBR, TLBWI, and TLBWR instructions. EntryLo0 holds the entries for even pages and EntryLo1 holds the entries for odd pages. Software may determine the value of PABITS by writing all ones to the EntryLo0 or EntryLo1 registers and reading the value back. Bits read as “1” from the PFN field allow software to determine the boundary between the PFNand Fill fields to calculate the value of PABITS. The contents of the EntryLo0 and EntryLo1 registers are not defined after an address error exception and some fields may be modified by hardware during the address error exception sequence. Software writes of the EntryHi register (via MTC0) do not cause the implicit update of address-related fields in the BadVAddr or Context registers. For Release 1 of the Architecture, Figure 8-3 shows the format of the EntryLo0 and EntryLo1 registers; Table 8-5 describes the EntryLo0 and EntryLo1 register fields. For Release 2 of the Architecture, Figure 8-4 shows the format of the EntryLo0 and EntryLo1 registers; Table 8-6 describes the EntryLo0 and EntryLo1 register fields. Figure 8-3 EntryLo0, EntryLo1 Register Format in Release 1 of the Architecture 31 30 29 6 5 3 2 1 0 Fill PFN C D V G Table 8-5 EntryLo0, EntryLo1 Register Field Descriptions in Release 1 of the Architecture Fields Description Read/ Write Reset State ComplianceName Bits Fill 31..30 These bits are ignored on write and return zero on read. The boundaries of this field change as a function of the value of PABITS. See Table 8-7 for more information. R 0 Required PFN 29..6 Page Frame Number. Corresponds to bits PABITS-1..12 of the physical address, where PABITS is the width of the physical address in bits. The boundaries of this field change as a function of the value of PABITS. See Table 8-7 for more information. R/W Undefined Required C 5..3 Coherency attribute of the page. See Table 8-8 below. R/W Undefined Required D 2 “Dirty” bit, indicating that the page is writable. If this bit is a one, stores to the page are permitted. If this bit is a zero, stores to the page cause a TLB Modified exception. Kernel software may use this bit to implement paging algorithms that require knowing which pages have been written. If this bit is always zero when a page is initially mapped, the TLB Modified exception that results on any store to the page can be used to update kernel data structures that indicate that the page was actually written. R/W Undefined Required V 1 Valid bit, indicating that the TLB entry, and thus the virtual page mapping are valid. If this bit is a one, accesses to the page are permitted. If this bit is a zero, accesses to the page cause a TLB Invalid exception. R/W Undefined RequiredMIPS32™ Architecture For Programmers Volume III, Revision 2.00 59 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 5 Available for implementation dependent use Optional 6 Available for implementation dependent use Optional 7 Available for implementation dependent use Optional Table 8-8 Cache Coherency Attributes C(5:3) Value Cache Coherency Attributes With Historical Usage Compliance62 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.6 Context Register (CP0 Register 4, Select 0) MIPS32™ Architecture For Programmers Volume III, Revision 2.00 63 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.6 Context Register (CP0 Register 4, Select 0) Compliance Level: Required for TLB-based MMUs; Optional otherwise. The Context register is a read/write register containing a pointer to an entry in the page table entry (PTE) array. This array is an operating system data structure that stores virtual-to-physical translations. During a TLB miss, the operating system loads the TLB with the missing translation from the PTE array. The Context register duplicates some of the information provided in the BadVAddr register, but is organized in such a way that the operating system can directly reference a 16-byte structure in memory that describes the mapping. A TLB exception (TLB Refill, TLB Invalid, or TLB Modified) causes bits VA31..13 of the virtual address to be written into the BadVPN2 field of the Context register. The PTEBase field is written and used by the operating system. The BadVPN2 field of the Context register is not defined after an address error exception and this field may be modified by hardware during the address error exception sequence. Figure 8-5 shows the format of the Context Register; Table 8-9 describes the Context register fields. Figure 8-5 Context Register Format 31 23 22 4 3 0 PTEBase BadVPN2 0 Table 8-9 Context Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits PTEBase 31..23 This field is for use by the operating system and is normally written with a value that allows the operating system to use the Context Register as a pointer into the current PTE array in memory. R/W Undefined Required BadVPN2 22..4 This field is written by hardware on a TLB exception. It contains bits VA31..13 of the virtual address that caused the exception. R Undefined Required 0 3..0 Must be written as zero; returns zero on read. 0 0 Reserved 8.7 PageMask Register (CP0 Register 5, Select 0) Compliance Level: Required for TLB-based MMUs; Optional otherwise. The PageMask register is a read/write register used for reading from and writing to the TLB. It holds a comparison mask that sets the variable page size for each TLB entry, as shown in Table 8-11. Figure 8-6 shows the format of the PageMask register; Table 8-10 describes the PageMask register fields. Figure 8-6 PageMask Register Format 31 29 28 13 12 11 0 0 Mask MaskX 0 Table 8-10 PageMask Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Mask 28..13 The Mask field is a bit mask in which a “1” bit indicates that the corresponding bit of the virtual address should not participate in the TLB match. R/W Undefined Required MaskX 12..11 In Release 2 of the Architecture, the MaskX field is an extension to the Mask field to support 1KB pages with definition and action analogous to that of the Mask field, defined above. If 1KB pages are enabled (Config3SP = 1 and PageGrainESP = 1), these bits are writable and readable, and their values are copied to and from the TLB entry on a TLB write or read, respectivly. If 1KB pages are not enabled (Config3SP = 0 or PageGrainESP = 0), these bits are not writable, return zero on read, and the effect on the TLB entry on a write is as if they were written with the value 2#11. In Release 1 of the Architecture, these bits must be written as zero, return zero on read, and have no effect on the virtual address translation. R/W 0 (See Description) Required (Release 2) 0 31..29,10..0 Ignored on write; returns zero on read. R 0 Required Table 8-11 Values for the Mask and MaskX1 Fields of the PageMask Register Page Size Bit 28 27 26 25 24 23 22 21 20 19 18 17 16 15 14 13 121 111 1 KByte 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 4 KBytes 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 16 KBytes 0 0 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 64 KBytes 0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 256 KBytes 0 0 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 MByte 0 0 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 4 MByte 0 0 0 0 0 0 1 1 1 1 1 1 1 1 1 1 1 164 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.8 PageGrain Register (CP0 Register 5, Select 1)Programming Note: In implementations of Release 2 of the Architecture, the following fields must be written with the specified values, and the TLB must be flushed before each instance in which the value of the PageGrain register is changed. This oper- ation must be carried out while running in an unmapped address space. The operation of the processor is UNDE- FINED if this sequence is not done. Note also that if PageGrain is changed, a hazard may be created between the instruction that writes PageGrain and a subsequent CACHE instruction. This hazard must be cleared using the EHB instruction. Field Required Value EntryLo0PFN, EntryLo1PFN 0 EntryLo0PFNX, EntryLo1PFNX 0 PageMaskMaskX 2#11 EntryHiVPN2X 0MIPS32™ Architecture For Programmers Volume III, Revision 2.00 67 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 68 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.9 Wired Register (CP0 Register 6, Select 0) Compliance Level: Required for TLB-based MMUs; Optional otherwise. The Wired register is a read/write register that specifies the boundary between the wired and random entries in the TLB as shown in Figure 8-8. The width of the Wired field is calculated in the same manner as that described for the Index register. Wired entries are fixed, non-replaceable entries which are not overwritten by a TLBWR instruction.Wired entries can be overwritten by a TLBWI instruction. The Wired register is set to zero by a Reset Exception. Writing the Wired register causes the Random register to reset to its upper bound. The operation of the processor is UNDEFINED if a value greater than or equal to the number of TLB entries is written to the Wired register. Figure 8-8 shows the format of the Wired register; Table 8-13 describes the Wired register fields. Figure 8-9 Wired Register Format 31 n n-1 0 0 Wired Table 8-13 Wired Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits 0 31..n Must be written as zero; returns zero on read. 0 0 Reserved Wired n-1..0 TLB wired boundary R/W 0 Required R an do m W ir ed Entry 0 Entry 1010Wired Register Figure 8-8 Wired And Random Entries In The TLB Entry TLBSize-1 8.10 HWREna Register (CP0 Register 7, Select 0) MIPS32™ Architecture For Programmers Volume III, Revision 2.00 69 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.10 HWREna Register (CP0 Register 7, Select 0) Compliance Level: Required (Release 2). The HWREna register contains a bit mask that determines which hardware registers are accessible via the RDHWR instruction. Figure 8-10 shows the format of the HWREna Register; Table 8-14 describes the HWREna register fields. Privileged software may determine which of the hardware registers are accessible by the RDHWR instruction. In doing so, a register may be virtualized at the cost of handling a Reserved Instruction Exception, interpreting the instruction, and returning the virtualized value. For example, if it is not desirable to provide direct access to the Count register, access to that register may be individually disabled and the return value can be virtualized by the operating system. Figure 8-10 HWREna Register Format 31 4 3 0 0 0000 0000 0000 0000 0000 0000 0000 Mask Table 8-14 HWREna Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits 0 31..4 Must be written with zero; returns zero on read 0 0 Reserved Mask 3..0 Each bit in this field enables access by the RDHWR instruction to a particular hardware register (which may not be an actual register). If bit ‘n’ in this field is a 1, access is enabled to hardware register ‘n’. If bit ‘n’ of this field is a 0, access is disabled. See the RDHWR instruction for a list of valid hardware registers. R/W 0 Required 8.14 EntryHi Register (CP0 Register 10, Select 0) Compliance Level: Required for TLB-based MMU; Optional otherwise. The EntryHi register contains the virtual address match information used for TLB read, write, and access operations. A TLB exception (TLB Refill, TLB Invalid, or TLB Modified) causes bits VA31..13 of the virtual address to be written into the VPN2 field of the EntryHi register. An implementation of Release 2 of the Architecture which supports 1KB pages also writes VA12..11 into the VPN2X field of the EntryHi register. A TLBR instruction writes the EntryHi register with the corresponding fields from the selected TLB entry. The ASID field is written by software with the current address space identifier value and is used during the TLB comparison process to determine TLB match. Because the ASID field is overwritten by a TLBR instruction, software must save and restore the value of ASID around use of the TLBR. This is especially important in TLB Invalid and TLB Modified exceptions, and in other memory management software. The VPNX2 and VPN2 fields of the EntryHi register are not defined after an address error exception and these fields may be modified by hardware during the address error exception sequence.Software writes of the EntryHi register (via MTC0) do not cause the implicit write of address-related fields in the BadVAddr,Context registers. Figure 8-13 shows the format of the EntryHi register; Table 8-17 describes the EntryHi register fields. Programming Note: In implementations of Release 2 of the Architecture, the VPN2X field of the EntryHi register must be written with zero and the TLB must be flushed before each instance in which the value of the PageGrain register is changed. This Figure 8-13 EntryHi Register Format 31 13 12 11 10 8 7 0 VPN2 VPN2X 0 ASID Table 8-17 EntryHi Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits VPN2 31..13 VA31..13 of the virtual address (virtual page number / 2). This field is written by hardware on a TLB exception or on a TLB read, and is written by software before a TLB write. R/W Undefined Required VPN2X 12..11 In Release 2 of the Architecture, the VPN2X field is an extension to the VPN2 field to support 1KB pages. These bits are not writable by either hardware or software unless Config3SP = 1 and PageGrainESP = 1. If enabled for write, this field contains VA12..11 of the virtual address and is written by hardware on a TLB exception or on a TLB read, and is by software before a TLB write. If writes are not enabled, and in implementations of Release 1 of the Architecture, this field must be written with zero and returns zeros on read. R/W 0 Required (Release 2 and 1KB Page Support) 0 10..8 Must be written as zero; returns zero on read. 0 0 Reserved ASID 7..0 Address space identifier. This field is written by hardware on a TLB read and by software to establish the current ASID value for TLB write and against which TLB references match each entry’s TLB ASID field. R/W Undefined Required(TLB MMU)72 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.14 EntryHi Register (CP0 Register 10, Select 0)operation must be carried out while running in an unmapped address space. The operation of the processor is UNDE- FINED if this sequence is not done.MIPS32™ Architecture For Programmers Volume III, Revision 2.00 73 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 74 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.15 Compare Register (CP0 Register 11, Select 0) Compliance Level: Required. The Compare register acts in conjunction with the Count register to implement a timer and timer interrupt function. The Compare register maintains a stable value and does not change on its own. When the value of the Count register equals the value of the Compare register, an interrupt request is combined in an implementation-dependent way with hardware interrupt 5 to set interrupt bit IP(7) in the Cause register. This causes an interrupt as soon as the interrupt is enabled. For diagnostic purposes, the Compare register is a read/write register. In normal use however, the Compare register is write-only. Writing a value to the Compare register, as a side effect, clears the timer interrupt. Figure 8-14 shows the format of the Compare register; Table 8-18 describes the Compare register fields. 8.16 Reserved for Implementations (CP0 Register 11, Selects 6 and 7) Compliance Level: Optional: Implementation Dependent. CP0 register 11, Selects 6 and 7 are reserved for implementation dependent use and are not defined by the architecture. Figure 8-14 Compare Register Format 31 0 Compare Table 8-18 Compare Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Compare 31..0 Interval count compare value R/W Undefined Required 8.17 Status Register (CP Register 12, Select 0)BEV 22 Controls the location of exception vectors: See Section Section 5.2.1, "Exception Vector Locations" on page 32 for details. R/W 1 Required TS 21 Indicates that the TLB has detected a match on multiple entries. It is implementation dependent whether this detection occurs at all, on a write to the TLB, or an access to the TLB. In Release 2 of the Architecture, multiple TLB matches may only be reported on a TLB write. When such a detection occurs, the processor initiates a machine check exception and sets this bit. It is implementation dependent whether this condition can be corrected by software. If the condition can be corrected, this bit should be cleared by software before resuming normal operation. See Section 4.9.3 on page 17 for a discusssion of software TLB initialization used to avoid a machine check exeception during processor initialization. If this bit is not implemented, it must be ignored on write and read as zero. Software should not write a 1 to this bit when its value is a 0, thereby causing a 0-to-1 transition. If such a transition is caused by software, it is UNPREDICTABLE whether hardware ignores the write, accepts the write with no side effects, or accepts the write and initiates a machine check exception. R/W 0 Required if TLB Shutdown is implemented SR 20 Indicates that the entry through the reset exception vector was due to a Soft Reset: If this bit is not implemented, it must be ignored on write and read as zero. Software should not write a 1 to this bit when its value is a 0, thereby causing a 0-to-1 transition. If such a transition is caused by software, it is UNPREDICTABLE whether hardware ignores or accepts the write. R/W 1 for Soft Reset; 0 otherwise Required if Soft Reset is implemented Table 8-19 Status Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Encoding Meaning 0 Normal 1 Bootstrap Encoding Meaning 0 Not Soft Reset (NMI or Reset) 1 Soft ResetMIPS32™ Architecture For Programmers Volume III, Revision 2.00 77 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. NMI 19 Indicates that the entry through the reset exception vector was due to an NMI exception: If this bit is not implemented, it must be ignored on write and read as zero. Software should not write a 1 to this bit when its value is a 0, thereby causing a 0-to-1 transition. If such a transition is caused by software, it is UNPREDICTABLE whether hardware ignores or accepts the write. R/W 1 for NMI; 0otherwise Required if NMI is implemented 0 18 Must be written as zero; returns zero on read. 0 0 Reserved Impl 17..16 These bits are implementation dependent and are not defined by the architecture. If they are not implemented, they must be ignored on write and read as zero. Undefined Optional IM7..IM2 15..10 Interrupt Mask: Controls the enabling of each of the hardware interrupts. Refer to Section Section 5.1, "Interrupts" on page 23 for a complete discussion of enabled interrupts. In implementations of Release 2 of the Architecture in which EIC interrupt mode is enabled (Config3VEIC = 1), these bits take on a different meaning and are interpreted as the IPL field, described below. R/W Undefined Required IPL 15..10 Interrupt Priority Level. In implementations of Release 2 of the Architecture in which EIC interrupt mode is enabled (Config3VEIC = 1), this field is the encoded (0..63) value of the current IPL. An interrupt will be signaled only if the requested IPL is higher than this value. If EIC interrupt mode is not enabled (Config3VEIC = 0), these bits take on a different meaning and are interpreted as the IM7..IM2 bits, described above. R/W Undefined Optional (Release 2 and EIC interrupt mode only) Table 8-19 Status Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Encoding Meaning 0 Not NMI (Soft Reset or Reset) 1 NMI Encoding Meaning 0 Interrupt request disabled 1 Interrupt request enabled78 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.17 Status Register (CP Register 12, Select 0)IM1..IM0 9..8 Interrupt Mask: Controls the enabling of each of the software interrupts. Refer to Section Section 5.1, "Interrupts" on page 23 for a complete discussion of enabled interrupts. In implementations of Release 2 of the Architecture in which EIC interrupt mode is enabled (Config3VEIC = 1), these bits are writable, but have no effect on the interrupt system. R/W Undefined Required KX 7 Enables access to 64-bit kernel address space on 64-bit MIPS processors. Not used by MIPS32 processors. This bit must be ignored on write and read as zero. R 0 Reserved SX 6 Enables access to 64-bit supervisor address space on 64-bit MIPS processors. Not used by MIPS32 processors. This bit must be ignored on write and read as zero. R 0 Reserved UX 5 Enables access to 64-bit user address space on 64-bit MIPS processors Not used by MIPS32 processors. This bit must be ignored on write and read as zero. R 0 Reserved KSU 4..3 If Supervisor Mode is implemented, the encoding of this field denotes the base operating mode of the processor. See Chapter 3, “MIPS32 Operating Modes,” on page 9 for a full discussion of operating modes. The encoding of this field is: Note: This field overlaps the UM and R0 fields, described below. R/W Undefined Required if Supervisor Mode is implemented; Optional otherwise Table 8-19 Status Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Encoding Meaning 0 Interrupt request disabled 1 Interrupt request enabled Encoding Meaning 2#00 Base mode is Kernel Mode 2#01 Base mode is Supervisor Mode 2#10 Base mode is User Mode 2#11 Reserved. The operation of the processor is UNDEFINED if this value is written to the KSU fieldMIPS32™ Architecture For Programmers Volume III, Revision 2.00 79 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.18 IntCtl Register (CP0 Register 12, Select 1) Compliance Level: Required (Release 2). The IntCtl register controls the expanded interrupt capability added in Release 2 of the Architecture, including vectored interrupts and support for an external interrupt controller. This register does not exist in implementations of Release 1 of the Architecture. Figure 8-16 shows the format of the IntCtl register; Table 8-20 describes the IntCtl register fields. Figure 8-16 IntCtl Register Format 31 29 28 26 25 10 9 5 4 0 IPTI IPPCI 000 0000 0000 0000 00 VS 0 Table 8-20 IntCtl Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits IPTI 31..29 For Interrupt Compatibility and Vectored Interrupt modes, this field specifies the IP number to which the Timer Interrupt request is merged, and allows software to determine whether to consider CauseTI for a potential interrupt. The value of this field is UNPREDICTABLE if External Interrupt Controller Mode is both implemented and enabled. The external interrupt controller is expected to provide this information for that interrupt mode. R Preset or Externally Set Required Encoding IP bit Hardware Interrupt Source 2 2 HW0 3 3 HW1 4 4 HW2 5 5 HW3 6 6 HW4 7 7 HW582 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.18 IntCtl Register (CP0 Register 12, Select 1)IPPCI 28..26 For Interrupt Compatibility and Vectored Interrupt modes, this field specifies the IP number to which the Performance Counter Interrupt request is merged, and allows software to determine whether to consider CausePCI for a potential interrupt. The value of this field is UNPREDICTABLE if External Interrupt Controller Mode is both implemented and enabled. The external interrupt controller is expected to provide this information for that interrupt mode. If performance counters are not implemented (Config1PC = 0), this field returns zero on read. R Preset or Externally Set Optional (Performance Counters Implemented) 0 25..10 Must be written as zero; returns zero on read. 0 0 Reserved VS 9..5 Vector Spacing. If vectored interrupts are implemented (as denoted by Config3VInt or Config3VEIC), this field specifies the spacing between vectored interrupts. All other values are reserved. The operation of the processor is UNDEFINED if a reserved value is written to this field. If neither EIC interrupt mode nor VI mode are implemented (Config3VEIC = 0 and Config3VINT = 0), this field is ignored on write and reads as zero. R/W 0 Optional 0 4..0 Must be written as zero; returns zero on read. 0 0 Reserved Table 8-20 IntCtl Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Encoding IP bit Hardware Interrupt Source 2 2 HW0 3 3 HW1 4 4 HW2 5 5 HW3 6 6 HW4 7 7 HW5 Encoding Spacing Between Vectors (hex) Spacing Between Vectors (decimal) 16#00 16#000 0 16#01 16#020 32 16#02 16#040 64 16#04 16#080 128 16#08 16#100 256 16#10 16#200 512MIPS32™ Architecture For Programmers Volume III, Revision 2.00 83 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.19 SRSCtl Register (CP0 Register 12, Select 2) Compliance Level: Required (Release 2). The SRSCtl register controls the operation of GPR shadow sets in the processor. This register does not exist in implementations of the architecture prior to Release 2. Figure 8-17 shows the format of the SRSCtl register; Table 8-21 describes the SRSCtl register fields. Figure 8-17 SRSCtl Register Format 31 30 29 26 25 22 21 18 17 16 15 12 11 10 9 6 5 4 3 0 0 00 HSS 0 00 00 EICSS 0 00 ESS 0 00 PSS 0 00 CSS Table 8-21 SRSCtl Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits 0 31..30 Must be written as zeros; returns zero on read. 0 0 Reserved HSS 29..26 Highest Shadow Set. This field contains the highest shadow set number that is implemented by this processor. A value of zero in this field indicates that only the normal GPRs are implemented. The value in this field also represents the highest value that can be written to the ESS, EICSS, PSS, and CSS fields of this register, or to any of the fields of the SRSMap register. The operation of the processor is UNDEFINED if a value larger than the one in this field is written to any of these other values. R Preset Required 0 25..22 Must be written as zeros; returns zero on read. 0 0 Reserved EICSS 21..18 EIC interrupt mode shadow set. If Config3VEIC is 1 (EIC interrupt mode is enabled), this field is loaded from the external interrupt controller for each interrupt request and is used in place of the SRSMap register to select the current shadow set for the interrupt. See Section 5.1.1.3, "External Interrupt Controller Mode" on page 29 for a discussion of EIC interrupt mode. If Config3VEIC is 0, this field must be written as zero, and returns zero on read. R Undefined Required (EIC interrupt mode only) 0 17..16 Must be written as zeros; returns zero on read. 0 0 Reserved ESS 15..12 Exception Shadow Set. This field specifies the shadow set to use on entry to Kernel Mode caused by any exception other than a vectored interrupt. The operation of the processor is UNDEFINED if software writes a value into this field that is greater than the value in the HSS field. R/W 0 Required 0 11..10 Must be written as zeros; returns zero on read. 0 0 Reserved84 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.21 Cause Register (CP0 Register 13, Select 0)8.21 Cause Register (CP0 Register 13, Select 0) Compliance Level: Required. The Cause register primarily describes the cause of the most recent exception. In addition, fields also control software interrupt requests and the vector through which interrupts are dispatched. With the exception of the IP1..0, DC, IV, and WP fields, all fields in the Cause register are read-only. Release 2 of the Architecture added optional support for an External Interrupt Controller (EIC) interrupt mode, in which IP7..2 are interpreted as the Requested Interrupt Priority Level (RIPL). Figure 8-19 shows the format of the Cause register; Table 8-24 describes the Cause register fields. Figure 8-19 Cause Register Format 31 30 29 28 27 26 25 24 23 22 21 16 15 10 9 8 7 6 2 1 0 BD TI CE DC PCI 0 IV WP 0 IP7..IP2 IP1..IP0 0 Exc Code 0 RIPL Table 8-24 Cause Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits BD 31 Indicates whether the last exception taken occurred in a branch delay slot: The processor updates BD only if StatusEXL was zero when the exception occurred. R Undefined Required TI 30 Timer Interrupt. In an implementation of Release 2 of the Architecture, this bit denotes whether a timer interrupt is pending (analogous to the IP bits for other interrupt types): In an implementation of Release 1 of the Architecture, this bit must be written as zero and returns zero on read. R Undefined Required(Release 2) CE 29..28 Coprocessor unit number referenced when a Coprocessor Unusable exception is taken. This field is loaded by hardware on every exception, but is UNPREDICTABLE for all exceptions except for Coprocessor Unusable. R Undefined Required Encoding Meaning 0 Not in delay slot 1 In delay slot Encoding Meaning 0 No timer interrupt is pending 1 Timer interrupt is pendingMIPS32™ Architecture For Programmers Volume III, Revision 2.00 87 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. DC 27 Disable Count register. In some power-sensitive applications, the Count register is not used but may still be the source of some noticeable power dissipation. This bit allows the Count register to be stopped in such situations. In an implementation of Release 1 of the Architecture, this bit must be written as zero, and returns zero on read. R/W 0 Required(Release 2) PCI 26 Performance Counter Interrupt. In an implementation of Release 2 of the Architecture, this bit denotes whether a performance counter interrupt is pending (analogous to the IP bits for other interrupt types): In an implementation of Release 1 of the Architecture, or if performance counters are not implemented (Config1PC = 0), this bit must be written as zero and returns zero on read. R Undefined Required (Release 2 and performance counters implemented) IV 23 Indicates whether an interrupt exception uses the general exception vector or a special interrupt vector: In implementations of Release 2 of the architecture, if the CauseIV is 1 and StatusBEV is 0, the special interrupt vector represents the base of the vectored interrupt table. R/W Undefined Required WP 22 Indicates that a watch exception was deferred because StatusEXL or StatusERL were a one at the time the watch exception was detected. This bit both indicates that the watch exception was deferred, and causes the exception to be initiated once StatusEXL and StatusERL are both zero. As such, software must clear this bit as part of the watch exception handler to prevent a watch exception loop. Software should not write a 1 to this bit when its value is a 0, thereby causing a 0-to-1 transition. If such a transition is caused by software, it is UNPREDICTABLE whether hardware ignores the write, accepts the write with no side effects, or accepts the write and initiates a watch exception once StatusEXL and StatusERL are both zero. If watch registers are not implemented, this bit must be ignored on write and read as zero. R/W Undefined Required if watch registers are implemented Table 8-24 Cause Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Encoding Meaning 0 Enable counting of Count register 1 Disable counting of Count register Encoding Meaning 0 No timer interrupt is pending 1 Timer interrupt is pending Encoding Meaning 0 Use the general exception vector (16#180) 1 Use the special interrupt vector (16#200)88 MIPS32™ Architecture For Programmers Volume III, Revision 2.00 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved. 8.21 Cause Register (CP0 Register 13, Select 0)IP7..IP2 15..10 Indicates an interrupt is pending: In implementations of Release 1 of the Architecture, timer and performance counter interrupts are combined in an implementation-dependent way with hardware interrupt 5. In implementations of Release 2 of the Architecture in which EIC interrupt mode is not enabled (Config3VEIC = 0), timer and performance counter interrupts are combined in an implementation-dependent way with any hardware interrupt. If EIC interrupt mode is enabled (Config3VEIC = 1), these bits take on a different meaning and are interpreted as the RIPL field, described below. R Undefined Required RIPL 15..10 Requested Interrupt Priority Level. In implementations of Release 2 of the Architecture in which EIC interrupt mode is enabled (Config3VEIC = 1), this field is the encoded (0..63) value of the requested interrupt. A value of zero indicates that no interrupt is requested. If EIC interrupt mode is not enabled (Config3VEIC = 0), these bits take on a different meaning and are interpreted as the IP7..IP2 bits, described above. R Undefined Optional (Release 2 and EIC interrupt mode only) IP1..IP0 9..8 Controls the request for software interrupts: An implementation of Release 2 of the Architecture which also implements EIC interrupt mode exports these bits to the external interrupt controller for prioritization with other interrupt sources. R/W Undefined Required ExcCode 6..2 Exception code - see Table 8-25 R Undefined Required 0 25..24, 21..16, 7, 1..0 Must be written as zero; returns zero on read. 0 0 Reserved Table 8-24 Cause Register Field Descriptions Fields Description Read/ Write Reset State ComplianceName Bits Bit Name Meaning 15 IP7 Hardware interrupt 5 14 IP6 Hardware interrupt 4 13 IP5 Hardware interrupt 3 12 IP4 Hardware interrupt 2 11 IP3 Hardware interrupt 1 10 IP2 Hardware interrupt 0 Bit Name Meaning 9 IP1 Request software interrupt 1 8 IP0 Request software interrupt 0MIPS32™ Architecture For Programmers Volume III, Revision 2.00 89 Copyright © 2001-2003 MIPS Technologies Inc. All rights reserved.