Channels ▼
RSS

Programmer's Bookshelf


SEP90: PROGRAMMER'S BOOKSHELF

Microprocessors From the Programmer's Perspective

Like everyone else, programmers generally prefer high-end machines. Many PC programmers, however, mastered instruction sets, addressing modes, and registers on the 8088 or 68000, never really coming to grips with the ins-and-outs of the fundamentally different, though backward compatible, chips such as the 80386 or 68030. Although they use 80386s, many PC programmers are still 8088 programmers at heart, possessing a surprising ignorance of high-end microprocessor architecture.

Then there are basic questions such as, What is RISC? Are the Intel 80486 and Motorola 68040 RISC chips? What is the architecture of the new IBM System/6000 family or the Sun SPARCstations? and How do you program one of those things?

To address questions like these, Robert Dewar and Matthew Smosna's Microprocessors: A Programmer's View provides a solid introduction to the new chips. As the subtitle indicates, this book is for programmers, not hardware design engineers; there are no descriptions of pins here, but instead, lots of code examples.

After an opening chapter on general issues -- register sets, addressing modes, and instruction formats -- the authors present an in-depth look at the Intel 80386 (three chapters) and Motorola 68030 (two chapters). This is followed by one chapter each on the most important Reduced Instruction Set Computer (RISC) architectures: MIPS, Sun SPARC, Intel i860, IBM (both the ROMP architecture found in the IBM RT, and the RIOS used in the new System/6000 family), and INMOS transputer.

The RISC microprocessors require less explanation than the more conventional Intel or Motorola offerings, simply because the RISC chips really do have a simpler architecture. As Dewar and Smosna point out, one reason for this is that RISC manufacturers started with a clean slate while Intel and Motorola were largely driven by the need for backward compatibility.

Microprocessors also contains a lot of anecdotal material, and reflects a knowledge of the real world that is surprising in a treatise on computer architecture. One section, "A Sad Story," talks about how Intel thinks INT 5 means one thing, how IBM thinks it means another, and how this led to the IBM PCjr not using the Intel 80188 chip. Another story, which comes in the middle of a discussion of the 256-byte instruction cache on the 68020, describes a misaligned loop in Peter Norton's SI benchmarking program for the PC. A brief digression on patent law describes how DEC patented the use of the instruction pointer (IP) as a general register.

A Background in Compilers

Dewar and Smosna are both professors at the NYU Courant Institute of Mathematical Sciences. Between them, they have over 25 years experience working on compilers, including the well-respected Realia COBOL and Alsys Ada for the IBM PC, the SPITBOL compiler, and NYU's SETL language.

Why is a background in compilers useful when writing a book on the new hardware? Because, for better or for worse, most code that is run on high-end processors is generated by compilers. Thus, compiler writers determine to a large extent which features of a microprocessor are used. The fundamental observation that inspired the original RISC research was that only a small subset of the instruction set and addressing modes of most processors is commonly executed. Who better than a compiler writer to tell us which features are important and which ones, however interesting sounding, will never be used.

If an instruction exists and almost no one uses it, can its real estate on the chip be put to better use? For example, it is difficult for a compiler to take advantage of many of the niftier features of the 80386 instruction set. The 80386 has a special three-operand form of the IMUL instruction that can manipulate 64-bit integers, but there is no corresponding C data type for 64-bit integers, so the instruction is hardly ever used -- even in code that needs to manipulate 64-bit integers! (In their wonderfully idiosyncratic style, Dewar and Smosna explain all this with an anecdote involving the typesetting firm owned by one of their brothers-in-law.)

So, just because a microprocessor has an instruction to work with 64-bit integers, it doesn't mean that code that handles 64-bit integers will in fact use the instruction. More likely, existing code will never be changed to take advantage of the new "hardware support" for 64-bit integers.

Furthermore, say the authors, code shouldn't often be changed to use a new feature. "Do not assume that an instruction should be used just because it is there." By way of example they provide an in-depth look at the Intel ENTER and LEAVE instructions.

"Hardware support" for a feature sounds like it should always be better than "doing it in software." Dewar and Smosna present a cogent argument that this ain't necessarily so. Again, the 80386 provides many examples. The authors discuss how "simply" by executing a FAR JMP whose target is a task state segment (TSS), one performs a 386 context switch. Sounds terrific. Why does multitasking software for the 386 ignore this magnificent hardware support, and instead do context switches in software? Because the hardware-supported context switch can easily take 300 clock cycles!

