Compilers. Introduction to Compilers. Lecture 1. Spring term. Mick O Donnell: michael.odonnell@uam.es Alfonso Ortega: alfonso.ortega@uam.

Transcription

1 Compilers Spring term Mick O Donnell: michael.odonnell@uam.es Alfonso Ortega: alfonso.ortega@uam.es Lecture 1 to Compilers 1

2 Topic 1: What is a Compiler? 3 What is a Compiler? A compiler is a computer program which coverts source code written in a high level programming language into another form, typically machine code. unsigned int gcd (unsigned int a, unsigned int b) { if (a == 0 &&b == 0) b = 1; else if (b == 0) b = a; else if (a!= 0) while (a!= b) if (a <b) b -= a; else a -= b; } return b; The machine code is a sequence of instructions for the machine to perform. 4 2

3 Why study Compilers? Very few computer scientists actually write or modify compilers. So why is this a core subject? Some computer scientists need to understand how compilers work, so that they can write them. For this reason, the knowledge needs to be passed on. But more importantly, understanding how our computer programs are compiled and executed can help any programmer understand how the code they write drives the machine, and thus help us write faster, more effective programs. 5 Topic 2: History of Programming Languages 6 3

4 Development of Programming FIXED HARDWARE Early automatic machines were constructed with a single task in mind, and thus could not be programmed. Machines would process data supplied by the user. E.g., Cash Registers, Ballot Counters. PROGRAMMABLE HARDWARE In the 1940s, the first programmable computing machines were made. Users could change the way in which the machine processed data by configuring a number of switches on the machine. STORED PROGRAMS Some machines allowed operators to enter program line by line, stored in memory. In 1944, Harvard Mark I accepted programs stored on paper tape. In : The magnetic drum memory was introduced as a data storage device for computers. 7 Development of Programming (Cont.) MACHINE CODE The earliest programmable computers worked directly in machine code. A machine code program is a sequence of instructions, each instruction consists of an operator, and (in the early days) a single argument, which would be either a value (e.g., an integer), or a reference to a register (a memory location). The CPU loads in one instruction at a time, and executes that instruction. The next instruction in sequence is then loaded in. Each instruction is represented as a fixed number of bits (in early days, 8 bits were used, although currently 64 bit instructions are common). The first 4 bits represented the operator ( e.g., 00 for NOOP, 01 for ADD, 02 for MOV, etc. The remaining 4 bits represent the data to operate on. e.g Add 1 to the current sum. 8 4

5 Development of Programming (cont.) INTRODUCTION OF ASSEMBLY LANGUAGE Programming in machine code is very slow, requiring the programmer to continually keep track of which binary code represents which operation, and converting numbers into binary. Assembly Language introduced a mnemonic representation, using symbols such as ADD, MOV or POP to use rather than the binary codes. A program called the ASSEMBLER then translates the assembly language program into machine code. Assembly programs also allow the inclusion of comments, which explain the program to other programmers, but are ignored in the conversion to machine code. Distinct assembly language for each machine type. EXAMPLE mov al, 0x Development of Programming (cont.) HIGH LEVEL PROGRAMMING LANGUAGES Assembly language is specific to a particular machine code, and thus a particular machine type. The next step was to develop programming languages which work on any machine. Each machine provides a compiler to translate the high-level language to the machine code for that machine. Some writing in assembler still took place where optimal performance needed (and still happens today!) 1945: Zuse developed plankalkul (plan calculus) the first programming language. This was the predecessor of algorithmic programming languages and concepts of logic programming. It was designed to be a chess-playing program. 1949: Short Order, developed by John Mauchly, is thought to be the first high-level programming language an IBM team lead by John W. Backus developed FORTRAN 10 5

6 Development of Programming (cont.) NEW PARADIGMS While the earliest HLPLs were seen as sequences of instructions, the developing experience of using compilers to map from abstract languages to machine runnable code allowed computer scientists to experiment with the way programming languages were formulated. Best known of the new programming paradigms are: Functional (Lisp, Scheme, ML, Haskell), Logical (Prolog, etc.), Object-oriented (C++, Java, CLOS, Python, etc.) 11 Development of Programming (cont.) VIRTUAL MACHINES In the standard approach, source programs are compiled to distinct machine code formats for each hardware/os platform. An alternative approach compiles the source code to a platformindependent form of machine code, called Byte. Each platform then provides software (e.g., Java Runtime for Windows) to execute the byte code on that platform. The byte code thus does not drive the CPU directly: the virtual machine examines the byte code to see which of its functions it should run. For this reason, the virtual machine is usually called an interpreter. 12 6

7 Development of Programming (cont.) INTERPRETED LANGUAGES? Programming languages such as Java, Perl, Python, Tcl/Tk, etc. are often called interpreted languages, because historically they have always been used only in virtual machines. However, more and more compilers are becoming available for these languages, which produce native machine code from the source code. For this reason, calling a language interpreted or compiled is on the way out, as a given language can be used in both environments. 13 Topic 3: History of Compilers 14 7

8 Development of Compilers Machine code No need for processing, used directly Assembly code: Translated to machine code via a direct mapping (e.g., replace symbol MOV with hex code 0A BC Comments dropped during mapping High level programs Initial approaches wrote compiler in machine code, with knowledge of the programming language coded directly. Later approaches separated language structure from the code, using the notion of grammars: PROGRAM begin STATEMENT* end STATEMENT VAR = EXPR ; print EXPR EXPR VAR NUM EXPR + EXPR etc. 15 Evolution of Bugs The term bug was used to refer to hardware problems as early as 1878, e.g., Thomas Edison to a friend: It has been just so in all of my inventions. The first step is an intuition, and comes with a burst, then difficulties arise this thing gives out and [it is] then that "Bugs" as such little faults and difficulties are called show themselves. Regularly applied to problems in radar electronics during WW II First computer bug: 1947: Working on a prototype of the Mark II, at Harvard, an operator finds the first computer "bug," logged at 15:45 hours on September 9, 1947, a moth that had caused a relay failure. 1962: NASA Mariner 1 went off-course during launch : four people died when exposed to lethal doses of radiation from Therac- 25 linear accelerator machines, used for treatment of cancer. Software errors caused machines to incorrectly calculate the amount of radiation being delivered to the patient. 1989: A computer in Paris read files on traffic violations and then mistakenly sent out letters charging 41,000 traffic offenders with crimes including murder, drug trafficking, extortion, and prostitution. Recipients were described as "surprised." 16 8

9 Topic 4: How Compilers Work 17 How does a compiler work? A compiler can be viewed in two parts: 1. Source : which takes as input source code as a sequence of characters, and interprets it as a structure of symbols (vars, values, operators, etc.) 2. Object Generator: which takes the structural analysis from (1) and produces runnable code as output. 18 9

10 How does a compiler work? A compiler can be viewed in two parts: 1. Source : which takes as input source code as a sequence of characters, and interprets it as a structure of symbols (vars, values, operators, etc.) 2. Object Generator: which takes the structural analysis from (1) and produces runnable code as output. Source 19 How does a compiler work? A compiler can be viewed in two parts: 1. Source : which takes as input source code as a sequence of characters, and interprets it as a structure of symbols (vars, values, operators, etc.) 2. Object Generator: which takes the structural analysis from (1) and produces runnable code as output. Source Generat or Object 20 10

11 How does a compiler work? A compiler can be viewed in two parts: 1. Source : which takes as input source code as a sequence of characters, and interprets it as a structure of symbols (vars, values, operators, etc.) 2. Object Generator: which takes the structural analysis from (1) and produces runnable code as output. The Source is machine-independent, while the Object Generator needs to be produce different code for each machine-type, and is thus machine-dependent. 21 How does a compiler work? A compiler can be viewed in two parts: 1. Source : which takes as input source code as a sequence of characters, and interprets it as a structure of symbols (vars, values, operators, etc.) 2. Object Generator: which takes the structural analysis from (1) and produces runnable code as output. The Source is machine-independent, while the Object Generator needs to be produce different code for each machine-type, and is thus machine-dependent. (1) is often called the front-end of the compiler, and (2) the back-end 22 11

12 How does a compiler work? The Front End typically has three stages: Lexical Analysis: accepts the source code as a sequence of chars, outputs the code as a sequence of tokens. Syntax : interprets the program tokens as a structured program. Semantic : checks that variables are instantiated before use, etc. FRONT END Source Lexical Syntactic Semantic 23 The Lexical FRONT END Source Lexical Syntactic Semantic 24 12

13 Lexical : Also called tokeniser, scanner, or in Spanish, morphological analyser Main task: recognise which character sequences are tokens (variables, values, operators, etc.) E.g., A := 100; A, :=, 100, ; Secondary task: tag each token by its type, e.g., identifier entifier, reserved- word, integer eger, etc. begin int A; A := 100; A := A+A; output A End How does a compiler work? (reserved-word,begin) (type, int)(<id>,a)(<symb>,;) (<id>,a)(<mult-symb>,:=) (<cons int>,100)(<symb>,;) (<id>,a)(<mult-symb>,:=) (<id>,a)(<symb>,+)(<id>,a)(<symb>,;) (reserved-word,output)(<id>,a) (reserved-word,end) 25 Parts of translators / compilers Lexical analyser The tokens recognised in lexical analysis are usually of the following types: Identifiers Reserved words (e.g. for, while ) Numeric constants (integers, real numbers, etc.) Literal (or string) constants. Simple symbols: operators (+, -, *, ), separators (;,., ) Multiple symbols: operators (+=, -=, ) These tokens, together with their types, become the atoms (terminals) of the next stage, syntactic analysis

14 Parts of translators / compilers Lexical analyser Other tasks done in lexical analysis: Remove excess blank-spaces and comments. Detect lexical errors: Badly formed symbols Badly formed identifiers Badly formed constants. Badly formed comments. 27 Parts of translators / Compilers Lexical analyser: example The figure shows an example of morphological analysis of a program correctly written in the programming language asple. The morphological analyser returns, as syntactic units, pairs with: The name of the unit (reserved-word, identifier, symbol, multiplesymbol ) The char sequence from the source that corresponds to that unit. begin int A; A := 100; A := A+A; output A end AM (reserved-word,begin) (type, int)(<id>,a)(<symb>,;) (<id>,a)(<mult-symb>,:=) (<cons int>,100)(<symb>,;) (<id>,a)(<mult-symb>,:=) (<id>,a)(<symb>,+)(<id>,a)(<symb>,;) (reserved-word,output)(<id>,a) (reserved-word,end) 28 14

15 The Syntactic FRONT END Source Lexical Syntactic Semantic 29 Syntactic Also called parser Inputs: the tokenised program produced by lexical analyser Resources: A grammar defining the structure of the language PROGRAM begin STATEMENT* end STATEMENT VAR = EXPR ; print EXPR EXPR VAR NUM EXPR + EXPR etc. Outputs: a structural representation of the program, showing, e.g., that tokens group into a statement, that statements group into a block, etc. This data structure is called a Parse Tree, or sometimes an Intermediate Representation. The parse tree is a language independent structure, which gives a great deal of flexibility to the code generator

16 Parts of translators / compilers Syntactic analyses: example <Program> begin <declrcns> ; <stmts> end <declrcn> <statement> ; <stmts> <type> <ids> <assignment> <statement> ; <stmts> int <id> <id> := <expr> <asignment> <statement> A.Sintáctico (<palabra clave>,begin) (<tipo>,int)(<id>,a)(<simb>,;) A A <const.int> <id> := <expr> <outputstmt> 100 A <expr> + <expr> output<expr> <id> <id> <id> (<id>,a)(<simbm>,:=) (<cons int>,100)(<simb>,;) (<id>,a)(<simbm>,:=) (<id>,a)(<simb>,+)(<id>,a)(<simb>,;) (<palabra clave>,output)(<id>,a) (palabra clave>,end) A A A 31 Syntactic : Syntactic Other functions: It is also responsible for identifying syntactic errors in the code. i.e. places where a sequence of tokens does not match the syntax rules of the language, e.g., Missing ; at the end of a statement in Java 32 16

17 Parts of translators / compilers Lexical vs. Syntactic analyser The distinction between lexical analyser and syntax analyser is somewhat arbitrary: It should be possible to write a context-independent grammar and implement a pushdown automata that recognises the complete language. However, some of the syntactic elements of programming languages (e.g. comments, constants, names) belong to a simpler type of languages, and are usually easy to describe with regular expressions, and thence they are recognisable with finite automatas. Therefore, it is usually a good idea to split the analysis in two steps. 33 The Semantic FRONT END Source Lexical Syntactic Semantic 34 17

18 Semantic Semantic : Can perform checks on program consistency: Operations have arguments of allowed types variables are initialised before referenced, correct number of arguments to function calls, etc. Typically a global view of the program 35 The Symbol Table FRONT END Source Lexical Syntactic Semantic Symbol Table 36 18

19 Parts of translators / compilers The symbols table is a table whose aim is to store all the information necessary to determine that the program is correct, and to generate the code: Names and types of variables. Names of procedures, and types of arguments and return values. Names of objects, packages, modules Shared between the 3 modules of the front end FRONT END Symbols table Lexical Syntactic Semantic Symbol Table 37 Parts of translators / compilers Symbols table Definition: the symbol table is a data structure which holds information on the identifiers in the program (variable names, function names, etc.). Implementation: The symbol table is usually implemented with a data structure (typically a hash table), to allow for efficient execution of: Introducing information Retrieving information 38 19

20 Parts of translators / compilers Symbols table: example The symbols table may have the following content begin int A; A := 100; A := A+A; output A endm.a Syntactic Anal. Element <id> Type int Value A 39 The Front End Summary of Front End : FRONT END Source Lexical Syntactic Semantic Symbol Table 40 20

21 The Back End The Back End typically has two stages: Generator: Generates object code from parse tree (typically machine code) Optimiser: recognises structures in the machine code which can be made more efficient, and changes them BACK END Generator Optimiser Object 41 The Back End The Back End sometimes has an initial pre-processing step, which: breaks any expressions into their simplest components. For example, the assignment: a := * 3 would be broken into: temp := 2 * 3; a := 1 + temp; Such expressions are called Binary Expressions. Such expressions facilitate the generation of assembler language code. Compilers that translate from one high level language to another often do not contain this step. This step sometimes also performs machine independent optimizations

22 The Back End A different back-end is required for each object language, Distinct code to generate Optimisation depends on target language Each target machine type has different machine code. Thus, the back end differs for each machine type BACK END 1 Generator 1 Optimiser 1 Object 1 BACK END 2 Generator 2 Optimiser 2 Object 2 43 Optimisation: Parts of translators / Compilers The Back End It is difficult for a compiler to generate the target code in a way that fully takes advantage of the resources (memory, cache, CPU ) in a efficient way. These last modules try to reorganise and rewrite portions of the code in order to mitigate this problem

23 Optimisation : EXAMPLE The translator might have generated, initially, the following version of the program in assembler. The optimiser might realise that, in this case, the management of arithmetic expressions has produced two instructions that are redundant (as the value is already in EAX) and can be removed. Parts of translators / Compilers The Back End segment.data _A dd 0 segment.codigo global _main _main: push dword 100 pop eax mov [_A], eax push dword [_A] push dword [_A] POP edx POP eax add eax,edx push eax pop eax mov [_A], eax push dword [_A] pop eax push eax call imprime_entero add esp, 4 call imprime_fin_linea ret 45 Optimisation : EXAMPLE The translator might have generated, initially, the following version of the program in assembler. The optimiser might realise that, in this case, the management of arithmetic expressions has produced two instructions that are redundant (as the value is already in EAX) and can be removed. Parts of translators / Compilers The Back End segment.data _A dd 0 segment.codigo global _main _main: push dword 100 pop eax mov [_A], eax push dword [_A] POP edx add eax,edx push eax pop eax mov [_A], eax push dword [_A] pop eax push eax call imprime_entero add esp, 4 call imprime_fin_linea ret 46 23

24 Parts of Translators / Compilers Error recovery Error recovery: Most translators are not only used for translating from a high-level programming language into other language. They are also a tool for software development, showing the programmer the bugs in their program Therefore, one of the major functions of translators is the diagnostic they provide in case of coding mistakes. Compilers should also be designed so that they don t just stop at the first bug, but can recover from the error, and locate other bugs. 47 Parts of Translators / Compilers Complete example begin int A; A := 100; A := A+A; output A end Source AM Syntactic A. Generation, Optimisation, Memory Magmt. segment.data _A dd 0 segment.codigo global _main _main: push dword 100 pop eax mov [_A], eax push dword [_A] POP edx add eax,edx push eax pop eax mov [_A], eax push dword [_A] pop eax push eax call imprime_entero add esp, 4 call imprime_fin_linea ret (<palabra clave>,begin) (<tipo>,int)(<id>,a)(<simb>,;) Object (<id>,a)(<simbm>,:=) (<cons int>,100)(<simb>,;) (<id>,a)(<simbm>,:=) (<id>,a)(<simb>,+)(<id>,a)(<simb>,;) (<palabra clave>,output)(<id>,a) (palabra clave>,end) 48 24

25 Topic 5: Interpreters 49 Compilers vs. Interpreters General concepts The back end of a compiler translates the internal representation of the program into object code in a file. An interpreter can have the same front end, but rather than converting the internal representation, it knows how to execute it directly. An interpreter thus allows for on the fly execution of lines of code provided by a programmer. Sometimes used in an interactive environment with a user But also allows for scripts (source code) to be executed as a program without intervening compilation

26 Compilers vs. Interpreters Example If a session of an interpreter received, from the user, the program statements from the previous examples Interpreter Window Input begin int A; A := 100; A := A+A; output A Session start int A := 100 A := A + A Session end Output Main parts of an interpreter: Symbols table Morphological analyser Syntax analyser Semantic analyser execution Memory management Interpreters Parts of an interpreter 52 26

27 Topic 6: Other Topics 53 Other concepts Single and multiple Pass Compilers Pass: Complete revision of the source program, for any specific purpose. One-pass compiler: Compiler that performs all the translation with just one pass over the source code. Many-passes compiler: Compiler that performed more than one pass. These usually impose less restrictions to the source language