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.
The only information you'll need to know once Hammer has arrived is that it's the fastest thing on the planet, and the only mass-market 64-bit processor. :-)
Oh yeah, and where to buy one.
Except for us who have to make informed decisions about future upgrade paths and which processors are going to provide the best cost and performance for our specific applications. Sometimes you need to know the specifics of how a processor operates and what it's specific strengths and benefits are before you recommend changing a companies whole server base etc...
Just because I doubt myself does not mean I find your position compelling.
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
If you are in that position,
chances are you don't need, or you could write this article.
Also, if you are a big enough player, you get some sample procs and run some benchmark tests, maybe even write some of your own.
In the future, I would want to not be isolated from my friends in the Space Station.
The DEC Alpha's have been 64 bit for a long time and the Alpha backplane is the fastest in the biz.
Alex
"The Brady Bunch is back...working homicide"
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); }
No one with a clue would ever do this any other way than by buying/borrowing a system for evaluation and running the specific application as a benchmark.
The beauty of Hammer is that doing so will be quite inexpensive compared to other comparable options. :-)
I stand by my original post.
(BTW, my vote for most innovative Hammer feature is the integrated memory controller(s) - memory bandwidth scales with processor count in SMP systems.)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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]
"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.
thank God the internet isn't a human right.
Words bad, hurt Oog head!
Oog simple Caveman, like Hammer. Oog use 64-bit Hammer bash! Oog buy AMD. Oog love AMD!
--
Internet Explorer (n): Another bug -- that is, a feature that can't be turned off -- in Windows.
For a more detailed treament of the topic, take a look at David Patterson's and John Hennessy's _Computer Organization & Design_. It is an excellent text book on the topic.
The microprocessors understand YOU!
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.
You can compress data by removing all zeros, because they don't contain any information anyway. Besides, a "0" is more bulky than a "1" so you'll save more than half of the space.
Escher was the first MC and Giger invented the HR department.
This was definitely worth posting - it's a good, helpful summary. It's the kind of thing that I wish there was more of since I can pass the article on to people who need it.
I'd like to see a series of books on the way computers work, at various levels of knowledge, so people can get the knowledge in bite-sized chunks. It'd be helpful to me, since I often end up being "Mr. Explainer" and I'd LOVE to just hand someone a book and get back to work.
"The Sage treasures Unity and measures all things by it" - Lao Tzu
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.'"