please solve 12 13 14 Operands In the Ch 2 lecture notes we

please solve 12, 13, 14

Operands In the Ch. 2 lecture notes, we discussed three different locations where the operands of an instruction may be found. What are the three locations? In MIPS assembler, if a function returns an integer value, which register should the return value be placed in? Which register is dedicated to the assembler so it may use this register when implementing pseudo instructions? In a MIPS32 system, suppose a 4-byte signed integer variable named x is allocated in memory at 0 times 1001_4822? Would there be any issues with this scenario? In a MIPS32 system, suppose a 4-byte signed integer variable named x with value 0 times AABBCCDD is allocated in memory at 0 times 1001_0000? The system is big-endian. Draw a memory diagram showing the four bytes of x stored in memory and clearly label the addresses of each byte of x.

Solution

2.1.1 Historical Perspective The MIPS® Instruction Set Architecture (ISA) has evolved over time from the original MIPS I™ ISA, through the MIPS V™ ISA, to the current MIPS32™ and MIPS64™ Architectures. As the ISA evolved, all extensions have been backward compatible with previous versions of the ISA. In the MIPS III™ level of the ISA, 64-bit integers and addresses were added to the instruction set. The MIPS IV™ and MIPS V™ levels of the ISA added improved floating point operations, as well as a set of instructions intended to improve the efficiency of generated code and of data movement. Because of the strict backward-compatible requirement of the ISA, such changes were unavailable to 32-bit implementations of the ISA which were, by definition, MIPS I™ or MIPS II™ implementations. While the user-mode ISA was always backward compatible, the privileged environment was allowed to change on a per-implementation basis. As a result, the R3000® privileged environment was different from the R4000® privileged environment, and subsequent implementations, while similar to the R4000 privileged environment, included subtle differences. Because the privileged environment was never part of the MIPS ISA, an implementation had the flexibility to make changes to suit that particular implementation. Unfortunately, this required kernel software changes to every operating system or kernel environment on which that implementation was intended to run. Many of the original MIPS implementations were targeted at computer-like applications such as workstations and servers. In recent years MIPS implementations have had significant success in embedded applications. Today, most of the MIPS parts that are shipped go into some sort of embedded application. Such applications tend to have different trade-offs than computer-like applications including a focus on cost of implementation, and performance as a function of cost and power. The MIPS32 and MIPS64 Architectures are intended to address the need for a high-performance but cost-sensitive MIPS instruction set. The MIPS32 Architecture is based on the MIPS II ISA, adding selected instructions from MIPS III, MIPS IV, and MIPS V to improve the efficiency of generated code and of data movement. The MIPS64 Architecture is based on the MIPS V ISA and is backward compatible with the MIPS32 Architecture. Both the MIPS32 and MIPS64 Architectures bring the privileged environment into the Architecture definition to address the needs of operating systems and other kernel software. Both also include provision for adding MIPS Application Specific Extensions (ASEs), User Defined Instructions (UDIs), and custom coprocessors to address the specific needs of particular markets. MIPS32 and MIPS64 Architectures provides a substantial cost/performance advantage over microprocessor implementations based on traditional architectures. This advantage is a result of improvements made in several contiguous disciplines: VLSI process technology, CPU organization, system-level architecture, and operating system and compiler design. 2.2 Architectural Changes Relative to the MIPS I through MIPS V Architectures In addition to the MIPS32 Architecture described in this document set, the following changes were made to the architecture relative to the earlier MIPS RISC Architecture Specification, which describes the MIPS I through MIPS V Architectures. • The MIPS IV ISA added a restriction to the load and store instructions which have natural alignment requirements (all but load and store byte and load and store left and right) in which the base register used by the instruction must 8 MIPS32™ Architecture For Programmers Volume I, Revision 0.95 Chapter 2 The MIPS Architecture: An Introduction also be naturally aligned (the restriction expressed in the MIPS RISC Architecture Specification is that the offset be aligned, but the implication is that the base register is also aligned, and this is more consistent with the indexed load/store instructions which have no offset field). The restriction that the base register be naturally-aligned is eliminated by the MIPS32 Architecture, leaving the restriction that the effective address be naturally-aligned. • Early MIPS implementations required two instructions separating a mflo or mfhi from the next integer multiply or divide operation. This hazard was eliminated in the MIPS IV ISA, although the MIPS RISC Architecture Specification does not clearly explain this fact. The MIPS32 Architecture explicitly eliminates this hazard and requires that the hi and lo registers be fully interlocked in hardware for all integer multiply and divide instructions (including, but not limited to, the madd, maddu, msub, msubu, and mul instructions introduced in this specification). • The Implementation and Programming Notes included in the instruction descriptions for the madd, maddu, msub, msubu, and mul instructions should also be applied to all integer multiply and divide instructions in the MIPS RISC Architecture Specification. 2.2.1 MIPS Instruction Set Architecture (ISA) The MIPS32 and MIPS64 Instruction Set Architectures define a compatible family of 32-bit and 64-bit instructions within the framework of the overall MIPS32 and MIPS64 Architectures. Included in the ISA are all instructions, both privileged and unprivileged, by which the programmer interfaces with the processor. The ISA guarantees object code compatibility for unprivileged and, often, privileged programs executing on any MIPS32 or MIPS64 processor; all instructions in the MIPS64 ISA are backward compatible with those instructions in the MIPS32 ISA. Using conditional compilation or assembly language macros, it is often possible to write privileged programs that run on both MIPS32 and MIPS64 implementations. 2.2.2 MIPS Privileged Resource Architecture (PRA) The MIPS32 and MIPS64 Privileged Resource Architecture defines a set of environments and capabilities on which the ISA operates. The effects of some components of the PRA are visible to unprivileged programs; for instance, the virtual memory layout. Many other components are visible only to privileged programs and the operating system. The PRA provides the mechanisms necessary to manage the resources of the processor: virtual memory, caches, exceptions, user contexts, etc. 2.2.3 MIPS Application Specific Extensions (ASEs) The MIPS32 and MIPS64 Architectures provide support for optional application specific extensions. As optional extensions to the base architecture, the ASEs do not burden every implementation of the architecture with instructions or capability that are not needed in a particular market. An ASE can be used with the appropriate ISA and PRA to meet the needs of a specific application or an entire class of applications. 2.2.4 MIPS User Defined Instructions (UDIs) In addition to support for ASEs as described above, the MIPS32 and MIPS64 Architectures define specific instructions for the use of each implementation. The Special2 instruction function fields and Coprocessor 2 are reserved for capability defined by each implementation. 2.3 Architecture Versus Implementation MIPS32™ Architecture For Programmers Volume I, Revision 0.95 9 2.3 Architecture Versus Implementation When describing the characteristics of MIPS processors, architecture must be distinguished from the hardware implementation of that architecture. • Architecture refers to the instruction set, registers and other state, the exception model, memory management, virtual and physical address layout, and other features that all hardware executes. • Implementation refers to the way in which specific processors apply the architecture. Here are two examples: 1. A floating point unit (FPU) is an optional part of the MIPS32 Architecture. A compatible implementation of the FPU may have different pipeline lengths, different hardware algorithms for performing multiplication or division, etc. 2. Most MIPS processors have caches; however, these caches are not implemented in the same manner in all MIPS processors. Some processors implement physically-indexed, physically tagged caches. Other implement virtually-indexed, physically-tagged caches. Still other processor implement more than one level of cache. The MIPS32 architecture is decoupled from specific hardware implementations, leaving microprocessor designers free to create their own hardware designs within the framework of the architectural definition. 2.4 Relationship between the MIPS32 and MIPS64 Architectures The MIPS Architecture evolved as a compromise between software and hardware resources. The architecture guarantees object-code compatibility for User-Mode programs executed on any MIPS processor. In User Mode MIPS64 processors are backward-compatible with their MIPS32 predecessors. As such, the MIPS32 Architecture is a strict subset of the MIPS64 Architecture. The relationship between the architectures is shown in Figure 2-1. Figure 2-1 Relationship between the MIPS32 and MIPS64 Architectures 2.5 Instructions, Sorted by ISA This section lists the instructions that are a part of the MIPS32 and MIPS64 ISAs. MIPS32 Architecture MIPS64 Architecture High-performance 32-bit Instruction Set Architecture and Privileged Resource Architecture High-performance 64-bit Instruction Set Architecture and Privileged Resource Architecture, fully backward compatible with the 32-bit architecture 10 MIPS32™ Architecture For Programmers Volume I, Revision 0.95 Chapter 2 The MIPS Architecture: An Introduction 2.5.1 List of MIPS32 Instructions Table 2-1 lists of those instructions included in the MIPS32 ISA. 2.5.2 List of MIPS64 Instructions Table 2-2 lists of those instructions introduced in the MIPS64 ISA. Table 2-1 MIPS32 Instructions ABS.D ABS.S ADD ADD.D ADD.S ADDI ADDIU ADDU AND ANDI BC1F BC1FL BC1T BC1TL BC2F BC2FL BC2T BC2TL BEQ BEQL BGEZ BGEZAL BGEZALL BGEZL BGTZ BGTZL BLEZ BLEZL BLTZ BLTZAL BLTZALL BLTZL BNE BNEL BREAK C.cond.D C.cond.S CACHE CEIL.W.D CEIL.W.S CFC1 CFC2 CLO CLZ COP2 CTC1 CTC2 CVT.D.S CVT.D.W CVT.S.D CVT.S.W CVT.W.D CVT.W.S DIV DIV.D DIV.S DIVU ERET FLOOR.W.D FLOOR.W.S J JAL JALR JR LB LBU LDC1 LDC2 LH LHU LL LUI LW LWC1 LWC2 LWL LWR MADD MADDU MFC0 MFC1 MFC2 MFHI MFLO MOV.D MOV.S MOVF MOVF.D MOVF.S MOVN MOVN.D MOVN.S MOVT MOVT.D MOVT.S MOVZ MOVZ.D MOVZ.S MSUB MSUBU MTC0 MTC1 MTC2 MTHI MTLO MUL MUL.D MUL.S MULT MULTU NEG.D NEG.S NOR OR ORI PREF ROUND.W.D ROUND.W.S SB SC SDC1 SDC2 SH SLL SLLV SLT SLTI SLTIU SLTU SQRT.D SQRT.S SRA SRAV SRL SRLV SSNOP SUB SUB.D SUB.S SUBU SW SWC1 SWC2 SWL SWR SYNC SYSCALL TEQ TEQI TGE TGEI TGEIU TGEU TLBP TLBR TLBWI TLBWR TLT TLTI TLTIU TLTU TNE TNEI TRUNC.W.D TRUNC.W.S WAIT XOR XORI Table 2-2 MIPS64 Instructions ABS.PS ADD.PS ALNV.PS C.cond.PS CEIL.L.D CEIL.L.S CVT.D.L CVT.L.D CVT.L.S CVT.PS.S CVT.S.L CVT.S.PL CVT.S.PU DADD DADDI DADDIU DADDU DCLO DDIV DDIVU DLCZ DMFC0 DMFC1 DMFC2 DMTC0 DMTC1 DMTC2 DMULT DMULTU DSLL DSLL32 DSLLV DSRA DSRA32 DSRAV DSRL DSRL32 DSRLV DSUB DSUBU 2.6 Pipeline Architecture MIPS32™ Architecture For Programmers Volume I, Revision 0.95 11 2.6 Pipeline Architecture This section describes the basic pipeline architecture, along with two types of improvements: superpipelines and superscalar pipelines. (Pipelining and multiple issuing are not defined by the ISA, but are implementation dependent.) 2.6.1 Pipeline Stages and Execution Rates MIPS processors all use some variation of a pipeline in their architecture. A pipeline is divided into the following discrete parts, or stages, shown in Figure 2-2: • Fetch • Arithmetic operation • Memory access • Write back Figure 2-2 One-Deep Single-Completion Instruction Pipeline In the example shown in Figure 2-2, each stage takes one processor clock cycle to complete. Thus it takes four clock cycles (ignoring delays or stalls) for the instruction to complete. In this example, the execution rate of the pipeline is one instruction every four clock cycles. Conversely, because only a single execution can be fetched before completion, only one stage is active at any time. FLOOR.L.D FLOOR.L.S LD LDL LDR LDXC1 LLD LUXC1 LWU LWXC1 MADD.D MADD.PS MADD.S MOV.PS MOVF.PS MOVN.PS MOVT.PS MOVZ.PS MSUB.D MSUB.PS MSUB.S MUL.PS NEG.PS NMADD.D NMADD.PS NMADD.S NMSUB.D NMSUB.PS NMSUB.S PLL.PS PLU.PS PREFX PUL.PS PUU.PS RECIP.D RECIP.S ROUND.L.D ROUND.L.S RSQRT.D RSQRT.S SCD SD SDL SDR SDXC1 SUB.PS SUXC1 SWXC1 TRUNC.L.D TRUNC.L.S Table 2-2 MIPS64 Instructions Instruction 1 Fetch ALU Memory Write Cycle 1 Cycle 2 Cycle 3 Cycle 4 Stage 1 Stage 2 Stage 3 Stage 4 Execution Rate Cycle 5 Cycle 6 Cycle 7 Cycle 8 Cycle 3 Instruction 2 Stage 1 Stage 2 Stage 3 Stage 4 Fetch ALU Memory Write Instruction completion 12 MIPS32™ Architecture For Programmers Volume I, Revision 0.95 Chapter 2 The MIPS Architecture: An Introduction 2.6.2 Parallel Pipeline Figure 2-3 illustrates a remedy for the latency (the time it takes to execute an instruction) inherent in the pipeline shown in Figure 2-2. Instead of waiting for an instruction to be completed before the next instruction can be fetched (four clock cycles), a new instruction is fetched each clock cycle. There are four stages to the pipeline so the four instructions can be executed simultaneously, one at each stage of the pipeline. It still takes four clock cycles for the first instruction to be completed; however, in this theoretical example, a new instruction is completed every clock cycle thereafter. Instructions in Figure 2-3 are executed at a rate four times that of the pipeline shown in Figure 2-2. Figure 2-3 Four-Deep Single-Completion Pipeline 2.6.3 Superpipeline Figure 2-4 shows a superpipelined architecture. Each stage is designed to take only a fraction of an external clock cycle—in this case, half a clock. Effectively, each stage is divided into more than one substage. Therefore more than one instruction can be completed each cycle. Figure 2-4 Four-Deep Superpipeline 2.6.4 Superscalar Pipeline A superscalar architecture also allows more than one instruction to be completed each clock cycle. Figure 2-5 shows a four-way, five-stage superscalar pipeline. Cycle 1 Instruction 1 Cycle 2 Cycle 3 Cycle 4 Cycle 5 Cycle 6 Cycle 7 Instruction 2 Instruction 3 Instruction 4 Fetch ALU Memory Write Fetch ALU Memory Write Fetch ALU Memory Write Fetch ALU Memory Write Clock Phase Cycle 1 Cycle 2 Cycle 3 Cycle 4 Cycle 5 Cycle 6 Cycle 7 Cycle 8 1 21 21 2 1 21 2 1 2 1 2 1 2 Fetch ALU Mem Write Fetch ALU Mem Write Fetch ALU Mem Write Fetch ALU Mem Write Fetch ALU Mem Write Fetch ALU Mem Write Fetch ALU Mem Write Fetch ALU Mem Write 2.7 Load/Store Architecture MIPS32™ Architecture For Programmers Volume I, Revision 0.95 13 Figure 2-5 Four-Way Superscalar Pipeline 2.7 Load/Store Architecture Generally, it takes longer to perform operations in memory than it does to perform them in on-chip registers. This is because of the difference in time it takes to access a register (fast) and main memory (slower). To eliminate the longer access time, or latency, of in-memory operations, MIPS processors use a load/store design. The processor has many registers on chip, and all operations are performed on operands held in these processor registers. Main memory is accessed only through load and store instructions. This has several benefits: • Reducing the number of memory accesses, easing memory bandwidth requirements • Simplifying the instruction set • Making it easier for compilers to optimize register allocation 2.8 Programming Model This section describes the following aspects of the programming model: • “CPU Data Formats” • “Coprocessors (CP0-CP3)” • “CPU Registers” • “FPU Data Formats” • “Byte Ordering and Endianness” • “Memory Access Types”