Phases of a Compiler Questions and Answers

Answer: A

Correct answer: names must be found quickly and are looked up very frequently

Every identifier in the program is looked up at least once and usually several times, across several phases, so the lookup is on the compiler's hot path.

A hash table gives near constant time, where a linear list would give time proportional to the number of names. The trade is that ordering is lost, which is why scope handling uses a stack of tables or a chain of them alongside. No standard prescribes the structure; speed alone recommends it.

Answer: B

Correct answer: removed or hidden so the enclosing declarations become visible again

A name declared in an inner scope must cease to be visible when that scope ends, and any outer declaration it concealed must become visible again.

The usual implementation is a stack of scopes, pushed on entry and popped on exit, or a chain of entries per name from which the innermost is unlinked. The entries may survive if debugging information needs them, but they are removed from the visible set - which is what scope means.

Answer: C

Correct answer: the symbols it defines and the symbols it leaves unresolved

Separate compilation means the linker must later match one module's references against another's definitions, so each object file carries two lists: the symbols it exports and the external symbols it needs.

Local variable names are not needed for linking, and appear only if debugging information is requested. The optimisations applied and the source text are irrelevant to resolution - the linker works entirely from the symbol tables and the relocation entries.

Answer: D

Correct answer: map machine addresses back to source lines and variable names

The debugger must display source lines and variable values while executing machine code, which requires a mapping between the two - addresses to lines, and variable names to stack offsets or registers.

The compiler emits that mapping alongside the code. Optimisation complicates it badly, since code is reordered and variables removed, which is why debug builds usually disable it. The information is a translation aid, not a constraint on the optimiser and nothing to do with loading.

Answer: A

Both are true and the reason gives the mechanism, and this is why builds are often produced twice. A variable may be held in a register at one moment and nowhere at all the next, so the debugger cannot always report its value.

Answer: B

Correct answer: an optimisation pass operating within the middle of the compiler

Reading intermediate code and writing intermediate code is the signature of an optimisation pass: the representation is unchanged and only the quality of the program improves.

Such passes are typically run several times and in sequence, since one transformation exposes opportunities for another. They sit between the front and back ends, so they are neither the last pass before the executable nor part of lexical analysis, and they have nothing to do with the assembler.

Answer: C

Correct answer: more thorough optimisation generally costs more compilation time

Optimisation requires analysis, and the more thorough analyses are expensive - data flow over the whole flow graph, interprocedural work, repeated passes as one transformation exposes another.

That is precisely why compilers expose levels rather than a single setting: a developer compiling repeatedly wants speed, and a release build can afford minutes. The relationship is a trade, not an independence, and certainly not the inverse the last option suggests.

Answer: D

Correct answer: omits most optimisation and includes full symbolic information

The two go together and both serve the debugger. Full symbolic information supplies the mapping from addresses to source lines and variables.

Omitting optimisation keeps that mapping meaningful: an optimiser reorders code, merges computations and removes variables entirely, after which stepping through the source becomes confusing and inspecting a variable may be impossible. A debug build is therefore slower and larger by design. Semantic checking and the parser are identical in both builds.

Answer: A

Token patterns are regular expressions and are recognised by finite automata, which is what makes scanner generation mechanical. Left recursion and declaration order are properties bearing on parsing and semantic analysis instead.

Answer: B

Correct answer: a grammar that is unambiguous and within a well known class

An unambiguous grammar gives each valid program exactly one parse tree, so there is no choice for the parser to resolve. Belonging to a class such as LL(1) or LALR(1) means an efficient deterministic parser can be generated automatically.

Neither the number of keywords nor the presence of comments affects this, both being matters for the scanner, and a single type would simplify semantic analysis rather than parsing. The grammar's properties are what decide parsing difficulty.