vbcc - C compiler (c) in 1995 by Volker Barthelmann INTRODUCTION vbcc shall be a free portable ANSI compliant C compiler. It is clearly split into a machine independant and a machine 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 machine 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 machine 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 machine independant parts of vbcc. Be sure to read all the documents in the doc directory for Your machine. LEGAL vbcc is (c) in 1995 by Volker Barthelmann. All code is written by me and 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 will be passed through to vbcc by the frontend). vbcc [options] file At the moment file has to be an already preprocessed C source. 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 for code (only for testing) -O=n turns optimizing options on/off; every bit set in n turns on an option; see below -ansi switch to ANSI mode; at the moment this only affects warning/error messages; in ANSI mode every warning with ANSI violation will be an error and all other warnings are suppressed. -maxerrors=n abort the compilation after n errors; do not stop if n==0 -dontwarn=n suppress warning number n 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 many many bugs, the compiler may crash, it may generate incorrect code, accept incorrect sources etc. Also it does almost no optimizing at the moment and is still very slow. DATA TYPES vbcc can handle the following 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 At the moment the following bits in the -O option are recognized: Bit 0 (1) Use simple register allocation to assign variables to registers. 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. Other Bits may be recognized by the machine dependant part of vbcc. KNOWN PROBLEMS Some known machine independant problems of vbcc at the moment: - Some size limits are still hardcoded into the source. - Switch statements are not optimized. - Bitfields are not supported (they are always used as int) - this should be ANSI compliant, however. - No own preprocessor and some problems connected with this. E.g. in error messages the name and line number of the preprocessor output will be printed rather than the original source. Also there are some cases where You cannot format Your source as freely as possible. However You probably have rather strange style if You encounter this problem. - Inefficient source. - 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. - return of structures passes a pointer to a static object; I am not sure if this is sufficient - this will probably be changed to pass the address of the destination as a function argument. - The scope of function parameters may be incorrect (will probably only occur if struct/union/enum tags are defined within a prototype). - Code for accessing volatile objects may not be generated if the result is not used. - Certain kinds of incorrect source may result in an infinite loop of error printing or worse problems - some errors will probably have to be changed to abort the translation. THE FUTURE - Bugfixing - Builtin preprocessor. Someone is already working on this. - Implementing an optimizer. This will be a rather large thing to do and I will not start before vbcc seems stable. - Certain features like register parameters. - Other code generators. - If You have any other ideas, tell me. CREDITS (in descending alphabetical order, under work, not complete) Frank Wille Markus Schmidinger Thorsten Schaaps Joerg Plate Joern Maass Kai Kohlmorgen Dirk Holtwick Volker Graf Matthias Fleischer Thomas Dorn Walter Doerwald Lars Dannenberg Michael Bode Michael Bauer Juergen Barthelmann Thomas Arnhold Volker Barthelmann volker@vb.franken.de Kennedy-Ring 39 91301 Forchheim Germany