<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 3.2 Final//EN">
<HTML>
<HEAD>
- <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.9">
- <TITLE>SDCC Compiler User Guide: Reporting Bugs</TITLE>
+ <META NAME="GENERATOR" CONTENT="SGML-Tools 1.0.7">
+ <TITLE>SDCC Compiler User Guide: Retargetting for other MCUs.</TITLE>
<LINK HREF="SDCCUdoc-27.html" REL=next>
<LINK HREF="SDCCUdoc-25.html" REL=previous>
<LINK HREF="SDCCUdoc.html#toc26" REL=contents>
<A HREF="SDCCUdoc-25.html">Previous</A>
<A HREF="SDCCUdoc.html#toc26">Contents</A>
<HR>
-<H2><A NAME="Bugs"></A> <A NAME="s26">26. Reporting Bugs</A> </H2>
+<H2><A NAME="Retargetting"></A> <A NAME="s26">26. Retargetting for other MCUs.</A> </H2>
-<P>Shoot of an email to 'sandeep.dutta@usa.net', as a matter of principle
-I always reply to all email's sent to me. Bugs will be fixed ASAP. When reporting
-a bug , it is useful to include a small snippet of code that is causing the
-problem, if possible compile your program with the --dumpall option and send
-the dump files along with the bug report.
+<P>The issues for retargetting the compiler are far too numerous to be covered
+by this document. What follows is a brief description of each of the seven
+phases of the compiler and its MCU dependency.
+<P>
+<OL>
+<LI>Parsing the source and building the annotated parse tree. This phase is
+largely MCU independent (except for the language extensions). Syntax &
+semantic checks are also done in this phase , along with some initial optimizations
+like back patching labels and the pattern matching optimizations like bit-rotation
+etc.</LI>
+<LI>The second phase involves generating an intermediate code which can be
+easy manipulated during the later phases. This phase is entirely MCU independent.
+The intermediate code generation assumes the target machine has unlimited number
+of registers, and designates them with the name iTemp. The compiler can be
+made to dump a human readable form of the code generated by using the --dumpraw
+option.</LI>
+<LI>This phase does the bulk of the standard optimizations and is also MCU
+independent. This phase can be broken down into several sub-phases.
+<UL>
+<LI>Break down intermediate code (iCode) into basic blocks.</LI>
+<LI>Do control flow & data flow analysis on the basic blocks.</LI>
+<LI>Do local common subexpression elimination, then global subexpression elimination</LI>
+<LI>dead code elimination</LI>
+<LI>loop optimizations</LI>
+<LI>if loop optimizations caused any changes then do 'global subexpression
+elimination' and 'dead code elimination' again.</LI>
+</UL>
+</LI>
+<LI>This phase determines the live-ranges; by live range I mean those iTemp
+variables defined by the compiler that still survive after all the optimizations.
+Live range analysis is essential for register allocation, since these computation
+determines which of these iTemps will be assigned to registers, and for how
+long.</LI>
+<LI>Phase five is register allocation. There are two parts to this process
+.
+<OL>
+<LI>The first part I call 'register packing' (for lack of a better term) .
+In this case several MCU specific expression folding is done to reduce register
+pressure.</LI>
+<LI>The second part is more MCU independent and deals with allocating registers
+to the remaining live ranges. A lot of MCU specific code does creep into this
+phase because of the limited number of index registers available in the 8051.</LI>
+</OL>
+</LI>
+<LI>The Code generation phase is (unhappily), entirely MCU dependent and very
+little (if any at all) of this code can be reused for other MCU. However the
+scheme for allocating a homogenized assembler operand for each iCode operand
+may be reused.</LI>
+<LI>As mentioned in the optimization section the peep-hole optimizer is rule
+based system, which can reprogrammed for other MCUs.</LI>
+</OL>
<HR>
<A HREF="SDCCUdoc-27.html">Next</A>
<A HREF="SDCCUdoc-25.html">Previous</A>
projects / fw / sdcc / blobdiff