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."
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. :-)
Galileo: "The Earth revolves around the Sun!"
Score: -1 100% Flamebait
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.
Ok, I know that this probably doesnt jive with the majority of people who post here, however I'm not a tech person totally. I have my moments, but over all I'm just not. I'd like to get a better understanding of the inner workings of microprocessors from a laymans perspective... kind of like I'm in 4th grade. I feel like if I had that understanding I would better understand my machine, but this stuff is just too much for me...
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.
Some things, like microprocessor design, simply can't be gleaned without a proper education and then experience working in the field. Even the best undergrad program will only take you to about the pentium II level in design. I had a course where we built (paper design, and simulated of course) a processor that was a PII equivalent.
Anything higher than that... well, go get a job with amd or intel.
-
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.
That was fun, let me tell you.
-
build one of these
try { do() || do_not(); } catch (JediException err) { yoda(err); }
2 definitions found
From Webster's Revised Unabridged Dictionary (1913) [web1913]:
Layman \Lay"man\n.; pl. {Laymen}. [Lay, adj. + man.]
1. One of the people, in distinction from the clergy; one of
the laity; sometimes, a man not belonging to some
particular profession, in distinction from those who do.
From WordNet (r) 1.7 [wn]:
layman
n : someone who is not a clergyman or a professional person
[syn: {layperson}] [ant: {clergyman}]
"If anyone needs me, I'm in the angry dome."
"It's pitched lower than many Ars articles (all of which are a bit over my head, to be honest)"
I used to feel the same way, but now that I have had several courses in this area, I find Ars's usual detail about right. (if they are still too low pitched you can always read the references) If your a person who understands this stuff, but doesn't want to spend the time reading the latest journals and conferences, Ars articles often provide a great way to stay up to date. Although they may not be accessable to some (I've been there). I hope this "lower pitch" doesn't become a trend.
you're using a liquid crystal display to watch Buffy, Dawn, Spike, Xander, Anya, Giles (assuming he's still alive) and Willow as they work to defeat The First (From beneath you, it devours).
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]
we'll never get a grip because "Can't touch this".
Basically, Hammer (64 bit cpus) = larger addressing space, not nescessarily faster processing.
And almost certainly higher cost and higher power consumption.
"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!
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
But if you need it, you shouldn't be reading Slashdot, or at least, not posting stories.
The classic on this subject, is, of course, Von Neumann's First draft report on the EDVAC.
Well... kinda...
I suspect some people do use alternate addressing, since Intel put it in the Xeon -- it has a (slower) 36-bit mode that can address up to 8 GB of virtual memory.
The Hammer has a 48-bit virtual and 40-bit physical addressing -- not 64-bit, although there's a good bit of confusion on this (particularly since AMD's own docs refer to 64-bit addressing in some areas, but refer to the 40/48 bit addressing in others -- I doubt they implemented full 64-bit addressing; it'd be massive overkill for the lifetime of the CPU).
I agree that Hammer is important for much more than address space though.
Hmm... By the looks of things there using a flat model, no CS/DS and a few other bits and bobs, it's not just the addressing that's changed by but the 'way' that you address memory.
This is a small step away from CISC, since the memory access model is becoming simpler, which inturn can give performance improvements.
thank God the internet isn't a human right.
There are 10 kinds of people on this board: those who understand the language of microprocessors and those who don't. As for myself, I fall into the latter category because the darn thing is /.ed already.
Wh47 d1d j00 541, 31337 15n't t3h r0xor5 ne m0r3???
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.'"
I've been using home-built AMD-based PCs since the K6 series. I've run Linux, Windows (various flavors), one or two BSDs and BeOS on them -- with all manners of software. I've never had any issues whatsoever with the processor. I have had issues with dodgy motherboards/chipsets, but never the CPU (e.g., same CPU, different mainboard or new BIOS clears up the problem). I'd look elsewhere for the source of your problems. Heat, specifically, would be a good start. I'd check memory next (a lot of the "weird", or at least intermittent, errors I've seen have had to do with one of the two).
As for the "everyone tests on Intel", well, possibly. But they also probably test on AMD, and it really shouldn't matter much anyway since the two are essentially completely compatible as far as your game is concerned. In addition, I know a lot of people using AMD now in fairly intensive environments (for things like clustering) since you can effectively reduce the cost per cycle in half. I haven't heard them complain of "glitchy errors" or "general weirdness". I imagine when the Hammer line comes out they will be even more popular, especially on the low cost high-end.
-B
Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.
YES I agree. I think the initial point was in reference to the "this is in some way related to the Hammer coming out" comment.
That relation is so tenuous, that you could say "My boss might buy a computer, so I need to read this."
In the future, I would want to not be isolated from my friends in the Space Station.