Slashdot Mirror
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."
Athletic Scholarships to universities make as much sense as academic scholarships to sports teams.
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...
Kill Trolls Dead. Here's
And as the author notes, this kind of information is really crucial to get a grip on before Hammer arrives.
Yah, you don't want to be caught without da knowledge when the MC gets back in town to teach these new kids a "lesson".
2 legit 2 quit! Hammer time, yo!! Word!
Dragging people kicking and screaming into reality since 1996.
It is nice to have an appreciation for the underlying mechanisms of the things we use.
As Socrates said, the unexamined life is not worth living.
But as many EE or even ECE people know, most programmers don't give a rats ass about what the hardware is doing. those that do have this understanding ( OS people, real-time people, embedded people, well a lot of people!) have it because they need it.
I'm not arguing that it isn't beneficial to know the difference between SIMD, SISD, MIMD, MISD systems, but if you aren't programming or designing for parallel systems, how will this help you when a new processor comes to market?!
The "Hammer" line is just a fumble for relevance. Guess what? We're reading this on a computer. The relevance is already there!
In the future, I would want to not be isolated from my friends in the Space Station.
Everybody knows computers work because the ONEs and ZEROs are at war with each other...
that my 'puter was powered by a series of little mice on little wheels.
Suppose I'd better stop putting food for them in the coffee cup holder. Who would have thought that the nice man from IT support was right all along
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
build one of these
try { do() || do_not(); } catch (JediException err) { yoda(err); }
This is quite possibly the best "intro to computers" on a high level that I've ever seen, and it even delves into some of the more specifics of CPU operation. Kudos to Ars...
However, I still don't see how this is relevant to Hammer, as the article doesn't even go into detail about different takes on architecture vis a vis Intel and AMD. There's a few links at the end to a discussion of the diffs in the G4e and the P4, but nothing on the AMD side.
[offtopic]
Personally, I'm getting wary of various AMD products. I continually see issues w/ AMD and games (the EQ debacle being one of them), I see general weirdness w/ my software on my Athlon, and it just reminds me of all the hideously weird incompatibilities I've had over the years (some that aren't even regularly reproduceable, maybe it's a bad mobo?), and it makes me recall a discussion w/ some of my friends:
"If you want it to run right, use Intel. Everyone, _everyone_ tests w/ Intel stuff first. From MS (yah, boo, whatever) to id, from nVidia to Creative Labs, everyone tests on Intel _first_."
I'm not trying to bash AMD, it's just that, well, every time I use an AMD system, I end up experiencing weird glitchy errors, that come and go as they please. While my Athlon setup has been orders of magnitude more stable than past AMD systems, it's still not the rock that my P3 was.
[/offtopic]
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.
Stupider like a fox! - H.S.
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.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"