%TOPIC%

From LRDE

Revision as of 14:11, 9 June 2014 by Clément Démoulins (talk | contribs) (Ccmp logs)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


This page contains the log of the topics of

for AppIng1 students of class EPITA 2015 (i.e., from November 2012 to April 2013). The topic was started with the Formal Languages Course (THL).


CMP 1 (%roland%)

Lecture 1: 2012-11-22, 1.5 hours: Introduction to the Project

  1. The Tiger Project. See the lecture notes (everything except section 4, ``The Tiger Compiler):

tiger-project-intro.pdf, tiger-project-intro-handout.pdf and tiger-project-intro-handout-4.pdf.

    1. Ressources (http://www.lrde.epita.fr/~akim/ccmp/).
      1. Assignments (http://www.lrde.epita.fr/~akim/ccmp/assignments.html).
      2. Appel's books.
      3. Tiger Compiler Reference Manual (http://www.lrde.epita.fr/~akim/ccmp/tiger.html).
      4. epita.cours.compile.
    2. Goals (C++, OO, DP, Management, Several Iterations, Testing, Documenting, Maintaining, Fixing, Understanding Computers, English).
    3. Non goals (Compiler Construction).
    4. Rules of the Game.
      1. No copy between groups.
      2. Tests are part of the project (test cases and frameworks should not be exchanged).
      3. Fixing mistakes earlier is better.
      4. Work between groups is encouraged as long as they don't cheat.

Lecture 2: 2012-11-29, 1.5 hours: Introduction to Compilers, Development Tools

  1. The Tiger Project. See the lecture notes (section 4, ``The Tiger Compiler):

tiger-project-intro.pdf, tiger-project-intro-handout.pdf and tiger-project-intro-handout-4.pdf.

    1. C Compilation model (cpp, cc1, as, ld).
    2. Tiger Compiler pipeline
    3. Compilers handling multiple input (sources languages) and multiple outputs (target assembly languages/processors).
      1. The case of GCC.
      2. Factoring the compiler components: intermediate representation(s).
      3. Front-end and back-ends.
    4. Other compilation strategies.
    5. The Tiger Compiler pipe (annotated with tools and steps).
      1. Front-end: TC-0 - TC-3 (mandatory part), TC-4 - TC-5 (optional part).
      2. Back-end: TC-6 - TC-9 (optional part).
    6. Misc: students should overcome Make, Makefiles and separate compilation, etc.
  1. Development Tools, section 1 (tc Tasks). See the lecture notes:

dev-tools.pdf, dev-tools-handout.pdf and dev-tools-handout-4.pdf.

    1. tc architecture and tasks

Lecture 3: 2012-12-20, 3 hours: Scanner and Parser Hints, Development Tools

  1. Additional details and hints about the scanner and the parser: The Scanner and the Parser. See the lecture notes:

scanner.pdf, scanner-handout.pdf and scanner-handout-4.pdf.

    1. Symbols (light-weight, shared and non-mutable strings used to represent identifiers).
    2. Extra information (in addition to tokens/terminals) passed between the scanner and the parser.
      1. Semantic values.
      2. Locations.
    3. Various improvements on the scanner and the parser.
      1. Error recovery by deletion (using the error symbol).
      2. Pure (reentrant) parser and scanner.
  1. Development Tools, section 3 (Tools for the Developer). See the lecture notes:

dev-tools.pdf, dev-tools-handout.pdf and dev-tools-handout-4.pdf.

Lecture 4: 2013-01-11, 3 hours: Development Tools, Introduction to Abstract Syntax

  1. Autoconf and Automake
    1. History: Unix, Unices, configuration systems (imake, configure), portability issues (broken tools, broken/missing functions, libraries, etc.).
    2. Generating configure with Autoconf
      1. The choice of (a subset of) the Bourne Shell for portability reasons.
      2. Generating to encapsulate tests, simplify, shorten and reuse shell script bits.
      3. Using the M4 macro language.
      4. Autotools Diagram: Autoconf.
    3. Generating Makefile (s) with Automake and configure.
      1. Generating to simplify and shorten portable Makefile bits.
      2. Substituting variables (@VAR@) in Makefile.in using configure (BTW: variables listed in configure --help).
      3. Completing the Autotools diagram: Automake.
      4. Developer side vs User side.
    4. A word on aclocal.
    5. Hands-on example.
      1. A simple program.
        1. Writing hello-world.cc.
        2. Adding Makefile.am.
        3. Running autoscan.
        4. Adjusting config.scan to create config.ac (initializing Automake, avoiding autoheader).
        5. Running alocal, automake -a -c (and installing helpers) and autoconf.
        6. Running ./configure.
        7. Running make.
        8. Running ./hello-world.
      2. Adding a (static) library.
        1. Writing the client (hello.cc) and the library (greet.hh and greet.cc).
        2. Adjusting Makefile.am (lib_LIBRARIES vs noinst_LIBRARIES), and configure.ac (AC_PROG_RANLIB).
        3. Updating by running make (and not the Autotools).
        4. Compiling the client (hello) by adjusting Makefile.am (in particular, link to libgreet.a using hello_LDADD).
        5. Running make again.
        6. Running ./hello.
      3. Adding tests.
        1. A word on Tests.
          1. Tests matter.
          2. Rules.
            1. A bug => a test.
            2. A suspicious behavior => one or several tests to isolate it.
            3. Don't throw away tests!
            4. Don't exchange tests! (bis repetita).
        2. TESTS in Makefile.am and make check.
        3. Compiling test-only (not installed) programs: check_PROGRAMS.
      4. Distributing.
        1. make dist.
        2. make distcheck.
        3. Don't forget to adjust the arguments of AC_INIT in configure.ac.
      5. Installing.
        1. make install.
        2. configure --prefix, $prefix, $bindir, $libdir, etc. and bin_, lib_ prefixes of primaries (PROGRAMS, LIBRARIES, etc.).
        3. make uninstall (careful, very limited).
    6. Misc.
      1. Generating tests with configure (e.g. so that they can find $srcdir).
      2. Changing variables (e.g. CXXFLAGS) at the configuration step (=./configure CXXFLAGS...=; global) or at the build step (=make CXXFLAGS...=; local).
      3. autoheader and config.h: getting rid of limitations of using -D options to pass options to the compiler.
      4. Pros and cons of using multiple Makefile s in a multi-directory project.
      5. srcdir vs builddir, running configure from a directory other than the source dir.
    7. The big picture: a diagram of the Autotools
  2. Development Tools, section 2 (Maintaining Packages). See the lecture notes:

dev-tools.pdf, dev-tools-handout.pdf and dev-tools-handout-4.pdf.

  1. Abstract Syntax: introduction (presentation of the outline, differences between parse trees and abstract syntax trees). See the lecture notes,

ast.pdf, ast-handout.pdf and ast-handout-4.pdf.

Lecture 5: 2013-02-07, 3 hours: Abstract Syntax

  1. Abstract Syntax, up to the section 2.3 (``Visitors), included. See the lecture notes,

ast.pdf, ast-handout.pdf and ast-handout-4.pdf.

Lecture 6: 2013-02-14, 3 hours: Abstract Syntax, Names, Identifiers and Bindings

  1. Abstract Syntax, up to the end. See the lecture notes,

ast.pdf, ast-handout.pdf and ast-handout-4.pdf.

  1. Names, Identifiers and Bindings, except section 3 (``Complications) . See the lecture notes,

names.pdf, names-handout.pdf and names-handout-4.pdf.

TYLA (%roland%)

Lecture 1: 2013-02-22, 3 hours: History of Computing, History of Programming Languages

Lecture 2: 2013-03-01, 3 hours: History of Programming Languages, Object Oriented History

Lecture 3: 2013-03-14, 3 hours: Subprograms, Some Traits of Functional Programming Languages, Types

Lecture 4: 2013-03-21, 3 hours: Types, Generic Programming

  1. Types. See the lecture notes (section 2.2),

type-checking.pdf, type-checking-handout.pdf and type-checking-handout-4.pdf.

  1. Generic Programming. See the lecture notes,

generic.pdf, generic-handout.pdf and generic-handout-4.pdf.

  1. More on GP, concepts and links between GP and OOP.
    • OOP vs GP
      • OOP: two levels: Interfaces and classes (compile time), instances (run time).
      • GP: three levels: Concepts (documentation/design time), models/types (compile time) and instances (run time).
      • Constraint through interface inheritance (OOP) vs lack of explicit constraint (classic GP) or implicit/explicit concept checking (C++ concept proposal)


-- %roland% - 27 Mar 2013