Understanding the Microprocessor

Citywide writes "Ars has a very thorough technical piece up entitled Understanding the Microprocessor. It's pitched lower than many Ars articles (all of which are a bit over my head, to be honest), but that's why it's worth checking out: it explains the fundamentals is a very clear and useful way. And as the author notes, this kind of information is really crucial to get a grip on before Hammer arrives."

Comments

Re:Nomination

[JonTurner]

Maybe this guy should spin this off into a book,
Too late. Charles Petzold has already done it. See CODE. It should be on every geek's bookshelf.

Re:I concur! Not a joke!

[Sobrique]

SIMD ~= Array processing. Take this bazillion element array and add 1 to each. MIMD ~= current multiprocessing. x processors running x separate bits of code.
MISD is fairly near useless, since it's basically one great big implicit race condition. It's included in the list for completelness only.
(These two processors in parallel, add 1 to this element and multiply it by 2. So do you get 2 (x+1) or do you get (2x + 1))

Re:why?

[oliverthered]

"Basically, Hammer (64 bit cpus) = larger addressing space, not nescessarily faster processing."
I suggest you go read the developer docs for the hammer.

Memory addressing has been re-designed, because no-one uses the protection model in x86. etc....
Do you understand me, or the developer docs, probably not.
now read Understanding the Microprocessor and say that the Hammer isn't an improvement.

Re:Computer Organization and Design

[Anonymous Coward]

Or, for an even more detailed treatment, try Hennessey and Patterson's _Computer Architecture: A Quantitative Approach_.

Re:Here's What I'd like to see

[dohnut]

I think what you would like, although it's a bit dated, would be Understanding Digital Computers. This book takes starts at the gate level and goes through the layout and operation of a simple 8 bit CPU. I got this book when I was 13. When I went to college and took my digital architecture classes I aced them, and even though that was much more difficult I credit my success to having read this book first instead of diving in naked like most students do/did. It's been forever since I've read it, but I still have it on my bookshelf.

Re:Nomination

[ShotgunEd]

Maybe this guy should spin this off into a book, make a killing selling it to Undergrad CS students lost in space...

Computer Organization and Design: The Hardware/Software Interface is the ultimate intro to microprocessors book. It covers instruction sets and architecture extremely well. As the title suggests, it show how (and why) the instruction set and architecture are tied together. (Most of the discussions revolve around MIPS, but they have stuff on Pentiums and PowerPCs, too.) The meat of the book involves actually designing a pipelined, MIPS-like processor from scratch. Really cool stuff - you can actually implement the final design on an FPGA board pretty easily. The final design is, of course, much much much simpler than an actual processor, but it really gives you a sense of what all the components do and how they function together. Anyways, highly recommended...

Computer Organization and Design: The Hardware/Software Interface from Amazon

Just a few problems

[drinkypoo]

First of all, I think it would have been beneficial to examine a really stupid CPU (like the 8086 perhaps) before launching into stuff like SIMD.

Second, the first two instruction types given are arithmetic and load/store. Unfortunately something like half the instructions (or more) in a program are usually arithmetic and branch instructions (conditional jumps in fact.) So those are definitely the things to discuss first, before load/store, if you're going to do it that way. I personally would bring all three types of operation to the front right away and then delve into how they work, but that's a personal decision.

Speaking of branching instructions he describes forward and backward branches. This is silly. There are two kinds of branches, relative (offset) and absolute. You can jump to a location which is +/- however far from your current position, or you can jump to a specific address. Some CPUs only allow one or the other of these. x86 uses both. (A short jump is an 8 bit signed jump, -128/+127 offset from your current location. A near jump is 16 bit. A far jump specifies a segment and offset, because x86 uses a segmented memory model.) So branching forward or backward is only a significant concept (at all - of course the assembler handles this for you) when talking about relative branches.

I thought that this article was going to talk about how it was actually done. Maybe I'm just special (where's my helmet?) but I've got most of this material (in this article) out of previous ars technica articles. The stuff in this comment I'm writing now, on the other hand, is based on a class in x86 assembly, the final for which is on this coming Tuesday. I want to know how the instruction decoder is put together, for example.

