Compiler-CampusMinden · cagix · Aug 22, 2024 · Aug 22, 2024 · Aug 22, 2024 · Aug 22, 2024
@@ -1,7 +1,7 @@
 * @cagix
 /homework/ @bcg7 @cagix
-/lecture/frontend/lexing/regular.md @bcg7 @cagix
-/lecture/frontend/parsing/cfg.md @bcg7 @cagix
-/lecture/frontend/parsing/ll-parser.md @bcg7 @cagix
-/lecture/frontend/semantics/attribgrammars.md @bcg7 @cagix
-/lecture/backend/minipython-builder.md @bcg7 @cagix
+/lecture/01-lexing/regular.md @bcg7 @cagix
+/lecture/02-parsing/cfg.md @bcg7 @cagix
+/lecture/02-parsing/ll-parser.md @bcg7 @cagix
+/lecture/03-semantics/attribgrammars.md @bcg7 @cagix
+/lecture/07-codegen/minipython-builder.md @bcg7 @cagix
@@ -273,5 +273,5 @@ Citations of "99 Bottles of Beer" lyrics and programming language examples (lice
 *   ["Language Java"](https://www.99-bottles-of-beer.net/language-java-4.html) by Sean Russell on 99-bottles-of-beer.net
 *   ["Language Prolog"](https://www.99-bottles-of-beer.net/language-prolog-965.html) by M\@ on 99-bottles-of-beer.net
 *   ["Language Haskell"](https://www.99-bottles-of-beer.net/language-haskell-1070.html) by Iavor on 99-bottles-of-beer.net
-*   Screenshot of ["Language Brainfuck"](https://99-bottles-of-beer.net/language-brainfuck-2542.html) by Michal Wojciech Tarnowski on 99-bottles-of-beer.net (file [`screenshot_brainfuck_99bottles.png`](https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/intro/images/screenshot_brainfuck_99bottles.png))
+*   Screenshot of ["Language Brainfuck"](https://99-bottles-of-beer.net/language-brainfuck-2542.html) by Michal Wojciech Tarnowski on 99-bottles-of-beer.net (file [`screenshot_brainfuck_99bottles.png`](https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/00-intro/images/screenshot_brainfuck_99bottles.png))
 :::
@@ -16,7 +16,7 @@ tldr: |
   von Stufe zu Stufe zu: Der ursprüngliche Input ist ein Strom von Zeichen, daraus wird ein
   Strom von Wörtern (Token), daraus ein Baum (Parse Tree), Zwischencode (IC), ...
 
-  ![](https://raw.githubusercontent.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/master/lecture/intro/images/architektur_cb.png)
+  ![](https://raw.githubusercontent.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/master/lecture/00-intro/images/architektur_cb.png)
 
   Die gezeigten Phasen werden traditionell unterschieden. Je nach Aufgabe können verschiedene
   Stufen zusammengefasst werden oder sogar gar nicht auftreten.

@@ -4,8 +4,8 @@ title: "Überblick"
 ---
 
 
-Was ist ein Compiler? Welche Bausteine lassen sich identifizieren,
-welche Aufgaben haben diese?
+Was ist ein Compiler? Welche Bausteine lassen sich identifizieren, welche Aufgaben haben
+diese?
 
 
 `{{< children showhidden="true" >}}`{=markdown}

@@ -282,7 +282,7 @@ GREETING    : [a-zA-Z]+ ;
 WHITESPACE  : [ \t\n]+ -> skip ;
 ```
 
-[Konsole: Hello (Classpath, Aliase, grun, Main, Dateien, Ausgabe)]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/frontend/lexing/src/Hello.g4"}
+[Konsole: Hello (Classpath, Aliase, grun, Main, Dateien, Ausgabe)]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/01-lexing/src/Hello.g4"}
 
 
 ::::::::: notes
@@ -374,7 +374,7 @@ zurückgeben lassen. (Diese Methode wird letztlich vom Parser benutzt.)
 
 Die restlichen Dateien werden für den Parser und verschiedene Arten der
 Traversierung des AST generiert (vgl.
-[AST-basierte Interpreter](../../backend/interpretation/astdriven-part1.md)).
+[AST-basierte Interpreter](../06-interpretation/astdriven-part1.md)).
 
 ### Bedeutung der Ausgabe
 
@@ -441,7 +441,7 @@ hello
     Rekursive Lexer-Regeln sind erlaubt. **Achtung**: Es dürfen keine
     _links-rekursiven_ Regeln genutzt werden, etwa wie `ID : ID '*' ID ;` ...
     (Eine genauere Definition und die Transformation in nicht-linksrekursive
-    Regeln siehe [LL-Parser](../parsing/ll-parser.md)).
+    Regeln siehe [LL-Parser](../02-parsing/ll-parser.md)).
 
 *   Alle Literale werden in _einfache_ Anführungszeichen eingeschlossen
     (es erfolgt keine Unterscheidung zwischen einzelnen Zeichen und Strings

@@ -1,12 +1,12 @@
 ---
 archetype: "default"
-title: "Lexer"
+title: "Lexikalische Analyse"
 ---
 
 
-Der Lexer (auch "Scanner") soll den Zeichenstrom in eine Folge von Token
-zerlegen. Zur Spezifikation der Token werden in der Regel reguläre Ausdrücke
-verwendet.
+In der lexikalischen Analyse soll ein Lexer (auch "Scanner") den Zeichenstrom in eine
+Folge von Token zerlegen. Zur Spezifikation der Token werden in der Regel reguläre
+Ausdrücke verwendet.
 
 
 `{{< children showhidden="true" >}}`{=markdown}

@@ -108,7 +108,7 @@ NUM   : [0-9]+ ;
 WS    : [ \t\n]+ -> skip ;
 ```
 
-[Konsole: Hello (grun, Parse-Tree)]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/frontend/parsing/src/Hello.g4"}
+[Konsole: Hello (grun, Parse-Tree)]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/02-parsing/src/Hello.g4"}
 
 ::::::::: notes
 ### Starten des Parsers
@@ -524,9 +524,9 @@ public class TestMyListener {
 }
 ```
 
-[Beispiel: TestMyListener.java und calc.g4]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/frontend/parsing/src/TestMyListener.java"}
+[Beispiel: TestMyListener.java und calc.g4]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/02-parsing/src/TestMyListener.java"}
 
-In [Syntaxgesteuerte Interpreter](../../backend/interpretation/syntaxdriven.md)
+In [Syntaxgesteuerte Interpreter](../06-interpretation/syntaxdriven.md)
 werden wir damit einen einfachen syntaxgesteuerten Interpreter aufbauen.
 :::
 
@@ -601,9 +601,9 @@ public class TestMyVisitor {
 }
 ```
 
-[Beispiel: TestMyVisitor.java und calc.g4]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/frontend/parsing/src/TestMyVisitor.java"}
+[Beispiel: TestMyVisitor.java und calc.g4]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/02-parsing/src/TestMyVisitor.java"}
 
-In [Syntaxgesteuerte Interpreter](../../backend/interpretation/syntaxdriven.md)
+In [Syntaxgesteuerte Interpreter](../06-interpretation/syntaxdriven.md)
 werden wir damit einen einfachen syntaxgesteuerten Interpreter aufbauen.
 :::
 
@@ -629,9 +629,9 @@ hinzu, welches man im jeweiligen Kontext abfragen bzw. setzen kann (agiert
 als Rückgabewert der generierten Methode). Auf diesen Wert kann in den
 Aktionen mit `$v` zugegriffen werden.
 
-In [Attributierte Grammatiken](../semantics/attribgrammars.md)
+In [Attributierte Grammatiken](../03-semantics/attribgrammars.md)
 werfen wir einen genaueren Blick auf die attributierten Grammatiken. In
-[Syntaxgesteuerte Interpreter](../../backend/interpretation/syntaxdriven.md)
+[Syntaxgesteuerte Interpreter](../06-interpretation/syntaxdriven.md)
 werden wir eingebettete Aktionen und Attribute nutzen, um einen einfachen
 syntaxgesteuerten Interpreter aufzubauen.
 

@@ -0,0 +1,27 @@
+---
+archetype: "default"
+title: "Syntaktische Analyse"
+---
+
+
+In der syntaktischen Analyse arbeitet ein Parser mit dem Tokenstrom, der vom Lexer kommt.
+Mit Hilfe einer Grammatik wird geprüft, ob gültige Sätze im Sinne der Sprache/Grammatik
+gebildet wurden. Der Parser erzeugt dabei den Parse-Tree. Man kann verschiedene Parser
+unterscheiden, beispielsweise die LL- und die LR-Parser.
+
+
+`{{< children showhidden="true" >}}`{=markdown}
+
+
+
+
+
+
+
+<!-- DO NOT REMOVE - THIS IS A LAST SLIDE TO INDICATE THE LICENSE AND POSSIBLE EXCEPTIONS (IMAGES, ...). -->
+::: slides
+## LICENSE
+![](https://licensebuttons.net/l/by-sa/4.0/88x31.png)
+
+Unless otherwise noted, this work is licensed under CC BY-SA 4.0.
+:::
@@ -0,0 +1,36 @@
+---
+archetype: "default"
+title: "Semantische Analyse"
+---
+
+
+Auf die lexikalische Analyse und die Syntaxanalyse folgt die semantische Analyse. Nach dem
+Parsen steht fest, dass ein Programm syntaktisch korrekt ist. Nun muss geprüft werden, ob
+es auch semantisch korrekt ist. Dazu gehören u.a. die Identifikation und Sammlung von
+Bezeichnern und die Zuordnung zur richtigen Ebene (Scopes) sowie die die Typ-Prüfung
+und -Inferenz.
+
+In dieser Phase zeigen sich die Eigenschaften der zu verarbeitenden Sprache sehr deutlich,
+beispielsweise müssen Bezeichner deklariert sein vor der ersten Benutzung, welche Art von
+Scopes soll es geben, gibt es Klassen und Vererbung ...
+
+Da hier der Kontext der Symbole eine Rolle spielt, wird diese Phase oft auch "Context Handling"
+oder "Kontext Analyse" bezeichnet. Neben attributierten Grammatiken sind die Symboltabellen
+wichtige Werkzeuge.
+
+
+`{{< children showhidden="true" >}}`{=markdown}
+
+
+
+
+
+
+
+<!-- DO NOT REMOVE - THIS IS A LAST SLIDE TO INDICATE THE LICENSE AND POSSIBLE EXCEPTIONS (IMAGES, ...). -->
+::: slides
+## LICENSE
+![](https://licensebuttons.net/l/by-sa/4.0/88x31.png)
+
+Unless otherwise noted, this work is licensed under CC BY-SA 4.0.
+:::
@@ -1,7 +1,6 @@
 ---
 archetype: lecture-cg
-title: "Semantische Analyse: Symboltabellen"
-linkTitle: "Überblick Symboltabellen"
+title: "SymbTab0: Überblick Symboltabellen"
 author: "Carsten Gips (HSBI)"
 readings:
   - key: "Mogensen2017"
@@ -72,7 +71,7 @@ Nach der Syntaxanalyse braucht der Compiler für die  darauf folgenden Phasen
 Auf dem Weg zum Interpreter/Compiler müssen die Symbole im AST korrekt zugeordnet
 werden. Dies geschieht über Symboltabellen. Im Folgenden werden wir verschiedene
 Aspekte von Symboltabellen betrachten und eine mögliche Implementierung erarbeiten,
-bevor wir uns (in [Syntaxgesteuerte Interpreter](../../../backend/interpretation/syntaxdriven.md))
+bevor wir uns (in [Syntaxgesteuerte Interpreter](../06-interpretation/syntaxdriven.md))
 um die Auswertung (Interpretation) des AST kümmern können.
 
 ### Logische Compilierungsphasen
@@ -174,7 +173,7 @@ Typen bestimmt oder angepasst werden können, müssen Bezeichner zunächst ident
 werden, d.h. bei namensgleichen Bezeichnern der richtige Bezug bestimmt werden.
 
 Zu Annotationen/Attributen, Typen und Type-Checks siehe VL
-[Typprüfungen, Attributgrammatiken](../attribgrammars.md)!
+[Typprüfungen, Attributgrammatiken](attribgrammars.md)!
 :::
 
 \bigskip
@@ -207,7 +206,7 @@ Konvertierungen vorgenommen werden, etwa bei `3+4.1` ...
 *   Variablen werden nicht als Funktionen genutzt
 *   Funktionen werden nicht als Variablen genutzt
 
-=> Verweis auf VL [Typprüfungen, Attributgrammatiken](../attribgrammars.md)
+=> Verweis auf VL [Typprüfungen, Attributgrammatiken](attribgrammars.md)
 
 Da Funktionen bereits vor dem Bekanntmachen der Definition aufgerufen werden dürfen, bietet
 sich ein **zweimaliger Durchlauf** (*pass*) an: Beim ersten Traversieren des AST werden alle

@@ -1,6 +1,6 @@
 ---
 archetype: lecture-cg
-title: "Nested Scopes"
+title: "SymbTab1: Nested Scopes"
 author: "Carsten Gips (HSBI)"
 readings:
   - key: "Mogensen2017"

@@ -1,6 +1,6 @@
 ---
 archetype: lecture-cg
-title: "Funktionen"
+title: "SymbTab2: Funktionen"
 author: "Carsten Gips (HSBI)"
 readings:
   - key: "Mogensen2017"

@@ -1,6 +1,6 @@
 ---
 archetype: lecture-cg
-title: "Strukturen und Klassen"
+title: "SymbTab3: Strukturen und Klassen"
 author: "Carsten Gips (HSBI)"
 readings:
   - key: "Mogensen2017"

@@ -106,7 +106,7 @@ vornehmen.
 Anschließend können diverse *Writer* den AST in das gewünschte Zielformat überführen.
 :::
 
-[Konsole: pandoc hello.md -s -t native]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/intermediate/src/hello.md"}
+[Konsole: pandoc hello.md -s -t native]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/04-intermediate/src/hello.md"}
 
 
 ## Zwischenformat: Drei-Adressen-Code
@@ -203,7 +203,7 @@ define i32 @main() #0 {
 :::
 ::::::
 
-[Beispiel: clang -emit-llvm -S -o - hello.c]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/intermediate/src/hello.c"}
+[Beispiel: clang -emit-llvm -S -o - hello.c]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/04-intermediate/src/hello.c"}
 
 ::: notes
 Der obige Output ist auf die *relevanten Zeilen gekürzt*; der gesamte Output im LLVM-Format
@@ -276,7 +276,7 @@ y = x + 35
 :::
 ::::::
 
-[Beispiel: python -m dis hello.py]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/intermediate/src/hello.py"}
+[Beispiel: python -m dis hello.py]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/04-intermediate/src/hello.py"}
 
 ::: notes
 Python pflegt 3 Listen: `co_names` für die Namen plus `co_values` für die dazugehörigen Werte sowie
@@ -339,7 +339,7 @@ public class Hello {
 :::
 ::::::
 
-[Beispiel: javac Hello.java && javap -c Hello.class]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/intermediate/src/Hello.java"}
+[Beispiel: javac Hello.java && javap -c Hello.class]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/04-intermediate/src/Hello.java"}
 
 ::: notes
 Für jeden Methodenaufruf wird ein entsprechender Frame auf den Stack gepusht.
@@ -411,7 +411,7 @@ main:
 :::
 ::::::
 
-[Beispiel: gcc -S -o - hello.c]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/intermediate/src/hello.c"}
+[Beispiel: gcc -S -o - hello.c]{.bsp href="https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/04-intermediate/src/hello.c"}
 
 ::: notes
 Die Ausgabe unterscheidet sich je nach Architektur, auf dem der C-Code

@@ -8,7 +8,8 @@ Die Schnittstelle zwischen dem "Frontend" und dem "Backend" ist der "Zwischencod
 (_intermediate code_ (_IC_), auch _intermediate representation_ (_IR_) genannt).
 
 Für den Zwischencode gibt es kein allgemein definiertes Format. In der Praxis
-trifft man auf eine große Bandbreite an verschiedenen Formaten.
+trifft man auf eine große Bandbreite an verschiedenen Formaten, besonders verbreitet
+sind beispielsweise die Formate AST, SSA, LLVM-IR und MLIR.
 
 
 `{{< children showhidden="true" >}}`{=markdown}

@@ -0,0 +1,29 @@
+---
+archetype: "default"
+title: "Optimierung"
+---
+
+
+Üblicherweise finden sich die verschiedenen Optimierungsmöglichkeiten in
+der Backend-Phase. Man kann u.a. zwischen lokaler und globaler Optimierung
+oder beispielsweise JIT unterscheiden. Es kann sehr unterschiedliche Ziele
+für die Optimierung geben, beispielsweise möchte man den Code kleiner(kürzer,
+kompakter) gestalten oder die Laufzeit für das Programm verringern oder sogar
+Energieaspekte berücksichtigen.
+
+
+`{{< children showhidden="true" >}}`{=markdown}
+
+
+
+
+
+
+
+<!-- DO NOT REMOVE - THIS IS A LAST SLIDE TO INDICATE THE LICENSE AND POSSIBLE EXCEPTIONS (IMAGES, ...). -->
+::: slides
+## LICENSE
+![](https://licensebuttons.net/l/by-sa/4.0/88x31.png)
+
+Unless otherwise noted, this work is licensed under CC BY-SA 4.0.
+:::
@@ -19,7 +19,7 @@ tldr: |
 
   Der Wert von Literalen ergibt sich direkt durch die Übersetzung des jeweiligen Werts in den
   passenden Typ der Implementierungssprache. Bei einfachen Ausdrücken kann man auf das in
-  [Syntaxgesteuerte Interpreter](https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/backend/interpretation/syntaxdriven.md)
+  [Syntaxgesteuerte Interpreter](https://github.com/Compiler-CampusMinden/CB-Vorlesung-Bachelor/blob/master/lecture/06-interpretation/syntaxdriven.md)
   demonstrierte Vorgehen zurückgreifen: Man interpretiert zunächst die Teilausdrücke durch den
   Aufruf von `eval()` für die jeweiligen AST-Kindknoten und berechnet daraus das gewünschte
   Ergebnis.

@@ -6,9 +6,11 @@ title: "Interpreter"
 
 Ein Interpreter erzeugt keinen Code, sondern führt Source-Code (interaktiv) aus. Die einfachste
 Möglichkeit ist der Einsatz von attributierten Grammatiken, wo der Code bereits beim Parsen
-ausgeführt wird. Mehr Möglichkeiten hat man dagegen bei der Traversierung des AST, beispielsweise
-mit dem Visitor-Pattern. (Register- und Stack-basierte Interpreter betrachten wir im Rahmen der
-Veranstaltung aktuell nicht.)
+ausgeführt wird ("syntaxgesteuerte Interpretation"). Mehr Möglichkeiten hat man dagegen bei der
+Traversierung des AST, beispielsweise mit dem Visitor-Pattern. Auch die Abarbeitung von Bytecode
+in einer Virtuellen Maschine (VM) zählt zur Interpretation.
+
+(Register- und Stack-basierte Interpreter betrachten wir im Rahmen der Veranstaltung aktuell nicht.)
 
 
 `{{< children showhidden="true" >}}`{=markdown}