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: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.

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

[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.