Amiga Tools 5

home *** CD-ROM | disk | FTP | other *** search

/ Amiga Tools 5 / Amiga Tools 5.iso / tools / developer-tools / c-tools / vbcc / doc / vbcc.doc < prev

Wrap

Text File | 1996-06-17 | 20.0 KB | 549 lines

vbcc - C compiler (c) in 1995-96 by Volker Barthelmann vbpp - C preprocessor (c) in 1995-96 by Thorsten Schaaps INTRODUCTION vbcc is a free portable and retargetable ANSI C compiler. It is split into a target independant and a target dependant part and supports emulating datatypes of the target machine on any other machine so that it is possible to e.g. make a crosscompiler for a 64bit machine on a 32bit machine. The target independant part generates a form of intermediate code (quads) which has to be dealt with by the code generator. This intermediate code is rather cpu independant (apart from register usage), but the target independant part of vbcc uses informations about the target machine while generating this code. If you are interested in writing a code generator for vbcc, contact me (the necessary documents are not written yet). This document only deals with the target independant parts of vbcc. Be sure to read all the documents in the doc directory for your machine. LEGAL vbcc is (c) in 1995-96 by Volker Barthelmann. The builtin preprocessor (consisting of the files preproc.c and vbpp.h) is written and (c) by Thorsten Schaaps. All other code is (c) by Volker Barthelmann. vbcc may be freely redistributed as long as no modifications are made and nothing is charged for it. Non-commercial usage of vbcc is allowed without any restrictions. Commercial usage needs my written consent. Sending me money, gifts, postcards etc. would of course be very nice and may encourage further development of vbcc, but is not legally or morally necessary to use vbcc. INSTALLATION The installation is system dependant and covered in another manual. USAGE Usually vbcc will be called by a frontend. However if you call it directly, it has to be done like this (and most of the options should be passed through to vbcc by the frontend). vbcc [options] file The following options are supported by the machine independant part of vbcc: -quiet Do not print the copyright notice. -ic1 Write the intermediate code before optimizing to file.ic1. -ic2 Write the intermediate code after optimizing to file.ic2. -debug=n Set the debug level to n. -noasm Do not generate assembler output (only for testing). -O=n Turns optimizing options on/off; every bit set in n turns on an option. (See section on optimizing.) -maxoptpasses=n Set maximum number of optimizer passes to n. (See section on optimizing.) -inline-size=n Set the maximum 'size' of functions to be inlined. (See section on optimizing.) -ansi Switch to ANSI mode. In ANSI mode every warning with ANSI violation will be an error and all other warnings are suppressed. Also assignments between pointers to type and pointers to unsigned type will be errors. -maxerrors=n Abort the compilation after n errors; do not stop if n==0. -dontwarn=n Suppress warning number n; suppress all warnings if n<0. (See the section on errors/warnings.) -warn=n Turn on warning number n; turn on all warnings if n<0. (See the section on errors/warnings.) -nested-comments Allow nested comments (not ANSI conforming). Has no effect if the builtin preprocessor is disabled. -cpp-comments Allow C++ style comments (not ANSI conforming). Has no effect if the builtin preprocessor is disabled. -macro-redefinition Allow redefinition of macros (not ANSI conforming). Has no effect if the builtin preprocessor is disabled. -no-trigraphs Prevents expansion of trigraphs (not ANSI conforming). Has no effect if the builtin preprocessor is disabled. -no-preprocessor Do not invoke the builtin preprocessor vbpp. -E Only preprocess the file and write the preprocessed source to <file>.i. The assembler output will be saved to file.asm (if file already contained a suffix, this will first be removed; same applies to .ic1/.ic2) SOME INTERNALS I try to make vbcc as ANSI compliant as possible (but this is not that easy, because I do not have the ANSI document), so I am only mentioning some things I consider interesting. First, there still may be some bugs, but vbcc seems stable now unless you use the optimizer. ERRORS/WARNINGS vbcc knows the following kinds of messages: fatal errors Something is badly wrong and further compilation is impossible or pointless. vbcc will abort. E.g. no source file or really corrupt source. errors There was an error and vbcc cannot generate useful code. Compilation continues, but no code should be generated. E.g. unknown identifiers. warnings (1) Warnings with ANSI-violations. The program is not ANSI-conforming, but vbcc will generate code that could be what you want (or not). E.g. missing semicolon. warnings (2) The code has no ANSI-violations, but contains some strange things you should perhaps look at. E.g. unused variables. Errors or the first kind of warnings are always displayed and cannot be suppressed. Only some warnings of the second kind are turned on by default. Many of them are very useful for some, but annoying to others and their usability may depend on programming style. As I do not want to force anyone to a certain style I recommend everyone to find their own preferences. A good way to do this is starting with all warnings turned on by -warn=-1 so you will see all possible warnings. Now everytime you get a warning you do not find useful, turn that one off with -dontwarn=n. The file errors.doc contains a list of all errors/warnings, sometimes with more detailed descriptions. This might be very useful, too. See the docs on your frontend on how to configure it to your preferences. DATA TYPES vbcc can handle the following atomic data types: signed/unsigned char/short/int/long (signed is always default) float/double (long double is always the same as double) However several of them can be identical in certain implementations. OPTIMIZATIONS vbcc can compile with or without global optimizations. But note that the optimizer is not yet finished and is known to generate corrupt code in some cases. So only use it with extreme care. In the first compilation phase every function is parsed into a tree structure one expression after the other. Then type-checking and some minor optimizations like constant-folding or some algebraic simplifications are done on the trees. This phase of the translation is identical in optimizing and non-optimizing compilation. Then intermediate code is generated from the trees. In non-optimizing compilation temporaries needed to evaluate the expression are immediately assigned to registers if possible. In optimizing compilation a new variable is generated for each temporary required. Also for certain constructs like loops different intermediate code is produced in optimizing compilation. Some minor optimizations are performed while generating the intermediate code (simple elimination of unreachable code, some optimizations on branches etc.). After intermediate code for the whole function has been generated simple register allocation may be done in non-optimizing compilation if bit 1 has been set in the -O option. After that the intermediate code is passed to the code generator and then all memory for the function, its variables etc. is freed. In optimizing compilation flowgraphs are constructed, data flow analysis is performed and many passes are made over the function's intermediate code. Code may be moved around, new variables may be added, other variables removed etc. etc. (for more detailed information on the performed optimizations look at the description for the -O option below). Many of the optimization routines depend on each other and if one routine finds an optimization this often enables other routines to find further ones and some routines only do a first step and let other routines 'clean up' after it. Because of this vbcc usually makes many passes until no further optimizations are found. To avoid possible extremely long optimization times the number of those passes can be limited with the -maxoptpasses=n option (the default value is max. 10 passes). Now it will be decided if the compiled function is a candidate for inlining. In this case the intermediate code as well as the data structures for the local variables will be copied and stored until compilation of the entire translation-unit has finished. After those phases register allocation should be done. As temporaries have not been assigned to registers up to this point, register allocation is crucial in optimizing compilation (actually if optimizing is desired there are rarely reasons not to turn on all flags - also note that some flags MUST be turned on or vbcc may even crash). Note that optimizing compilation can take MUCH more time and needs MUCH more memory. It is hard to predict how much time and space it needs, but usually it roughly depends on length of a function (time and space needed will usually increase more than linear with the length of a function). At the moment the following bits in the -O option are recognized: Bit 0 (1) Register allocation This is the only flag that has any effect in non-optimizing compilation. In non-optimizing compilation any registers that have never been used for temporaries in this function are used for register variables in a simple way. For each variable a priority to registerize it is computed (this has already been done during generation of intermediate code). This value usually reflects how much can be gained by putting it in a register. Then for every free register the variable with the highest priority that can be stored in that register is assigned that register for the entire function. This improves the generated code quite a bit. The effect on compile time is hard to predict, but it should be very small - this optimization may even speed up the compilation. In optimizing compilation several passes are made: - First all temporaries are assigned to registers in basic blocks. Temporaries are recognized by utilising data flow information on active variables and one variable can be a temporary at one or several points although it is alive over several basic blocks at another point. - Then vbcc computes approximate savings that can be obtained by holding a variable in a register within a loop and assigns the most used variables to registers within loops (starting with innermost loops). Information on the function's loop structure and active variables are used. - Now about the same is done for the whole function, i.e. vbcc looks for variables to put in a register for the entire function. - At last the basic blocks are scanned and if there are variables that can efficiently be put in a register for one basic block this is done (at the moment this pass is done only if bit 6 is set, but this may change in the future and bit 6 may have a different meaning then). Then instructions to copy variables from memory to a register and back are inserted when necessary. Bit 1 (2) activate optimizing compilation This flag turns on the optimizer. If it is set to zero no global optimizations will be performed no matter what the other flags are set to. When turned on slightly different intermediate code will be generated by the first translation phases. Also the following optimizations are performed: - A flow graph is constructed and unused labels are deleted. - Unreachable code is eliminated. - Jump optimizations are performed. - Several peephole optimizations like constant folding and algebraic simplifications are performed on the intermediate code. - Identical statements at the beginning/end of basic blocks are moved to the successors/predecessors under certain conditions. Bit 2 (4) common subexpression elimination The intermediate code is scanned for common subexpressions that can be eliminated. Also copy propagation is performed. This can be done only within basic blocks or over the whole function depending on bit 5. If global cse is selected data flow analysis for available expressions and available copies is performed. Example for common subexpression elimination: q(int a,int b) { if(c){ f(a+b); }else{ g(a+b); } return(a+b); } will become something like: q(int a,int b) { int t; if(c){ t=a+b; f(t); }else{ t=a+b; g(t); } return(t); } Often common subexpressions occur in array indexing where they are not as obvious to the programmer. Note that the local versions of these optimizations are only restricted versions of the global ones. They operate on the intermediate code rather than on trees and therefore are slower than they could be on compilers that only perform local versions. Bit 3 (8) constant propagation Variables which are known to have a constant value at one time are replaced by constants. This can be done only within basic blocks or over the whole function depending on bit 5. If global constant propagation is selected data flow analysis for reaching definitions is performed. Note that the local versions of these optimizations are only restricted versions of the global ones. They operate on the intermediate code rather than on trees and therefore are slower than they could be on compilers that only perform local versions. Bit 4 (16) reserved for future use Bit 5 (32) global optimization Some optimizations are available in local and global versions. This flag turns on the global versions. At the moment this effects common subexpression elimination, copy propagation and constant propagation. Also if this flag is not turned on only one optimization pass is done whereas several are done if it is turned on. Not turning on this flag results in worse code and often shorter compile time. However there are cases where this increases compile time, too. It seems reasonable to me to always turn it on. Bit 6 (64) register allocation on basic blocks/ reserved for future use See Bit 1. Bit 7 (128) reserved for future use Bit 8 (256) reserved for future use Bit 9 (512) reserved for future use Bit 10 (1024) reserved for future use Bit 11 (2048) reserved for future use Bit 12 (4096) function inlining The intermediate code of functions that meet certain conditions (mainly adjustable by -inline-size) is kept in memory for the entire translation unit and subsequent calls to this function are replaced with this code. This way constant arguments can be propagated across the function and certain parts of the function may be omitted. Also common subexpressions across the functions can be eliminated. An inlined function call is about the same as a macro expansion (but safer). Also look at the documentation for the target dependant part of vbcc. There may be additional machine specific optimization options. PRAGMA At the moment vbcc accepts the following #pragma-directives (note that case is important and commands etc. must be separated by exactly one space at the moment): #pragma type <expr>; Write the type of <expr> to stdout. This is mainly intended for testing. #pragma tree <expr>; Write the parse-tree of <expr> to stdout. This is mainly intended for testing. #pragma only-inline on The following functions are prepared for inlining, but no code is generated. This can be used e.g. in header-files to supply inline versions of certain functions. -inline-size is ignored in this mode - every function gets prepared for inlining. Do not use this with functions that have local static variables! #pragma only-inline off The following functions are translated as usual again. KNOWN PROBLEMS Some known target independant problems of vbcc at the moment: - Some size limits are still hardcoded into the source (the maximum nesting of blocks and the maximum length of input lines). - Switch statements do never use jump-tables. - Bitfields are not supported (they are always used as int) - this should be ANSI compliant, however. - The source was written with an optimizing compiler in mind and is somewhat inefficient. - Initialized data is kept in memory for the whole translation-unit. This enables some optimizations, but very much memory is needed if a translation-unit contains many initializations. - The source is not strictly ANSI conforming (i.e. fully portable), yet. E.g. there may be some external identifiers with more than 6 identical characters (haven't checked yet) and other problems. However in practice it is very portable. - Code for accessing volatile objects may not be generated if the result is not used. - Messages that do not refer to a particular line (e.g. unused variable warnings or warnings found in optimizing) get printed with a more or less random line number. - long double is not really supported (see errors.doc). - The optimizer is not finished and is not stable. THE FUTURE - Bugfixing where necessary. - Completing the builtin preprocessor - Perhaps adding possibility to use precompiled header-files. - Finishing the optimizer (fixing some bugs and adding several other optimizations - mainly loop-optimizations, alias-optimizations and interprocedural optimizations). - Certain features like register parameters. - Other code generators. - If you have any other ideas, tell me. CREDITS All those who wrote parts of the vbcc distribution, made suggestions, answered my questions, tested vbcc, reported errors or were otherwise involved in the development of vbcc (in descending alphabetical order, under work, not complete): Frank Wille Ralph Schmidt Markus Schmidinger Thorsten Schaaps Joerg Plate Gunther Nikl Joern Maass Kai Kohlmorgen Dirk Holtwick Volker Graf Matthias Fleischer Robert Ennals Thomas Dorn Walter Doerwald Lars Dannenberg Michael Bode Michael Bauer Juergen Barthelmann Thomas Arnhold Thomas Aglassinger Volker Barthelmann volker@vb.franken.de Kennedy-Ring 39 91301 Forchheim Germany