ghc/docs/add_to_compiler/back-end.verb

   1 %************************************************************************
   2 %*                                                                      *
   3 \subsection{The back end of the compiler}
   4 \label{sec:back-end}
   5 %*                                                                      *
   6 %************************************************************************
   7
   8 The back end of the compiler begins once the typechecker's
   9 output has been desugared into the so-called Core syntax.  Core syntax
  10 is discussed in Section~\ref{sec:core-syntax}.
  11
  12 We intend the back end to be a sequence of highly effective
  13 CoreSyntax-to-CoreSyntax and STGsyntax-to-STGsyntax transformation
  14 passes, making it possible for the
  15 CoreSyntax$\Rightarrow$StgSyntax$\Rightarrow$Abstract~C (and on to
  16 machine code) denouement to produce really good code.
  17
  18 {\em It is with these transformation passes that we are hoping for
  19 your enthusiastic help!} There are also some examples in the
  20 GHC distribution, written by people other than the original compiler
  21 authors---so it can be done...
  22
  23 We already have a pretty good {\em simplifier}\srcloc{simplCore/} to
  24 do local transformations, written mainly by Andr\'e Santos.  Among
  25 other things, it unfolds basic arithmetic operations and constants,
  26 exposing the underlying unboxed values.  Those interested in the
  27 merits of these transformations should consult Peyton Jones and
  28 Launchbury's paper, ``Unboxed values as first class citizens in a
  29 non-strict functional language'' \cite{peyton-jones91b}.
  30
  31 The reader interested in the final code-generation parts of the
  32 compiler, from Core syntax to STG syntax\srcloc{stgSyn/CoreToStg.lhs}
  33 to Abstract~C\srcloc{codeGen/}, should consult Peyton Jones's recent
  34 paper, ``Implementing lazy functional languages on stock hardware: the
  35 Spineless Tagless G-machine'' \cite{peyton-jones92a}.
  36
  37 Further note: We have found that the STG
  38 syntax\srcloc{stgSyn/StgSyn.lhs} is the better medium for a few
  39 transformations\srcloc{stgSyn/SimplStg.lhs}. This is fine---STG syntax
  40 is a just-as-manipulable functional language as Core syntax, even if
  41 it's a bit messier.