[tropicalmug]

I am one of those programmers: I have no real idea how a compiler goes about its business, my university does not offer an accessible compiler class (only for grad students and very irregularly), and I have no idea where to start besides trying to force my way through the purple dragon book.

What are things I should know about compilers that I probably don't? What is suggested reading on compilers?

[RogerL]

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.

[stcredzero]

> 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.

You said it a lot more concisely than I did!

[xtracto]

I am not an expert in compilers, but in my undergrad compiler's class one of the things I remember the most are parsers (such as LALR). I remember having a great time implementing different types of parsers:

http://en.wikipedia.org/wiki/Category:Parsing_algorithms

I think the dragon book is the absolute reference for learning compilers:

http://www.amazon.com/Compilers-Principles-Techniques-Alfred...

[stcredzero]

As xtracto mentioned, parsing and enough automata theory to understand what context free grammars are and where they fall should be part of your basic toolkit, but how they generate code is even more useful to C programmers. (One study done decades ago found that the average C statement resulted in 2.7 CICS assembly language commands.)

The Dragon Book is not the best teaching tool out there. Maybe try The Elements of Computing Systems Chapters 10 & 11? You might need to peek at the earlier chapters to get a grounding in the particular assembly language they use.