Why RISC?

This entire discussion of complex instructions that hardly anyone uses directly leads into the authors' discussion of RISC. Quoting Dan Prener of IBM, the authors note that RISC is not a reduced set of instructions, but a set of reduced instructions.

The goal of RISC is to execute one instruction per clock cycle. This requires not only simplified instructions, but also optimal use of the processor's instruction pipeline. As Dewar and Smosna explain, while a single instruction may have a latency of five clock cycles, if the instruction fetch, decode, and execution can be broken into five stages that can be overlapped with similar stages for other instructions, then average throughput can equal one instruction per clock cycle.

The key way that RISC reduces the complexity of the instruction set is by introducing a "load/store" architecture. The only instructions that interface with memory are LOAD (read memory-to-register) and STORE (write register-to-memory). All other instructions are register-to-register. This greatly reduces the number of addressing modes, which, in turn, simplifies the processor's instruction decode unit.

But a load/store architecture isn't just aesthetically pleasing. It also provides the opportunity for a potentially large performance boost. Access times for memory will always be slower than clock speeds for microprocessors. Caches only partially deal with this problem. Because a load/store architecture gates all memory access through two instructions, we can boost performance by introducing a new rule: The memory operand to a LOAD is not yet available when the instruction following the LOAD starts executing. With this rule, the processor can start executing that instruction before the read from memory has completed. The only requirement is, of course, that this next instruction not need the result of the LOAD.

What then do we do with the instruction after a LOAD? Many pages in Dewar and Smosna's book are devoted to this topic. Obviously, we can insert a NOP, but then we are back where we started. In fact, a good optimizing compiler can usually reorganize code so that useful things can be done in the slot after a LOAD. But this means that good optimizing compilers are necessary to take advantage of RISC architecture. Rather than try to hide them, RISC exposes hardware features such as the speed difference between processors and memory. RISC programming means mastering the concept of software pipelining. Good compilers are needed so that most programmers will not have to remember that a LOAD from memory is a physical act that actually takes time.

The various RISC architectures explored in this book differ greatly in the extent to which they hide or expose the instruction pipeline. The MIPS chips, for example, based on the Stanford RISC research, rely on software conventions rather than hardware interlocks for handling what is called the "load delay slot." In fact, MIPS originally stood for "Microprocessor without Interlocked Pipeline Stages."

The Intel i860 is even more non-transparent. As explained by Dewar and Smosna, i860 programming looks as though it consists almost entirely of pipeline manipulation. For a good example, look in the index to Dewar and Smosna under "Breadcrumbs," and read the indicated page. (I'm not kidding!)

On the other hand, the RIOS architecture used in the IBM System/6000 sounds a lot easier to deal with. According to Dewar and Smosna, RIOS has an advantage over chips like the i860 that "with just a little knowledge of what is going on -- basically little more than the rule that you should not use results you just computed -- the programmer can write code that compiles in a highly efficient manner, without needing a sophisticated optimizing compiler."

The authors conclude that, "Rather than thinking of RISC as a clearly defined characteristic of microprocessors, it is better to think of RISC a being a term for a collection of design techniques used to improve performance."

Often processor's niftiest features are difficult to take advantage of in a high-level language. Chip underutilization is a major problem in our industry. It is often said that software lags behind hardware. The RISC solution is to design simpler chips. Another solution is to make heavier use of assembly language. Another solution, in the case of the underutilization of the 80386, is to use a DOS extender, so that one is using the machine as something other than a "fast XT."

Dewar and Smosna are wonderfully opinionated. Following their lengthy discussion of the rather baroque protection mechanism on the 80386, the authors forthrightly state, "The previous section is virtually incomprehensible. You probably have to read it several times to understand it, and it is still easy to get the DPLs, CPLs, and RPLs hopelessly mixed up." The title of this section is "Is All This Worthwhile?" A discussion of the insane number of addressing modes on the Motorola 68030 asks, "Had enough of this?" As computer books seem to be becoming more and more homogenized, it was a pleasure to read Microprocessors, a piece of technical writing which maintains the authors' voices from beginning to end.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video