|
|
Hello,
I just wanted to thank the authors so much for such a wonderful book. I work in IT and already had a decent foundation in computer science, however this book shed some light on some concepts I had been hazy on. Specifically, I now have SOLID understanding of how the stack works (as opposed to just a general notion), how high-level languages get broken down into lower level instructions (this is no longer "magic" in my mind), and also how the intermediate level hardware components (memory, ALU) of a CPU can be built.
I would like to thank you for keeping the exact implementation of each component/project unspecified. This made the experience much more rewarding since each step along the way I had to come up with the exact implementation to fit the requirements (as opposed to just following a blueprint). The fact that each little segment can be unit tested too was icing on the cake, it provided confirmation that what I was doing was correct and gave me confidence to venture onwards.
I completely finished the course last night, and although there were a few hiccups I managed to get through it without hitting a roadblock. I should have taken more notes (I know there are some gaps here), but here are some issues I personally had and can remember:
1) Making chips: Couldn't use certain lines directly for output, had to do NOT -> NOT -> output.
2) Stack logical operations in machine language: Used throwaway labels for logical operators. I believe now this was the only way to do it, although this wasn't obvious at the time and I felt like I should have been able to do it without.
3) Small issue with the logicial operations unittest. The unittest didn't check lt versus lte, which was a bug that made its way to the Fibonacci program (this was very hard to debug).
4) At one point the SP was set to 261. I noticed the unittests did this and in my initialization I set it to 256. The only way the tests would pass is if I changed this to 261. I'm guessing this is some disagreement on the start of the initial stack frame.
5) Operating System: Memory alloc/deAlloc testing. I realize this is tricky, but assuming most people code for first-fit, a cautionary test seems reasonable. I wonder how many people code first-fit, insert back into the free-list on deAlloc, and "defrag" on empty. If this is common enough, a unittest might be nice. On the other hand, this is pretty much the only opportunity I had test myself, which is not necessary a bad thing to add into the mix.
6) Operating system char output: At first it didn't hit me that each addressable unit in the screen was 2 chars wide. I was puzzled why my initial attempt didn't have "B" and "D" not exactly touching the right side of the screen and started to doubt the example output in the book. I think it's warranted here to explicitly mention this so that one has the mindset to use bitwise operators. (P.S. I will never take for granted characters again after seeing the amount of effort required to draw them pixel by pixel :-)
7) Jack Grammar (Figure 10.5): I think I wore that page out :-) . It would have been nice to include that either on the inside cover or in an appendix since that has to be referred to VERY often when building the compiler.
Now that I'm finished with this, I'd love to have a book (that uses the same methodology) to learn about/build a modern OS. I realize this was touched on here (memory allocation, device drivers), but I would like to get my "hands dirty" more in this area (scheduling, filesystems, etc). If anyone could recommend such a book I'd be grateful!
Thanks!
Don
|
Locked
