Section 2.7 is about symbol tables and has no exercises. Basically, the technique they talk about is, as you’re parsing the source, you move symbol tables around. So you start out with a null symbol table, and each time you enter a new scope, you push a new symbol table onto a stack. When you leave a scope, you pop that symbol table off the stack. When you look up a variable, you look in the current stack and then you keep going back through past stacks to find it if what you were looking for was declared in a different stack. Neat technique, pretty simple to execute.
Section 2.8 is about intermediate code generation. The gist is, you can build an AST or use some sort of sequential representation, like byte code or assembly. They say that using sequential representations is better for optimizing, but don’t deal a lot with why.
Exercises:

2.8.1: Define a class For for for-statements, similar to class If (below).

class If extends Stmt {
  Expr E; Stmt S;
  public If(Expr x, Stmt y) { E = x; S = y; after = newLabel(); }
  public void gen() {
    Expr n = E.rvalue();
    emit( "ifFalse " + n.toString() + " goto " + after );
    S.gen();
    emit(after + ":");
}

class For extends Stmt {
  Expr pre; Expr cond; Expr post; Stmt stmt;
  public For(Expr pre, Expr cond, Expr post, Stmt stmt) {
    this.pre = pre; this.cond = cond; this.post = post; this.stmt = stmt; before = newLable(); after = newLabel();
  }
  public void gen() {
    pre.gen();
    Expr condVal = cond.rvalue();
    emit (before + ":");
    emit ( "ifFalse " + condVal + " goto " + after );
    stmt.gen();
    post.gen();
    emit( "goto " + before );
    emit( after + ":" );
  }
}

2.8.2. The programming language C does not have a boolean type. Show how a C compiler might translate an if-statement into three-address code.
So I don’t know the details of how C handles truthiness/falsiness. IIRC 0 is false and all other integers are true. Presumably a null pointer is false. Perhaps an empty array, but, then again, perhaps not.

I think the way I’d do it is for each thing that can be an rvalue to emit an interim variable that is equal to true or false*. That way the If statement doesn’t have to keep track of every meaning of “truthy” for the language. I can ask an int to output 0, and it can have code to emit something like “t = [this_var] != 0,” and then a pointer can emit something like “t = [this_var] != NULL” or “t = [this_pointer’s_addrses] != 0x00” or whatever makes sense.

So then the If statement can be like

condition.generateTruthyInterimVariable("myTruthyInterimVariableName")

emit("ifTrue myTruthyInterimVariableName goto " + someLabel")

And with those somewhat lackluster answers, on we go to chapter 3, a deeper look at… Lexical Analysis?! Man, textbooks just have no respect for instant gratification.

*They never said the assembly language can’t have a true/false value; since their assembly language does, I’m going with it.