Defence Force logotype

Contents of /public/pc/tools/osdk/main/Osdk/_final_/documentation/doc_compiler.htm

Parent Directory Parent Directory | Revision Log Revision Log

Revision 1527 - (show annotations)
Sat Sep 7 09:16:40 2019 UTC (8 months, 3 weeks ago) by dbug
File MIME type: text/html
File size: 5722 byte(s)
OSDK 1.15

3 <HTML lang=fr dir=ltr>
4 <HEAD>
5 <meta name="robots" content="noindex">
6 <meta http-equiv="Content-Type" content="text/html;charset=iso-8859-1">
7 <title>OSDK - The Compiler</title>
8 <link href="documentation.css" rel="stylesheet" type="text/css">
9 </HEAD>
11 <BODY>
13 <hr>
14 <A href="documentation.htm"><img src="arrow_back.gif"></A>
15 <img src="pics/osdk_logo_small.png">
16 <hr>
18 <h1>The Compiler</h1>
20 <p id=chapter>Description</p>
21 <p>RCC16 is an Oric targeted version of the LCC Compiler.
22 </p>
24 <p>This compiler is decently ANSI compliant, and event support C++ comments as well as standard C comments.
25 </p>
28 The "official" source repository whre all the changes for the compiler are made before they reach the OSDK is Fabrice Frances' <a href="https://github.com/Oric4ever/lcc65">GitHub</a>
30 <p>Here is the primary source for the C Cross-Compiler targetting the 6502 processor that is included in the OSDK (Oric Software Development Kit). I am (Fabrice) putting it here so that it eventually becomes more familiar to people willing to maintain it in the long term...
32 <p>Also, in order to increase its maintenability, I will try to progressively document what my 6502 code generator does. If you are interested in it, the first thing to read is Hanson & Fraser's interfacing document (docs/INTERFAC.pdf): the lcc65 compiler is built from Hanson & Fraser's frontend, and my small 6502 backend (6502/src/gen.c).
34 <p>The frontend supplies the backend with forest of dags (directed acyclic graphs), the backend is responsible for code generation. The following options are accepted by the backend and affect the generated output; comparison of these outputs give a better understanding of what the backend does...
35 <ul>
36 <li><p>-G generates a graph output (in Graphviz dot format) instead of code output. The output is a representation of the forests of dags produced by the frontend, which means that the backend doesn't do any work (except transformation of Hanson & Fraser's internal structures to Graphviz dot format). For example, the visual representation of the compilation of tests/torture_test.c file gives the graph (tests/torture_test.dot), which once converted to pdf ("dot -Tpdf torture_test.dot") can be graphically seen in tests/torture_test.pdf.
38 <li><p>-O0 transforms the graph into code. More precisely, for each function, the backend first linearizes the forest of dags given by the frontend, allocates temporary variables to hold the result of operators, defines a number of "operand handling modes" (Constants, Direct, ZeroPage, Indirect, Y-Indexed) that will be used for optimizing the code in the advanced -O2 and -O3 optimizations, and generates 16-bit macro-instructions instead of 6502 opcodes in order to keep the generator small.
40 <li><p>-O1 removes the leaf nodes of the graph (ADDRG, ADDRF, ADDRL, CNST) so that their value become direct operands of the nodes above them. At the same time, this removes the need for the associated temporary variables.
42 <li><p>-O2 allocates some parameters and some local variables into "virtual-registers" in zero-page: these zero-page variables are of course faster than the normal parameters or local variables which are accessed on a software stack (i.e using indirect Y-indexed access). -O2 also does some simple optimizations like converting additions/substractions with 1 to INC/DEC operations, special treatment of 1-bit shifts or equality with 0, removal of some un-necessary conversions between chars/ints/unsigned ints, removal of function prologue/epilogue when possible.
44 <li><p>-O3 is an attempt for more agressive optimizations, trying to remove some indirection nodes (ASGN, INDIR) of usual code patterns so that addressing mode of the 16-bit macros integrates the additional indirection.
45 </ul>
46 <p>Last but not least, you have to know that the sources of the lcc frontend are very old (these are from LCC 1.9), written in K&R style (yeah!), so if you compile them you will get zillions of warnings. Moreover, I was told it is very difficult to compile them on Windows with Visual Studio, so I have added a project file for Code::Blocks in the src directory. Of course Linux users have a simple Makefile that should work on most systems.
49 <p>Optimisation level can be modified using the OSDKCOMP variable: Since OSDK 1.14 this variable will be initialized by default to -O3 value (used to be -O2).
50 </p>
53 <p id=chapter>Data types</p>
55 <p>Since the 6502 is an 8 bit processor, the data size are as follow:
57 <ul>
58 <li>Pointers are 16 bits long</li>
59 <li>char and shorts are 8 bits long</li>
60 <li>int are 16 bits long</li>
61 </ul>
64 <p id=chapter>Libraries</p>
66 <p>Some standard functions (memcpy, printf, ...) are implemented, but most of the standard library is not available.
67 </p>
69 <p>Some functions are just quick hacks done by directly calling the ROM functions.
70 Unfortunately, ROM releases are different, and thus any code calling these functions will work only on ATMOS.
71 </p>
73 <p id=chapter>Historic</p>
75 <p>Here is the list of all releases with a short description of things that changed:
76 </p>
78 <p id=dateentry>Version 1.36</p>
79 - fixes for the -O0 output
81 <p id=dateentry>Version 1.35</p>
82 - defstring is used by the frontend not only to define strings (signed char data) but also for initializing unsigned char arrays. In this case, defstring will receive char data with possible negative char values which have to be printed as their corresponding unsigned char value.
86 <hr>
87 <A href="documentation.htm"><img src="arrow_back.gif"></A>
88 <img src="pics/osdk_logo_small.png">
89 <hr>
91 </BODY>
92 </HTML>

  ViewVC Help
Powered by ViewVC 1.1.26