41–50 of 73 posts
While I agree that programmers should understand the fundementals of how a cpu et al works, is this book the best one?
"Microcomputer Structures" is out-of-print, but I recall the small text starting with atomic physics and building up to an introduction of the Von Neumann architecture.
As a freshman at Boston University in the 1980's, I took this mind-expanding course (probably because it was way above my level) with Professor D'Angelo. The final project was building an interface to a single-board computer.
I picked the basics of programming and how computers work with a book called "The Beginner's Computer Handbook - Understanding & Programming The Micro". Actually this book was the reason I became a programmer. I was 8 years old when received it as present on birthday from my dad. I could not find a link to the book, but found this blog post which has also some pictures: http://www.currybet.net/cbet_blog/2004/06/the-b…
ACTUAL REVIEW/SPOILER CONTENT:
So, the book does start pretty slowly. It considers the case of signaling with flashlights. This motivates semaphores (not the concurrency type!), which in turn motivates telegraphs. The telegraph repeater and its automation is used to motivate logic gates. Around here (forget exactly whether it's before or after) the author diverges for a chapter or two into boolean logic and counting mechanisms. Then the idea of storage is brought in, then the idea of state machines. Calculation is brought in, and soon the author has a simple little ALU. The author talks about wiring up an interface for this, and then there is talk about interrupts, operating systems, and also real embodiments of this sort of hardware--6502 or 8086 assembler is introduced and discussed.
The writing is geared such that someone in highschool shouldn't have trouble understanding anything, and there is enough history thrown in with the light style that it isn't a chore to slog through.
WHY THIS BOOK IS NOT A WASTE OF TIME:
So, I've already taken the introductory computer engineering/CS classes during my time at university. I've already read a lot in high school and a lot after college on computers and their architecture. This is not a new subject to me. Why is this still a good read?
Folks, our professions (whether you are a mechanical engineer black-boxing gear trains, a software engineer black-boxing Java/Scala/JVM bytecode, or a Perl hacker black-boxing the very mouth of madness) are all rooted in abstraction. Everything we do, everything we touch, is a slice of a pyramid of (sometimes shaky/leaky/smelly) abstractions.
The great thing about Code isn't what it teaches you about programming (it doesn't cover much other than assembly, if that) or computer engineering (no help soldering or designing ring buses or whatnot) or even mathematics (boolean algebra is pretty straightforward in its presentation); instead, Code focuses on bringing us to a functioning microcomputer from a flashlight in our bedroom, without ever skipping a layer of abstraction.
Even if you already know each slice (in broader detail than presented), seeing the entire journey is at worst enjoyable and at best extremely educational.
So, I picked up this book on a whim from Half-Priced Books about six months ago. I've since loaned it out to a mechanical engineering friend of mine, and he's finished it; I'll be loaning it out again soon--it's one of those books that I consider essential for spreading the good word of CS/EE. ACTUAL REVIEW/SPOILER CONTENT: So, the book does start pretty slowly. It considers the case of signaling with flashlights. Th…
I just thought I'd mention this as well.
As my ME friend (at that time, roommate) was chugging through the book, he'd randomly come up and ask me questions or points of clarification. This culminated one evening during dinner.
He, my other roommate (a Linux sysadmin/applied mathematician), and I (software developer and former ME) were enjoying some Indian food, and the ME began bugging us about interrupts. He couldn't understand quite what they were useful for.
So, over the course of four or so hours, we probed him with questions geared towards increasing his understanding. Something along these lines transpired:
ME:"So, what are interrupts good for?"
SD: "Well, they're good for getting the processor's attention. How would you handle checking if a button is down?"
ME: "I could have processor check a line in."
SA: "And if that check happens to miss the button press?"
ME: "...erm, I could have something else check it, faster."
SD: "And how would you check it?"
ME: "You...could have the switch be controlling a bit of the memory, I guess."
SD: "Congratulations! You've invented memory-mapped I/O!"
SD/SA:
SD: "But you still haven't told us about how to solve interrupts."
ME:
SD: "Let's think about the problem. What you want to do is have the processor poll the button, right?"
ME: "Yes."
SD: "And only do this when it's needed, right?"
ME: "Yep."
SD: "So, what if there was some kind of way of signaling the processor that data was ready?"
ME: "...oh. I guess you could use a pin for that."
SD: "What would that pin do?"
ME: "I think it would have to tell the processor to go handle input."
SD: "And how would that work?"
ME:
ME:
SA: "What happens if I want to go somewhere else to handle my interrupt code?"
ME:
SA: "You've just invented the interrupt trap vector!"
...etc...
So, by the end of the night, with proper questioning we'd gotten him to come up with MMIO, with virtual memory, with paging, and eventually gotten him to consider how to implement concurrency via scheduling and his newly discovered virtual memory mechanism.
It was delightful, and wouldn't have been possible unless he'd been getting the lay of the land from reading Code.
edit: oh god the spacing edit2: processor's, not processors
alright, meh, not convinced. we're all busy people and my bedside book stack is 12 high. compare books like CODE, SICP, and related books discussed below, to books like Beautiful Code, Higher Order Perl, Mythical Man Month, Seven Languages in Seven Weeks, tons of whitepapers. do I really need to read CODE? Seems like a bottom-of-stack book that will never quite make it to the top.
This book (probably) won't do that, but it will give you a more intuitive sense of how the machine actually _works_ at its core. This is not meant to be hands on stuff for someone who's programming at your level of abstraction.
Compared to those books you could clear this one out in a few days, and the benefit/effort ratio is probably actually better, although much less directly applicable.
alright, meh, not convinced. we're all busy people and my bedside book stack is 12 high. compare books like CODE, SICP, and related books discussed below, to books like Beautiful Code, Higher Order Perl, Mythical Man Month, Seven Languages in Seven Weeks, tons of whitepapers. do I really need to read CODE? Seems like a bottom-of-stack book that will never quite make it to the top.
BTW, if you want to buy the kindle version, buy it from O'Reilly instead of Amazon: 5 formats and no-DRM: http://shop.oreilly.com/product/9780735611313.do ($1.83 more though).
edit: It may actually be more of an electrical engineering class, but the CS program here is ABET certified, so it's essentially an engineering degree itself, but this is the kind of thing that any CS graduate should be intimately familiar with.