Buy this book if you're a programmer who wants to know how computers work.
I read the first edition in high school, and if I had to choose either this book or my entire undergrad CS education, I'd pick this book.
I read the first edition in high school, and if I had to choose either this book or my entire undergrad CS education, I'd pick this book.
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.
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.
> but CS curricula generally completely omit the electrical engineering portions
Where in this book does it talk about electrical engineering?
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.
8
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?
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."
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.
[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.
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.
These days I work far far away from that level and much of knowledge has atrophied but I often appreciate still understanding the concepts.
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.
I'm looking forward to diving into the second edition and hoping the second half is better than the first edition.
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.
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.
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.