|
|
|
|
|
|
by RogerL
4720 days ago
|
|
|
I am not the person you are responding to, but I don't think the point was to understand how compilers parse code, but to know how the compiler implements your code in assembly. I.e. knowing things like the difference between the stack and the heap, how to do a function call in assembly while passing parameters, how memory actually gets allocated to you from the operating system, what happens when a page fault occurs, how the compiler lays out data in memory (this has huge implications in your code as to whether you generate a ton of cache misses or not). None of that really has much to do with understanding compilers, but understanding modern microprocessors and assembly code. But, of course, you need to pick what makes sense to you. If all you ever do is write MySQL queries for low performance requirements apps, probably all of that knowledge will prove of little use to you. But to actually debug something when it goes all the way to the OS, to deal with hardware, to write a device driver, you really can't get far without knowing it. If you are programming in C/C++ or otherwise doing anything performant (3D graphics, CUDA GPU programming, and the like) you'd better know all that stuff intimately if you strive to do more than "program by magic" (when something breaks, randomly change code until it seems to work without you understanding why). When you know this, you can basically go into any programming assignment and get it done. Interface this phone to this hardware? Done. Fix this nasty blue screen crash? Okay, no problem. Modify the linux kernel for some local need? I'll get right to it! Without it you are kind of restrained to working on top of the infrastructure that others have built. Not that there is anything wrong with that - it's your career, and your life, you might as well try to have fun while doing it. |
|
|
You said it a lot more concisely than I did!