ISADesign:GeneralDesign:B

Copyright 2018, Clinton A Staley

Concepts

1. Relation of hardware to ISA
2. Coprocessors and vector processing
3. Register-memory and CISC architecture

Overview

This segment continues our look at general issues in ISA design. We'll look at how the ISA connects with the hardware, with special focus on coprocessors. We'll also talk about non-RISC ISA design. 1

The Hardware Shows Through

It is interesting to note that certain aspects of the CPU hardware show through in the ISA design. For instance 2, the position of the cond code is the same in all ARM instructions not just for consistency, but because those four bits lead into circuitry that decides whether or not the instruction will be executed. So, the cond bits need to be in the same position in each instruction.

Question 1

What other fields line up consistently in several different instructions, suggesting they they feed into the same hardware circuits?

Answer 1

3The register fields all line up in the instructions, again because those 4-bit values feed directly into circuits that select from the register bank. The same is true for many of the flags, for instance the S flags and L flags (which occupy the same position, but have different purposes in different instruction formats).

Coprocessor instructions

One of the most striking examples of this is the coprocessor instruction formats 4. (Recall we reserved these for discussion in this topic.) These instructions clearly show that the CPU and FPU are separate circuits, even though they both reside on the same silicon chip.

The Coprocessor Data Transfer format 5 includes the fldd and fstd instructions we used in our floating point example to load and store floating point registers to and from memory. Except for the different fixed-bit pattern (110), the first 16 bits of this format 6 are nearly identical to those for ldr/str and ldm/stm, specifying load/store, writeback, up/down offset, and address register. But the last 16 bits are somewhat different 7. The CRd field specifies the target floating point dX register, not a general purpose rX register, and the CPNum specifies the coprocessor number. Fewer bits are left for the offset 8, which is thus quite limited in range.

That coprocessor number field 9 says a lot. It suggests that the coprocessor is a separate entity, and that there may be more than one coprocessor. And note that it's a "coprocessor" number, not an "FPU" number. The ARM ISA is designed to accommodate a variety of possible partner coprocessors 10 doing different types of operations. It's not specific as to exactly what each one does. An FPU is just one possibility.

The Coprocessor Data Operation format 11 includes all the computational instructions like fsubd, faddd, fmuld, etc. It bears some similarity to the Data Processing format in that it has a 4-bit Opcode ("Op1"), plus CRn and Crd registers for the first operand and the target register. But again, it uses 4 bits for a coprocessor number, and drops the operand2 field in favor of a third register CRm (which is the second operand), and a "CP" or "Op2" field (the name differs in different format diagrams). Recall that we could not use floating point constants in floating point operations but instead had to load constants from memory? This is why -- there is no operand2 field.

These instruction formats are meant to work with a variety of different coprocessor types, not just FPUs. The only requirements for a coprocessor are 12:

1. It may have up to 16 registers of its own, which can be loaded/stored via Coprocessor Data Transfer
2. It must have opcodes of its own, specifiable by 4 bits (Op1) with an optional additional 3 bits (CP or Op2) as an extension, the meanings of which depend on the coprocessor.
3. There may be at most 16 coprocessors, since only 4 bits are reserved to number them.

Question 2

Look up the Coprocessor Register Transfer format 13, which we didn't use in the examples. What is its purpose?

Answer 2

It's for transferring between the registers of a coprocessor and those of the main CPU.

This reinforces the point. Transfers from coprocessor registers to main CPU registers require their own special instruction since the registers in question are in completely different areas of the chip.

Coprocessor examples

An FPU is one type of coprocessor. Let's look at a couple more example coprocessors, one an optional "add on", and another that is automatically part of most ARM chips.

Question 3 Look up the Move coprocessor 14 ("ARM Move coprocessor" makes a good search phrase). What is its general purpose? What type of device might have such a coprocessor as part of its ARM chip?

Answer 3

It's specifically designed to perform complex operations related to MPEG and other types of video compression 15. A video camera with an ARM processor would almost certainly include a Move or similar coprocessor.

We've discussed the MMU in past lectures, and we'll look more at it later. MMUs do a number of things related to managing memory segments, and they must be configured by the operating system.

But, what instructions in the ARM ISA address the MMU? How would we write assembly code to configure it? The answer is that the MMU is a coprocessor 16, and the instructions we just discussed are used to manage it. Of course, its opcodes are completely different from those for the FPU or for a Move coprocessor, and the contents of its registers have to do with memory segments, not floating point numbers, but the coprocessor instruction formats work with it just the same.

Question 4

Certain standard coprocessors like the MMU have a reserved coprocessor number. Do a brief online search and find out what coprocessor number is reserved for the MMU.

Answer 4

17It's coprocessor 15.

RISC (load/store) vs CISC (register-memory) architectures.

As mentioned early on in the course, ARM is a load/store ISA: it allows only registers as operands, and requires that values be loaded from memory into a register before computation, and stored back afterward.

There are ISAs that allow operations directly between registers and memory. The Intel processor is an example. This requires instructions large enough to include a memory address along with opcodes, register numbers, etc. so the instructions in such ISAs are often longer than 32 bits. Such ISAs are usually designated CISC 18 (Complex Instruction Set Computer), and their focus is on powerful machine instructions that can do in one operation what takes several instructions on a RISC processor. A related description is register-memory since such CISC ISAs have instructions that allow registers and/or memory locations as operands.

CISC ISAs generally have a variety of instruction lengths, not the fixed 32 bits of the ARM ISA.

Question 5

Briefly look up the Intel machine language. You should find it's quite different from ARM. Don't get into all the instructions (there are a huge number of them). Just answer: what lengths (in bytes) may they have?

Answer 5

19Intel instructions can vary from 1 to 14 bytes in length

Intel's instruction set has multiple possible fields, including register numbers and memory addresses. Not all of them are needed by every instruction. Those not needed are simply omitted entirely, resulting in varying instruction lengths. As a CISC processor, an Intel CPU has instructions that can perform such actions as loading a word from memory and adding it to another word in a register in one instruction 20. (This would take two instructions, a ldr and an add, in an ARM processor.)

But note, the power of CISC instructions comes with the cost of slower execution 21. RISC design focuses on doing smaller steps, very quickly and elegantly, and on highly consistent machine language formats that can be easily pipelined for speed. CISC design focuses on fewer, more powerful instructions, but these are harder to pipeline due to their varying running time and length.

RISC Rulez

Though Intel might be reluctant to admit this, most experts agree that CISC architectures are outdated, and in the 21st century RISC design dominates ISAs (aside, importantly, from Intel's). Indeed, even Intel processors have for several decades had a small RISC processor inside them 22 with an internal RISC instruction set, performing the complex CISC instructions as subroutines. So, perhaps "Intel Inside(tm)", should also be "RISC Inside".

Stack machines

If CISC machines are on one end of the spectrum of instruction complexity, on the other end are stack machines, whose instructions are even simpler than RISC's. We'll discuss those in the next segment.