If you ignore every other point I've made in this, consider the possibility that it is a big mistake to start talking about heavily pipelined CPUs. It would be best to start with the classic four-stage pipeline (fetch -> decode -> execute -> write) in which an instruction is fetched from memory (via the program counter; In x86 this is coupled with the CS register (code segment) and it is called the instruction pointer (IP or on 32 bit CPUs in 32 bit mode, EIP) and so you load the new instruction from CS:IP. As per my above paragraph a short or near jump updates IP or EIP, a far jump updates CS and [E]IP.

Finally, is it just me or is it amusing that we're supposed to understand this before hammer arrives but every page has a gigantic animated Pentium IV ad? Up yours, ars adsica.

Re:Just a few problems

[drinkypoo]

Is this a troll, or are some people still being taught about x86 segments and offsets?

Probably everyone who takes a class in x86 assembler (I would have preferred 68k but x86 is what was offered here) is learning about segmented addressing. This is because:

1. x86 CPUs still use segmented addressing. It is necessary to cross the 4GB boundary. In addition BIOS executes in real mode so even the most modern x86-based systems do segmented addressing at some point in the boot process.
2. ASM is used for three things. The first is inline assembler for optimization. The second is drivers, where things either have to happen on schedule (one operation MUST follow the prior and be followed by another specific operation.) The third is embedded systems where ALL of the code is sometimes STILL written in assembler, from front to back, typically runs on small x86-based computers running some form of DOS, and is typically 16 bit real mode code.

In addition even in 32 bit mode you still have and use segment registers. Oh, you might never CHANGE them, but they are still there. As the sibling to this comment points out, you can use them for optimization (changing DS and ES to allow your offsets to be the same, or smaller than they otherwise would be) and save a few cycles. The registers are there, and still in use.

Re:Just a few problems

[Hannibal_Ars]

"First of all, I think it would have been beneficial to examine a really stupid CPU (like the 8086 perhaps) before launching into stuff like SIMD."

Did you read the article, or did you just skim it. Nowhere do I launch into a discussion of SIMD. The only reason the term is present is because I used a diagram from a previous article.

"Second, the first two instruction types given are arithmetic and load/store. Unfortunately something like half the instructions (or more) in a program are usually arithmetic and branch instructions (conditional jumps in fact.) So those are definitely the things to discuss first, before load/store, if you're going to do it that way. I personally would bring all three types of operation to the front right away and then delve into how they work, but that's a personal decision. "

Yes, it's "personal decision," and I opted to go a different route. I think the order in which I introduced the concepts works. Other orders, are, of course, possible.

"Speaking of branching instructions he describes forward and backward branches. This is silly. There are two kinds of branches, relative (offset) and absolute. You can jump to a location which is +/- however far from your current position, or you can jump to a specific address."

Once you're done with your little intro to ASM, chief, you might stick around for some more advanced courses. In them, you'll learn that what branch prediction algorthims care about are whether a branch is forward or backward, because this tells you whether or not to assume it's part of a loop condition or not. I won't explain further, though, because a. I've covered the topic in previous articles, and b. I don't like to feed trolls anymore than I have to.

"I thought that this article was going to talk about how it was actually done. Maybe I'm just special (where's my helmet?) but I've got most of this material (in this article) out of previous ars technica articles."

Maybe if you'd have read the intro a little more closely, you'd know that I made it clear that everything in that article was covered in more depth in previous Ars articles. This article was intended as background for those articles.

"If you ignore every other point I've made in this, consider the possibility that it is a big mistake to start talking about heavily pipelined CPUs."

I don't discuss heavily pipelined CPUs, or pipelining in general, in this article. I do refer back to previous articles on the P4, but that's recommended as furthe reading. I'll cover pipelining in a future article (a point that I made clear in the conclusion.) And yes, I know that PC = IP in x86 lingo. Thank you. Now we all know that you know, too. Here's a cookie.

"Finally, is it just me or is it amusing that we're supposed to understand this before hammer arrives but every page has a gigantic animated Pentium IV ad? Up yours, ars adsica. "

I made one reference to Hammer in the intro, along with a reference to Itanium2, Yamhill, etc. Let it go, man. This article doesn't pretend to have much of anything specific to do with AMD.