The lecture slides as a PDF provide a good overview of everything. For this material, the textbook is fairly worthless. Although it does mention some optimizations, it gives no explanation of how compilers actually work.
Aside from the discussion in the text (which starts with MIPS and then discusses some other assembly languages for popular ISAs) and the slides posted at this site, the "generic" translation of various high-level language constructs into assmbly language is discussed in detail in the course notes I wrote years ago for the undergraduate compilers course at Purdue. The complete notes are available as .ps and .pdf; only the chapter about "compilation goals" is really relevant. Be warned that the stack instruction set discussed in the old notes does not exactly match what we are using in class.
In real life, will you ever have to write a compiler? The answer is almost certainly YES, but probably not a full compiler for a standard programming language. Why? Well, nearly every non-trivial program defines an input language, and grown-ups aren't happy with the syntax that you can support using scanf() as your parser. How you specify and process languages for compilation is pretty much how you should specify and process any language. It is true that, in the last few years, you actually have a shot at using AI to accept natural language input for your programs, but natural language is highly ambiguous, and it simply isn't acceptable for many systems to occassionally misunderstand what you wanted done.
As we discussed when talking about assembly language, I created a little compiler called mucky (MIPS uCompiler from KY) and have it set-up with a WWW form interface at http://garage.ece.engr.uky.edu:10043/cgi-bin/mucky.cgi. I've also made available the fairly readable C source code, which uses a simple CGI interface. This compiler is not particularly well-written, and it performs no optimization whatsoever, but it does give a concise example of how LL(1) recursive descent parsing and embedded code generation work. It does deal with at least a few issues not discussed in the slides. For example, it uses the register allocation method that we suggested when discussed assembly language programming. It also provides a good example of how control flow constructs are handled, although, like most compilers, it does not resolve forward references but merely passes them to the assembler.
You have used several assemblers in this course, but none of them are particularly simple. The most interesting one is AIK, because it not only is a pretty sophisticated reconfigurable assembler system, but is built using PCCTS ANTLR, an LL(k) compiler-construction tool set that automates converting an annotated grammar into a compiler. The annotated grammar for AIK is aik.g. You'll notice that AIK uses multiple-pass resolution, making up to 20 passes to resolve forward references.
Computer Organization and Design.