This book follows more along the lines of the coursework for a computer engineering degree than a computer science degree-- especially at institutions where CS lives under the math or IT department as opposed to the engineering department.
There can be a lot of overlap between the two, particularly on the software side of things, but CS curricula generally completely omit the electrical engineering portions of a CE curriculum, and that's where ECS puts its focus.
Their video course [1] is supposedly based off the book. In the course they state that they are not focused on (nor do they have expertise) in the "electrical engineering" aspect of computer systems.
In the first part of the course they focus on computer "hardware" but only on the logical aspects of it (i.e. logic gates etc.). So it probably is considered part computer engineering (though the second part does focus on software) but I wouldn't say it really overlaps with electrical engineering.
The first half of the book is about digital design, which is part of electrical engineering. They call it "Hardware Land" in the book.
From page 6 (1st ed.): Of course the layers of abstraction don't stop here. Elementary logic gates are built from transistors, using technologies based on solid-state physics and ultimately quantum mechanics. Indeed, this is where the abstractions of the natural world,as studied and formulated by physicists, become the building blocks of the abstractions of the synthetic worlds built and studied by computer scientists.
They actually call it "Hardware." If you look on the left of the thread linked website, you'll see a very nice "Table of contents." In this table of contents, it lists all the topics that the books covers.
HARDWARE
1 Boolean Logic 9
2 Boolean Arithmetic 31
3 Memory 45
4 Machine Language 61
5 Computer Architecture 83
6 Assembler 103
These topics are fundamental to computer science. Boolean algebra is fundamental to computer science. Just because E.E. or C.E. degree courses mention a topic, doesn't mean that topic all of a sudden becomes exclusive to them.
Also, I notice you're using the first edition. May I suggest you look at the second edition, as stated in the title?
> Just because E.E. or C.E. degree courses mention a topic, doesn't mean that topic all of a sudden becomes exclusive to them.
What country did/do you study in?
In the US, a research university intro course offering that's asymptotic to this book will almost certainly be promulgated by the EE side of the house for reasons like satisfying ABET accreditation requirements or EE programs generally being better postured to support lecture/recitation supplemented by a significant hardware lab component. At Stanford, see EE 108; CMU, 18-240; UF, EEL 3701; and so on.
At my undergrad alma mater, it was the only upper division EE course that didn't have a prerequisite. The senior lecturers who alternately steered the course were notorious for baiting would-be freshmen into taking it early as an effective means to cull the herd. What's funny is CS undergrad advisors publish a suggested sequence with a footnote calling this major course out by name with an explicit recommendation that it "be taken either by itself during the summer or with no more than 13 hours/credits during a Fall/Spring semester."
"This second edition has been extensively revised. It has been restructured into two distinct parts—part I, Hardware, and part II, Software—with six projects in each part. All chapters and projects have been rewritten, with an emphasis on separating abstraction from implementation, and many new sections, figures, and examples have been added. Substantial new appendixes offer focused presentation on technical and theoretical topics." From the blurb
Wasn't the first edition also in two parts (hardware then software) and with an emphasis on separating abstraction from implementation? That's how I remember it.
Yes on the first account. Kind of on the second. Each project had you finish in a way that would allow you to put it in a box and take it as an abstraction into the next one. That part worked well.
The part that was hard for me was that the book's language often muddled concept and implementation in the description of the project. This wasn't too much of a problem for myself as I went through this book several years after school. I had been working as a professional programmer for some time then and was used to disambiguating concepts and detail.
I know a lot of people work through this book as an undegrad but I must admit I doubt I would have enjoyed as much had I less experience. I can't speak to how much they've improved this aspect obviously and otherwise I found the book's language unusually clear for a textbook.
I have both a computer engineering education and have read the book. My recollection is that it's good for what it is but omits[0] a heck of a lot of necessary background knowledge to apply the material outside of the limited context of the book. I'm not saying that it's not good, just be aware that it's not the whole picture, so to speak.
[0] or perhaps it would be better to say "has no choice but to omit" or it would be ten times thicker than it is.
Coming from the pure CS side I definitely got this feeling. But the real value it provided me was to demystify a lot of what I was working on top of as a programmer. Not that I believe that working through this book has given me a complete understanding of the stack below where I work. I think a superscalar processor with a fat OS like Linux or Windows on top and several layers of drivers and firmware between is far far away from what this book teaches. But it did help me to stop thinking magically about a lot of what is going on. It's embarrassing to admit I once thought a lot of tools like debuggers and whatnot were doing some hocus pocus I couldn't hope to understand. This book really showed me that everything going on in a computer is capital D designed.
From your first projects in CS you're sitting atop a huge stack of tech. My own education was fairly low level compared to most CS programs. Several assembly languages, C, debugging crash dumps, register watches, etc were all part of my curriculum. Even still there is so much down below where I work it is hard not to think magically. Just being given a toy model of how all this doesn't but might work was extremely helpful. This may be why you might find CS majors more fond of this book than CE or EE.
Just curious what curriculum gave a low level CS education? Did you deliberately choose courses such as Compiler thoery and Operating System? In my school(I'm in first semester but join as a returner as I got a Stat master yrs ago) they are both optional and we can skip many low level courses.
Honestly, it was my school. I went to Digipen Institute of Technology. There are a lot of teachers there who worked for Nintendo which has a very old school dev culture. For example, the Wii U was literally their first console with an actual operating system. There are also a lot of Microsoft folks there who worked in jobs like Xbox dev support which gives one a pretty intense education in tackling low level problems.
These days I work far far away from that level and much of knowledge has atrophied but I often appreciate still understanding the concepts.
Thanks. This does sound very interesting. I wonder if there is any other place that offers a combination of many low level courses as well as game programming ones...Those Nintendo guys must be very cool. Did any of them work in the nes/snes period?
A couple. There was a range of experiences. The majority had been handheld developers building hardware and games for the GBC, GBA and DS.
I don't know specifically of another school that focuses on this. However, one thing I found over my college career and you are probably already aware of is that often, if you make a connection with department faculty and prove yourself ambitions they are accommodating in how they will account credits.
You might consider finding a school with a friendly and flexible faculty and then see if they will allow you to pursue a CS degree replacing some of the CS courses with CE courses. Give your existing degree you would might find a fair amount of latitude since they won't feel they need to babysit your trajectory.
The biggest part they omitted was how flip flops work. They talk about it briefly in a end of unit video, however. They don't really talk about clock cycles in any depth, and their interactions with flip flops, and why they're important.
The course, I think, it better to have left it out. It keeps the first part focused on the combination of elements culminating in a CPU.
And, most of all, it inspires you. After doing the course, I was more than motivated to understand this myself. And it remains the most educational computing course I've ever done.
Logged in to say exactly this. I thought I understand computation after my degree, and this book, while far from perfect, did an incredible job of bringing fundamental computation to life in the readers mind.
I'm looking forward to diving into the second edition and hoping the second half is better than the first edition.
I feel like computer science degrees rarely get into much of the hardware beyond some basic assembly. You might have benefitted from taking some computer engineering courses which cover the topics in this book in much greater detail.
Even some people actually working on compilers still talk about pipeline stalls in a ye olde pentium/RISC sense rather than the out of order monsters we have today.
Interesting my CS degree had a required introductory Computer Engineering course which itself had a pre-req first year course where we learned digital logic (among other stuff).
We didn't go quite as far as this book seems to but definitly got a decent grounding in how computers actually do their thing before it was back to theory.
When you've done that read Ulrich Drepper's piece on memory - it's tough but this is what sets you apart from a cowboy (not so much the section on DRAM pinouts, but the whole thing)
If you are interested you should dig in. The very best thing about this book or at least its previous edition is that it is really really fun. The only other textbook I've enjoyed as much is PG's ANSI Common Lisp.
I had sort of the opposite experience. The book was really fun, but it felt a lot more like I learned how to play some abstracted low-level game. It just didn't do much to actually inform me about how a modern CPU actually works.
I think that is nearly exactly the purpose of this book though. It is not to teach you how modern computers work. That may even be an impossible task (as in I'm not sure any one person could hold all of that in their head at once). But by giving you a version of a computer you can completely understand, you can begin to relate to how various pieces of the technology you work with on a daily basis might work.
For example, the portions on virtual machines do not explicitly show you how the JVM works but they give you an idea for the conerns involved such as managing object lifetimes and whatnot.
That's good to hear. I completed all but the final chapter of this book. I don't have a CS degree. A colleague told me I seemed to know a lot more about computing than his computer science class mates. I do wish I'd at least done data structures and algorithms in uni. Catching up now on coursera. next I want to through the book computer systems a programmers perspective
There can be a lot of overlap between the two, particularly on the software side of things, but CS curricula generally completely omit the electrical engineering portions of a CE curriculum, and that's where ECS puts its focus.