Compiler

From Wikipedia, the free encyclopedia

Jump to: navigation, search

This article is about the computing term. For the anime, see Compiler
(anime).

A diagram of the operation of a typical multi-language, multi-target

compiler.

A compiler is a computer program (or set of programs) that translates

text written in a computer language (the source language) into another
computer language (the target language). The original sequence is
usually called the source code and the output called object code.
Commonly the output has a form suitable for processing by other
programs (e.g., a linker), but it may be a human-readable text file.

The most common reason for wanting to translate source code is to

create an executable program. The name "compiler" is primarily used for
programs that translate source code from a high-level programming
language to a lower level language (e.g., assembly language or machine
language). A program that translates from a low level language to a
higher level one is a decompiler. A program that translates between
high-level languages is usually called a language translator, source to
source translator, or language converter. A language rewriter is usually
a program that translates the form of expressions without a change of
language.
A compiler is likely to perform many or all of the following operations:
lexical analysis, preprocessing, parsing, semantic analysis, code
generation, and code optimization.

Contents
[hide]

• 1 History
o 1.1 Compilers in education
• 2 Compiler output
o 2.1 Compiled versus interpreted languages
o 2.2 Hardware compilation
• 3 Compiler design
o 3.1 One-pass versus multi-pass compilers
o 3.2 Front end
o 3.3 Back end
• 4 Related techniques
• 5 See also
• 6 Notes
• 7 References

• 8 External links

[edit] History
Software for early computers was exclusively written in assembly
language for many years. Higher level programming languages were not
invented until the benefits of being able to reuse software on different
kinds of CPUs started to become significantly greater than the cost of
writing a compiler. The very limited memory capacity of early
computers also created many technical problems when implementing a
compiler.

Towards the end of the 1950s, machine-independent programming

languages were first proposed. Subsequently, several experimental
compilers were developed. The first compiler was written by Grace
Hopper, in 1952, for the A-0 programming language. The FORTRAN
team led by John Backus at IBM is generally credited as having
introduced the first complete compiler, in 1957. COBOL was an early
language to be compiled on multiple architectures, in 1960.[1]

In many application domains the idea of using a higher level language

quickly caught on. Because of the expanding functionality supported by
newer programming languages and the increasing complexity of
computer architectures, compilers have become more and more
complex.

Early compilers were written in assembly language. The first self-

