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

Nomination

[Apathy costs bills]

Nomination for Best Diagram Ever. I really wish my "Introduction to MicroProcessors" had had something like that; instead we were drowned in the whiteboard handwavings of a man with an accent I could hardly understand. Maybe this guy should spin this off into a book, make a killing selling it to Undergrad CS students lost in space...

Re:Nomination

[SomeoneGotMyNick]

I disagree.....

Everybody has a 'level' they need to start at when learning ANYTHING.

More often than not, the starting level offered to someone is a bit higher than their current comprehension level on a given subject. It happens all the time to college freshmen. It doesn't mean they are dumb. They have the capability to learn it. It means that their life experiences and knowledge are incompatible with the method in which the subject material is being presented.

With the assistance of an additional reference level (a bridge to knowledge, if you will), a person can then make 'the connection' to the material being taught. The microprocessor diagram helped me a lot. I learned about microprocessor theory from many books and diagrams. I'll be damned if I'll ever be able to share my knowledge with anyone else because it seemed tough to explain to someone else after I understood how it worked. I've always had a problem with 'dumbing down' anything I needed to explain. People always complain that I talk over their heads when they want an answer to a 'simple' question.

The example given in this article greatly streamlines the concept. Now I can give a quick intro to microprocessors the next time the subject comes up.

This is news how?

[radiumhahn]

Everybody knows computers work because the ONEs and ZEROs are at war with each other...

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

[baywulf]

I've been studying hardware design for a while now and the following course documents from the (former) ARSDigita university are a clear yet consise depiction of what you would learn in a beginnning microprocessor design course.

http://www.aduni.org/courses/how_computers_work/

Re:I concur! Not a joke!

[warpSpeed]

( OS people, real-time people, embedded people, well a lot of people!)

embedded people, are they, like, fetuses?

But seriously (and to stay on topic), I am really excited about hammer too. 64 bit processors for the people! I hope the mobo manufacturs get some nice, commodity products out there so that hammer is a viable chioce for my desktop!

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.