Who else studied with their book called "Computer Architecture" and what are your thoughts on it ?
I enjoyed that it was a simpler read then a lot of the circuits-type of books that are part of a EE/CE curriculum, but I always felt there was this lack of "hard science"/physics in the book.
And perhaps it was just not a topic they felt fit with the vision of what this book is suppose to be, and it likely came to be a better decision to abstract that part away for readability.
I read both Computer Architecture and Computer Organization and Design in college and I really enjoyed them.
I would recommend COaD to any beginner who wants to learn some basic concepts of computer design (and if working with FPGAs why not build one).
CA deals with more advanced concepts but doesn't overwhelm you with math and circuit theory (as you noted) so it's a natural progression (from COaD). I think something more advanced and "hard science" should be part of a post-graduate curriculum
I strongly prefer Computer Organization and Design over their Computer Architecture book. I had to read both while at Berkeley. I've considered picking up the new RISC-V edition of the former but I can't justify spending that kind of money when RISC-V is so similar to MIPS. Could be a fun bit of history if RISC-V ever takes over :-)
I read these two as well. Computer Organization and Design and Computer Architecture on my 2nd and 3rd-level computer architecture courses respectively. Glad to hear Hennessy and Patterson getting the Touring award, always had a good hunch about Computer Architecture despite not knowing as much back then.
I thought it was a great book because it proposed sensible benchmarking strategies and applied them thoroughly. That seems like a good way to determine things like how much better 8-way set associative caching is than 2-way.
It's a long time since I read it, but from my memory that's the kind of thing the book is about. I'm not sure how you'd determine those kinds of things in a more "hard science"/physics fashion.
I think that's because in a full EE/CE program you would have some earlier course that covered that based on a book like Sedra/Smith "Microelectronics" (but disclosure, I was CS so most my EE is self acquired)
When I was in grad school, we used the 4th Edition in the Senior/Masters level computer architecture class. I still have it on my book shelf. I've re-read large chunks of it a number of times in the past 10 years (often inspired by making sure my bases are covered during job interviews).
Given that most of my career has been pretty far removed from the compiler/assembly instructions, much of the content wasn't directly relevant to what I've been doing, but I still find myself using many of the tools that are outlined in the first chapter ("Quantitative Principles of Computer Design") when dealing with performance problems or analysis in high-level-language-world, which happens pretty often.
The only issue is that I am hoarding a bunch of copies of the original Computer Architecture editions as the comparisons between the architectures of the day are quite valuable.
I'm currently using it for my Computer Architecture class(MIPS edition). It's rather unfortunate that I'm just grokking the book for the grades, it's a very good book and explains a lot of concepts quite well. I may not grasp it the first time I read a section, but after going over it, I almost always understand.
We used Computer Organization and Design in college. Great book, did well in the class, felt I had a grasp of the material.
But man, 6 months out and I retained nearly nothing. It's just so esoteric and not very relevant to my every day schoolwork(then) and career(now) that it's slowly seeped out of my brain.
I enjoyed that it was a simpler read then a lot of the circuits-type of books that are part of a EE/CE curriculum, but I always felt there was this lack of "hard science"/physics in the book.
And perhaps it was just not a topic they felt fit with the vision of what this book is suppose to be, and it likely came to be a better decision to abstract that part away for readability.