hosting compiler — capable of compiling its own source code in a high-
level language — was created for Lisp by Hart and Levin at MIT in
1962.[2] Since the 1970s it has become common practice to implement a
compiler in the language it compiles, although both Pascal and C have
been popular choices for implementation language. Building a self-
hosting compiler is a bootstrapping problem -- the first such compiler for
a language must be compiled either by a compiler written in a different
language, or (as in Hart and Levin's Lisp compiler) compiled by running
the compiler in an interpreter.

[edit] Compilers in education

Compiler construction and compiler optimization are taught at

universities as part of the computer science curriculum. Such courses are
usually supplemented with the implementation of a compiler for an
educational programming language. A well-documented example is
Niklaus Wirth's PL/0 compiler, which Wirth used to teach compiler
construction in the 1970s.[3] In spite of its simplicity, the PL/0 compiler
introduced several influential concepts to the field:

1. Program development by stepwise refinement (also the title of a

1971 paper by Wirth[4])
2. The use of a recursive descent parser
3. The use of EBNF to specify the syntax of a language
4. A code generator producing portable P-code
5. The use of T-diagrams in the formal description of the
bootstrapping problem

[edit] Compiler output

One method used to classify compilers is by the platform on which the
generated code they produce executes. This is known as the target
platform.

A native or hosted compiler is one whose output is intended to directly

run on the same type of computer and operating system as the compiler
itself runs on. The output of a cross compiler is designed to run on a
different platform. Cross compilers are often used when developing
software for embedded systems that are not intended to support a
software development environment.
The output of a compiler that produces code for a virtual machine (VM)
may or may not be executed on the same platform as the compiler that
produced it. For this reason such compilers are not usually classified as
native or cross compilers.

[edit] Compiled versus interpreted languages

Higher-level programming languages are generally divided for

convenience into compiled languages and interpreted languages.
However, there is rarely anything about a language that requires it to be
exclusively compiled, or exclusively interpreted. The categorization
usually reflects the most popular or widespread implementations of a
language — for instance, BASIC is thought of as an interpreted
language, and C a compiled one, despite the existence of BASIC
compilers and C interpreters.

In a sense, all languages are interpreted, with "execution" being merely a

special case of interpretation performed by transistors switching on a
CPU. Modern trends toward just-in-time compilation and bytecode
interpretation also blur the traditional categorizations.

There are exceptions. Some language specifications spell out that

implementations must include a compilation facility; for example,
Common Lisp. Other languages have features that are very easy to
implement in an interpreter, but make writing a compiler much harder;
for example, APL, SNOBOL4, and many scripting languages allow
programs to construct arbitrary source code at runtime with regular
string operations, and then execute that code by passing it to a special
evaluation function. To implement these features in a compiled
language, programs must usually be shipped with a runtime library that
includes a version of the compiler itself.

[edit] Hardware compilation

The output of some compilers may target hardware at a very low level.
For example a Field Programmable Gate Array (FPGA) or structured
Application-specific integrated circuit (ASIC). Such compilers are said
to be hardware compilers or synthesis tools because the programs they
compile effectively control the final configuration of the hardware and
how it operates; the output of the compilation are not instructions that
are executed in sequence - only an interconnection of transistors or
lookup tables. For example, XST is the Xilinx Synthesis Tool used for
configuring FPGAs. Similar tools are available from Altera, Synplicity,
Synopsys and other vendors.

[edit] Compiler design

The approach taken to compiler design is affected by the complexity of
the processing that needs to be done, the experience of the person(s)
designing it, and the resources (eg, people and tools) available.

A compiler for a relatively simple language written by one person might

be a single, monolithic piece of software. When the source language is
large and complex, and high quality output is required the design may be
split into a number of relatively independent phases, or passes. Having
separate phases means development can be parceled up into small parts
and given to different people. It also becomes much easier to replace a
single phase by an improved one, or to insert new phases later (eg,
additional optimizations).

The division of the compilation processes in phases (or passes) was

championed by the Production Quality Compiler-Compiler Project
(PQCC) at Carnegie Mellon University. This project introduced the
terms front end, middle end (rarely heard today), and back end.

All but the smallest of compilers have more than two phases. However,
these phases are usually regarded as being part of the front end or the
back end. The point at where these two ends meet is always open to
debate. The front end is generally considered to be where syntactic and
semantic processing takes place, along with translation to a lower level
of representation (than source code).

The middle end is usually designed to perform optimizations on a form

other than the source code or machine code. This source code/machine
code independence is intended to enable generic optimizations to be
shared between versions of the compiler supporting different languages
and target processors.

The back end takes the output from the middle. It may perform more
analysis, transformations and optimizations that are for a particular
computer. Then, it generates code for a particular processor and OS.

This front-end/middle/back-end approach makes it possible to combine

front ends for different languages with back ends for different CPUs.
Practical examples of this approach are the GNU Compiler Collection,
LLVM, and the Amsterdam Compiler Kit, which have multiple front-
ends, shared analysis and multiple back-ends.

[edit] One-pass versus multi-pass compilers

Classifying compilers by number of passes has its background in the

hardware resource limitations of computers. Compiling involves
performing lots of work and early computers did not have enough
memory to contain one program that did all of this work. So compilers
were split up into smaller programs which each made a pass over the
source (or some representation of it) performing some of the required
analysis and translations.

The ability to compile in a single pass is often seen as a benefit because

it simplifies the job of writing a compiler and one pass compilers are
generally faster than multi-pass compilers. Many languages were
designed so that they could be compiled in a single pass (e.g., Pascal).

In some cases the design of a language feature may require a compiler to

perform more than one pass over the source. For instance, consider a
declaration appearing on line 20 of the source which affects the
translation of a statement appearing on line 10. In this case, the first pass
needs to gather information about declarations appearing after
statements that they affect, with the actual translation happening during
a subsequent pass.

The disadvantage of compiling in a single pass is that it is not possible to

perform many of the sophisticated optimizations needed to generate high
quality code. It can be difficult to count exactly how many passes an
optimizing compiler makes. For instance, different phases of
optimization may analyse one expression many times but only analyse
another expression once.

Splitting a compiler up into small programs is a technique used by

researchers interested in producing provably correct compilers. Proving
the correctness of a set of small programs often requires less effort than
proving the correctness of a larger, single, equivalent program.

While the typical multi-pass compiler outputs machine code from its
final pass, there are several other types:

• A "source-to-source compiler" is a type of compiler that takes a

high level language as its input and outputs a high level
language. For example, an automatic parallelizing compiler will
frequently take in a high level language program as an input and
then transform the code and annotate it with parallel code
annotations (e.g. OpenMP) or language constructs (e.g. Fortran's
DOALL statements).
• Stage compiler that compiles to assembly language of a
theoretical machine, like some Prolog implementations
o This Prolog machine is also known as the Warren
Abstract Machine (or WAM). Bytecode compilers for
Java, Python, and many more are also a subtype of this.
 • Just-in-time compiler, used by Smalltalk and Java systems, and
also by Microsoft .Net's Common Intermediate Language (CIL)
o Applications are delivered in bytecode, which is
compiled to native machine code just prior to execution.

[edit] Front end

The front end analyzes the source code to build an internal

representation of the program, called the intermediate representation or
IR. It also manages the symbol table, a data structure mapping each
symbol in the source code to associated information such as location,
type and scope. This is done over several phases, which includes some
of the following:

1. Line reconstruction. Languages which strop their keywords or

allow arbitrary spaces within identifiers require a phase before
parsing, which converts the input character sequence to a canonical
form ready for the parser. The top-down, recursive-descent, table-
driven parsers used in the 1960s typically read the source one
character at a time and did not require a separate tokenizing phase.
Atlas Autocode, and Imp (and some implementations of Algol and
Coral66) are examples of stropped languages whose compilers
would have a Line Reconstruction phase.
2. Lexical analysis breaks the source code text into small pieces
called tokens. Each token is a single atomic unit of the language,
for instance a keyword, identifier or symbol name. The token
syntax is typically a regular language, so a finite state automaton
constructed from a regular expression can be used to recognize it.
This phase is also called lexing or scanning, and the software doing
lexical analysis is called a lexical analyzer or scanner.

Lexical analysis
From Wikipedia, the free encyclopedia

Jump to: navigation, search

In computer science, lexical analysis is the process of converting a

sequence of characters into a sequence of tokens. Programs performing
lexical analysis are called lexical analyzers or lexers. A lexer is often
organized as separate scanner and tokenizer functions, though the
boundaries may not be clearly defined.

Contents
[hide]

• 1 Lexical grammar
• 2 Token
• 3 Scanner
• 4 Tokenizer
• 5 Lexer generator
• 6 Lexical analyzer generators
• 7 See also

• 8 References

[edit] Lexical grammar

The specification of a programming language will include a set of rules,
often expressed syntactically, specifying the set of possible character
sequences that can form a token or lexeme. The whitespace characters
are often ignored during lexical analysis.

[edit] Token
A token is a categorized block of text. The block of text corresponding
to the token is known as a lexeme. A lexical analyzer processes lexemes
to categorize them according to function, giving them meaning. This
assignment of meaning is known as tokenization. A token can look like
anything: English, gibberish symbols, anything; it just needs to be a
useful part of the structured text.

Consider this expression in the C programming language:

sum=3+2;

Tokenized in the following table:

lexeme token type

sum IDENT

= ASSIGN_OP
3 NUMBER

+ ADD_OP

2 NUMBER

; SEMICOLON

Tokens are frequently defined by regular expressions, which are

understood by a lexical analyzer generator such as lex. The lexical
analyzer (either generated automatically by a tool like lex, or hand-
crafted) reads in a stream of characters, identifies the lexemes in the
stream, and categorizes them into tokens. This is called "tokenizing." If
the lexer finds an invalid token, it will report an error.

Following tokenizing is parsing. From there, the interpreted data may be

loaded into data structures, for general use, interpretation, or compiling.

Consider a text describing a calculation:

46 - number_of(cows);

The lexemes here might be: "46", "-", "number_of", "(", "cows", ")"
and ";". The lexical analyzer will denote lexemes "46" as 'number', "-"
as 'character' and "number_of" as a separate token. Even the lexeme ";"
in some languages (such as C) has some special meaning.

[edit] Scanner
The first stage, the scanner, is usually based on a finite state machine. It
has encoded within it information on the possible sequences of
characters that can be contained within any of the tokens it handles
(individual instances of these character sequences are known as
lexemes). For instance, an integer token may contain any sequence of
numerical digit characters. In many cases, the first non-whitespace
character can be used to deduce the kind of token that follows and
subsequent input characters are then processed one at a time until
reaching a character that is not in the set of characters acceptable for that
token (this is known as the maximal munch rule). In some languages the
lexeme creation rules are more complicated and may involve
backtracking over previously read characters.

[edit] Tokenizer
Tokenization is the process of demarcating and possibly classifying
sections of a string of input characters. The resulting tokens are then
passed on to some other form of processing. The process can be
considered a sub-task of parsing input.

Take, for example, the following string. Unlike humans, a computer

cannot intuitively 'see' that there are 9 words. To a computer this is only
a series of 43 characters.

The quick brown fox jumps over the lazy dog

A process of tokenization could be used to split the sentence into word

tokens. Although the following example is given as XML there are many
ways to represent tokenized input:

<sentence>
<word>The</word>
<word>quick</word>
<word>brown</word>
<word>fox</word>
<word>jumps</word>
<word>over</word>
<word>the</word>
<word>lazy</word>
<word>dog</word>
</sentence>

A lexeme, however, is only a string of characters known to be of a

certain kind (eg, a string literal, a sequence of letters). In order to
construct a token, the lexical analyzer needs a second stage, the
evaluator, which goes over the characters of the lexeme to produce a
value. The lexeme's type combined with its value is what properly
constitutes a token, which can be given to a parser. (Some tokens such as
parentheses do not really have values, and so the evaluator function for
these can return nothing. The evaluators for integers, identifiers, and
strings can be considerably more complex. Sometimes evaluators can
suppress a lexeme entirely, concealing it from the parser, which is useful
for whitespace and comments.)

For example, in the source code of a computer program the string

 net_worth_future = (assets - liabilities);

might be converted (with whitespace suppressed) into the lexical token

stream:

NAME "net_worth_future"
EQUALS
OPEN_PARENTHESIS
NAME "assets"
MINUS
NAME "liabilities"
CLOSE_PARENTHESIS
SEMICOLON

Though it is possible and sometimes necessary to write a lexer by hand,

lexers are often generated by automated tools. These tools generally
accept regular expressions that describe the tokens allowed in the input
stream. Each regular expression is associated with a production in the
lexical grammar of the programming language that evaluates the
lexemes matching the regular expression. These tools may generate
source code that can be compiled and executed or construct a state table
for a finite state machine (which is plugged into template code for
compilation and execution).

Regular expressions compactly represent patterns that the characters in

lexemes might follow. For example, for an English-based language, a
NAME token might be any English alphabetical character or an
underscore, followed by any number of instances of any ASCII
alphanumeric character or an underscore. This could be represented
compactly by the string [a-zA-Z_][a-zA-Z_0-9]*. This means "any
character a-z, A-Z or _, followed by 0 or more of a-z, A-Z, _ or 0-9".

Regular expressions and the finite state machines they generate are not
powerful enough to handle recursive patterns, such as "n opening
parentheses, followed by a statement, followed by n closing
parentheses." They are not capable of keeping count, and verifying that
n is the same on both sides — unless you have a finite set of permissible
values for n. It takes a full-fledged parser to recognize such patterns in
their full generality. A parser can push parentheses on a stack and then
try to pop them off and see if the stack is empty at the end.

The Lex programming tool and its compiler is designed to generate code
for fast lexical analysers based on a formal description of the lexical
syntax. It is not generally considered sufficient for applications with a
complicated set of lexical rules and severe performance requirements;
for instance, the GNU Compiler Collection uses hand-written lexers.
[edit] Lexer generator
Lexical analysis can often be performed in a single pass if reading is
done a character at a time. Single-pass lexers can be generated by tools
such as the classic flex.

The lex/flex family of generators uses a table-driven approach which is

much less efficient than the directly coded approach. With the latter
approach the generator produces an engine that directly jumps to follow-
up states via goto statements. Tools like re2c and queχ have proven (e.g.
article about re2c) to produce engines that are between two to three
times faster than flex produced engines.[citation needed] It is in general
difficult to hand-write analyzers that perform better than engines
generated by these latter tools.

The simple utility of using a scanner generator should not be discounted,

especially in the developmental phase, when a language specification
might change daily. The ability to express lexical constructs as regular
expressions facilitates the description of a lexical analyzer. Some tools
offer the specification of pre- and post-conditions which are hard to
program by hand. In that case, using a scanner generator may save a lot
of development time.

[edit] Lexical analyzer generators

• Flex - Alternative variant of the classic 'lex' (C/C++).
• JLex - A Lexical Analyzer Generator for Java.
• Quex - (or 'Queχ') A Mode Oriented Lexical Analyzer Generator
for C++.
• OOLEX - An Object Oriented Lexical Analyzer Generator.
• re2c
• PLY - An implementation of lex and yacc parsing tools for
Python.

3. Preprocessing. Some languages, e.g., C, require a preprocessing

phase which supports macro substitution and conditional
compilation. Typically the preprocessing phase occurs before
syntactic or semantic analysis; e.g. in the case of C, the
preprocessor manipulates lexical tokens rather than syntactic
forms. However, some languages such as Scheme support macro
substitutions based on syntactic forms.
4. Syntax analysis involves parsing the token sequence to identify the
syntactic structure of the program. This phase typically builds a
 parse tree, which replaces the linear sequence of tokens with a tree
structure built according to the rules of a formal grammar which
define the language's syntax. The parse tree is often analyzed,
augmented, and transformed by later phases in the compiler.

Parsing
From Wikipedia, the free encyclopedia

(Redirected from Syntax analysis)

Jump to: navigation, search
"Parser" redirects here. For the computer programming language, see
Parser (CGI language).

In computer science and linguistics, parsing, or, more formally,

syntactic analysis, is the process of analyzing a sequence of tokens to
determine grammatical structure with respect to a given (more or less)
formal grammar. A parser is thus one of the components in an
interpreter or compiler, where it captures the implied hierarchy of the
input text and transforms it into a form suitable for further processing
(often some kind of parse tree, abstract syntax tree or other hierarchical
structure) and normally checks for syntax errors at the same time. The
parser often uses a separate lexical analyser to create tokens from the
sequence of input characters. Parsers may be programmed by hand or
may be semi-automatically generated (in some programming language)
by a tool (such as Yacc) from a grammar written in Backus-Naur form.

Parsing is also an earlier term for the diagramming of sentences of

natural languages, and is still used for the diagramming of inflected
languages, such as the Romance languages or Latin.

Parsers can also be constructed as executable specifications of grammars

in functional programming languages. Frost, Hafiz and Callaghan [1]
have built on the work of others to construct a set of higher-order
functions (called parser combinators) which allow polynomial time and
space complexity top-down parser to be constructed as executable
specifications of ambiguous grammars containing left-recursive
productions. The X-SAIGA site has more about the algorithms and
implementation details.

Contents
[hide]

• 1 Human languages
 • 2 Programming languages
o 2.1 Overview of process
• 3 Types of parsers
• 4 Examples of parsers
o 4.1 Top-down parsers
o 4.2 Bottom-up parsers
• 5 References
• 6 See also
o 6.1 Parsing concepts
o 6.2 Parser development software

 6.2.1 Wikimedia

[edit] Human languages

Also see Category:Natural language parsing

In some machine translation and natural language processing systems,

human languages are parsed by computer programs. Human sentences
are not easily parsed by programs, as there is substantial ambiguity in
the structure of human language. In order to parse natural language data,
researchers must first agree on the grammar to be used. The choice of
syntax is affected by both linguistic and computational concerns; for
instance some parsing systems use lexical functional grammar, but in
general, parsing for grammars of this type is known to be NP-complete.
Head-driven phrase structure grammar is another linguistic formalism
which has been popular in the parsing community, but other research
efforts have focused on less complex formalisms such as the one used in
the Penn Treebank. Shallow parsing aims to find only the boundaries of
major constituents such as noun phrases. Another popular strategy for
avoiding linguistic controversy is dependency grammar parsing.

Most modern parsers are at least partly statistical; that is, they rely on a
corpus of training data which has already been annotated (parsed by
hand). This approach allows the system to gather information about the
frequency with which various constructions occur in specific contexts.
(See machine learning.) Approaches which have been used include
straightforward PCFGs (probabilistic context free grammars), maximum
entropy, and neural nets. Most of the more successful systems use
lexical statistics (that is, they consider the identities of the words
involved, as well as their part of speech). However such systems are
vulnerable to overfitting and require some kind of smoothing to be
effective.[citation needed]
Parsing algorithms for natural language cannot rely on the grammar
having 'nice' properties as with manually-designed grammars for
programming languages. As mentioned earlier some grammar
formalisms are very computationally difficult to parse; in general, even
if the desired structure is not context-free, some kind of context-free
approximation to the grammar is used to perform a first pass. Algorithms
which use context-free grammars often rely on some variant of the CKY
algorithm, usually with some heuristic to prune away unlikely analyses
to save time. (See chart parsing.) However some systems trade speed for
accuracy using, eg, linear-time versions of the shift-reduce algorithm. A
somewhat recent development has been parse reranking in which the
parser proposes some large number of analyses, and a more complex
system selects the best option. It is normally branching of one part and
its subparts

[edit] Programming languages

The most common use of a parser is as a component of a compiler or
interpreter. This parses the source code of a computer programming
language to create some form of internal representation. Programming
languages tend to be specified in terms of a context-free grammar
because fast and efficient parsers can be written for them. Parsers are
written by hand or generated by parser generators.

Context-free grammars are limited in the extent to which they can

express all of the requirements of a language. Informally, the reason is
that the memory of such a language is limited. The grammar cannot
remember the presence of a construct over an arbitrarily long input; this
is necessary for a language in which, for example, a name must be
declared before it may be referenced. More powerful grammars that can
express this constraint, however, cannot be parsed efficiently. Thus, it is
a common strategy to create a relaxed parser for a context-free grammar
which accepts a superset of the desired language constructs (that is, it
accepts some invalid constructs); later, the unwanted constructs can be
filtered out.

[edit] Overview of process

The following example demonstrates the common case of parsing a
computer language with two levels of grammar: lexical and syntactic.

The first stage is the token generation, or lexical analysis, by which the
input character stream is split into meaningful symbols defined by a
grammar of regular expressions. For example, a calculator program
would look at an input such as "12*(3+4)^2" and split it into the tokens
12, *, (, 3, +, 4, ), ^, and 2, each of which is a meaningful symbol in the
context of an arithmetic expression. The parser would contain rules to
tell it that the characters *, +, ^, ( and ) mark the start of a new token, so
meaningless tokens like "12*" or "(3" will not be generated.

The next stage is parsing or syntactic analysis, which is checking that the
tokens form an allowable expression. This is usually done with reference
to a context-free grammar which recursively defines components that
can make up an expression and the order in which they must appear.
However, not all rules defining programming languages can be
expressed by context-free grammars alone, for example type validity and
proper declaration of identifiers. These rules can be formally expressed
with attribute grammars.

The final phase is semantic parsing or analysis, which is working out the
implications of the expression just validated and taking the appropriate
action. In the case of a calculator or interpreter, the action is to evaluate
the expression or program; a compiler, on the other hand, would
generate some kind of code. Attribute grammars can also be used to
define these actions.
[edit] Types of parsers
The task of the parser is essentially to determine if and how the input
can be derived from the start symbol of the grammar. This can be done
in essentially two ways:

• Top-down parsing - Top-down parsing can be viewed as an

attempt to find left-most derivations of an input-stream by
searching for parse-trees using a top-down expansion of the
given formal grammar rules. Tokens are consumed from left to
right. Inclusive choice is used to accommodate ambiguity by
expanding all alternative right-hand-sides of grammar rules [2].
LL parsers and recursive-descent parser are examples of top-
down parsers, which cannot accommodate left recursive
productions. Although it has been believed that simple
implementations of top-down parsing cannot accommodate
direct and indirect left-recursion and may require exponential
time and space complexity while parsing ambiguous context-free
grammars, more sophisticated algorithm for top-down parsing
have been created by Frost, Hafiz, and Callaghan [3] [1] which
accommodates ambiguity and left recursion in polynomial time
and which generates polynomial-size representations of the
potentially-exponential number of parse trees. Their algorithm is
able to produce both left-most and right-most derivations of an
input w.r.t. a given CFG.
• Bottom-up parsing - A parser can start with the input and attempt
to rewrite it to the start symbol. Intuitively, the parser attempts to
locate the most basic elements, then the elements containing
these, and so on. LR parsers are examples of bottom-up parsers.
Another term used for this type of parser is Shift-Reduce parsing.

Another important distinction is whether the parser generates a leftmost

derivation or a rightmost derivation (see context-free grammar). LL
parsers will generate a leftmost derivation and LR parsers will generate a
rightmost derivation (although usually in reverse)[citation needed].

5. Semantic analysis is the phase in which the compiler adds semantic

information to the parse tree and builds the symbol table. This
phase performs semantic checks such as type checking (checking
for type errors), or object binding (associating variable and
 function references with their definitions), or definite assignment
(requiring all local variables to be initialized before use), rejecting
incorrect programs or issuing warnings. Semantic analysis usually
requires a complete parse tree, meaning that this phase logically
follows the parsing phase, and logically precedes the code
generation phase, though it is often possible to fold multiple phases
into one pass over the code in a compiler implementation.

[edit] Back end

The term back end is sometimes confused with code generator because
of the overlapped functionality of generating assembly code. Some
literature uses middle end to distinguish the generic analysis and
optimization phases in the back end from the machine-dependent code
generators.

The main phases of the back end include the following:

1. Analysis: This is the gathering of program information from the

intermediate representation derived from the input. Typical
analyses are data flow analysis to build use-define chains,
dependence analysis, alias analysis, pointer analysis, escape
analysis etc. Accurate analysis is the basis for any compiler
optimization. The call graph and control flow graph are usually
also built during the analysis phase.
2. Optimization: the intermediate language representation is
transformed into functionally equivalent but faster (or smaller)
forms. Popular optimizations are inline expansion, dead code
elimination, constant propagation, loop transformation, register
allocation or even automatic parallelization.
3. Code generation: the transformed intermediate language is
translated into the output language, usually the native machine
language of the system. This involves resource and storage
decisions, such as deciding which variables to fit into registers
and memory and the selection and scheduling of appropriate
machine instructions along with their associated addressing
modes (see also Sethi-Ullman algorithm).

Compiler analysis is the prerequisite for any compiler optimization, and

they tightly work together. For example, dependence analysis is crucial
for loop transformation.

In addition, the scope of compiler analysis and optimizations vary

greatly, from as small as a basic block to the procedure/function level, or
even over the whole program (interprocedural optimization). Obviously,
a compiler can potentially do a better job using a broader view. But that
broad view is not free: large scope analysis and optimizations are very
costly in terms of compilation time and memory space; this is especially
true for interprocedural analysis and optimizations.

The existence of interprocedural analysis and optimizations is common

in modern commercial compilers from HP, IBM, SGI, Intel, Microsoft,
and Sun Microsystems. The open source GCC was criticized for a long
time for lacking powerful interprocedural optimizations, but it is
changing in this respect. Another good open source compiler with full
analysis and optimization infrastructure is Open64, which is used by
many organizations for research and commercial purposes.

Due to the extra time and space needed for compiler analysis and
optimizations, some compilers skip them by default. Users have to use
compilation options to explicitly tell the compiler which optimizations
should be enabled.

[edit] Related techniques

Assembly language is not a high-level language and a program that
compiles it is more commonly known as an assembler, with the inverse
program known as a disassembler.

A program that translates from a low level language to a higher level one
is a decompiler.

A program that translates between high-level languages is usually called

a language translator, source to source translator, language converter,
or language rewriter. The last term is usually applied to translations that
do not involve a change of language.