Commits

Even Wiik Thomassen  committed 89cb2fb

.

  • Participants
  • Parent commits bb07063

Comments (0)

Files changed (4)

 \end{enumerate}
 The second goal was not realized as Haskell's syntax and semantics have never
 been formally described. The plan for the last goal was to base Haskell on an
-an existing functional language called OL. This plan was abandoned early.
+an existing functional language called OL\@. This plan was abandoned early.
 Haskell has successfully achieved the majority of the remaining goals, although
 some features such as type classes were added without regard for goal
 five~\cite{hudak}.
 The compiler is also a library, called \gls{ghc} \gls{api}, which provides
 access to internal parts of \gls{ghc} and allows working with Haskell code.
 
-\subsection{Compiling Haskell}
+\subsection{Compilation process}
 Compiling Haskell source files start with parsing with a fully functional
-parser, which produces an \gls{ast} where identifiers are simple strings.
+parser that produces an \gls{ast} where identifiers are simple strings.
+
+The second step is called \textit{renaming}, where identifiers are turned into
+fully qualified names. This step also spots duplicate declarations, rearrange
+infix expressions, collect the equations of a functions together, and more.
+
+The third step is type checking. Any program that passes the type checker is
+type-safe and guaranteed to not crash at runtime.
 
 
 \subsection{Optimization's}
 \include{extcore} % GHC's External Core
 \include{pyhaskell} % Everyhing about PyHaskell
 \include{jit} % JIT techniques (method)
-%\include{benchmarks} % Describe how we benchmark
+\include{lowlevel} % Low level code examples
+\include{benchmarks} % Describe how we benchmark
 \include{evaluation}  % (result)
 %\include{discussion}
 %\include{conclusion}

File lowlevel.tex

+%-----------------------
+\chapter{Low level code}
+%-----------------------
+
+Low level code, assembly generated by GHC, and RPython traces etc.
 The backend performs the following steps:
 \begin{itemize}
     \item Translate \gls{cmm} code to unoptimized LLVM code.
-    \item Convert variables into \gls{ssa} form, as demanded by LLVM.
+    \item Convert variables into \gls{ssa} form, as demanded by LLVM\@.
         The backend allocate each mutable \gls{cmm} variable on the stack,
         and then uses \mycode{mem2reg} from LLVM to perform \gls{ssa}
         conversion.
 
 Htrace is build with \gls{ghc} and LLVM --- traces are optimized with compiler
 optimizations provided by LLVM. \gls{ghc} required some small changes to
-enable dynamic linking of some C functions into LLVM. Htrace disables
+enable dynamic linking of some C functions into LLVM\@. Htrace disables
 \gls{ghc}'s ``tables next to code'' optimization and uses a pure
 Haskell library for integer arithmetic, \mycode{integer-simple}. Two new
 passes were added to LLVM: inserting trace instrumentation and building
 \end{table}
 
 \mytodo{TODO: maybe add a paragraph where I summarize how the different
-approaches differ from my approach.
+approaches differ from my approach.\
 draw lessons from LLVM backend to my RPython backend.
 Something about RPython backend translates from STG instead of Cmm.
 Therefor no ABI compatibility with other backends. And none of the steps
 LLVM backend takes are relevant for us. But the runtime evaluation methods
-are same/similar, and benefit that the LLVM backend provides, so do we.
+are same/similar, and benefit that the LLVM backend provides, so do we.\
 explain how we use RPython/PyPy while lambdachine ``use''
 LuaJIT, and how this makes our goals the same but different methods.
 Also his challenges.}