git.gag.com Git - fw/sdcc/blob - doc/SDCCUdoc-26.html

   1 <!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
   2 <HTML>
   3 <HEAD>
   4  <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
   5  <TITLE>SDCC Compiler User Guide: Retargetting for other MCUs.</TITLE>
   6  <LINK HREF="SDCCUdoc-27.html" REL=next>
   7  <LINK HREF="SDCCUdoc-25.html" REL=previous>
   8  <LINK HREF="SDCCUdoc.html#toc26" REL=contents>
   9 </HEAD>
  10 <BODY>
  11 <A HREF="SDCCUdoc-27.html">Next</A>
  12 <A HREF="SDCCUdoc-25.html">Previous</A>
  13 <A HREF="SDCCUdoc.html#toc26">Contents</A>
  14 <HR>
  15 <H2><A NAME="Retargetting"></A> <A NAME="s26">26. Retargetting for other MCUs.</A> </H2>
  16
  17 <P>The issues for retargetting the compiler are far too numerous to be covered
  18 by this document. What follows is a brief description of each of the seven
  19 phases of the compiler and its MCU dependency.
  20 <P>
  21 <OL>
  22 <LI>Parsing the source and building the annotated parse tree. This phase is
  23 largely MCU independent (except for the language extensions). Syntax &amp;
  24 semantic checks are also done in this phase , along with some initial optimizations
  25 like back patching labels and the pattern matching optimizations like bit-rotation
  26 etc.</LI>
  27 <LI>The second phase involves generating an intermediate code which can be
  28 easy manipulated during the later phases. This phase is entirely MCU independent.
  29 The intermediate code generation assumes the target machine has unlimited number
  30 of registers, and designates them with the name iTemp. The compiler can be
  31 made to dump a human readable form of the code generated by using the --dumpraw
  32 option.</LI>
  33 <LI>This phase does the bulk of the standard optimizations and is also MCU
  34 independent. This phase can be broken down into several sub-phases.
  35 <UL>
  36 <LI>Break down intermediate code (iCode) into basic blocks.</LI>
  37 <LI>Do control flow &amp; data flow analysis on the basic blocks.</LI>
  38 <LI>Do local common subexpression elimination, then global subexpression elimination</LI>
  39 <LI>dead code elimination</LI>
  40 <LI>loop optimizations</LI>
  41 <LI>if loop optimizations caused any changes then do 'global subexpression
  42 elimination' and 'dead code elimination' again.</LI>
  43 </UL>
  44 </LI>
  45 <LI>This phase determines the live-ranges; by live range I mean those iTemp
  46 variables defined by the compiler that still survive after all the optimizations.
  47 Live range analysis is essential for register allocation, since these computation
  48 determines which of these iTemps will be assigned to registers, and for how
  49 long.</LI>
  50 <LI>Phase five is register allocation. There are two parts to this process
  51 .
  52 <OL>
  53 <LI>The first part I call 'register packing' (for lack of a better term) .
  54 In this case several MCU specific expression folding is done to reduce register
  55 pressure.</LI>
  56 <LI>The second part is more MCU independent and deals with allocating registers
  57 to the remaining live ranges. A lot of MCU specific code does creep into this
  58 phase because of the limited number of index registers available in the 8051.</LI>
  59 </OL>
  60 </LI>
  61 <LI>The Code generation phase is (unhappily), entirely MCU dependent and very
  62 little (if any at all) of this code can be reused for other MCU. However the
  63 scheme for allocating a homogenized assembler operand for each iCode operand
  64 may be reused.</LI>
  65 <LI>As mentioned in the optimization section the peep-hole optimizer is rule
  66 based system, which can reprogrammed for other MCUs.</LI>
  67 </OL>
  68 <HR>
  69 <A HREF="SDCCUdoc-27.html">Next</A>
  70 <A HREF="SDCCUdoc-25.html">Previous</A>
  71 <A HREF="SDCCUdoc.html#toc26">Contents</A>
  72 </BODY>
  73 </HTML>