From e900dd8d6f2ff7cef66fbd31898d375b71ef53d6 Mon Sep 17 00:00:00 2001 From: pommicket Date: Thu, 17 Feb 2022 13:22:13 -0500 Subject: procuding a (non-working) executable for tcc --- 05/tcc-0.9.25/tcc-doc.html | 2241 ++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 2241 insertions(+) create mode 100644 05/tcc-0.9.25/tcc-doc.html (limited to '05/tcc-0.9.25/tcc-doc.html') diff --git a/05/tcc-0.9.25/tcc-doc.html b/05/tcc-0.9.25/tcc-doc.html new file mode 100644 index 0000000..e40532e --- /dev/null +++ b/05/tcc-0.9.25/tcc-doc.html @@ -0,0 +1,2241 @@ + + + + + +Tiny C Compiler Reference Documentation + + + + + + + + + + + + + + + + + + + + + +
[Top][Contents][Index][ ? ]
+

Tiny C Compiler Reference Documentation

+ +

This manual documents version of the Tiny C Compiler. +

+ + + + + + + + + +
1. Introduction   Introduction to tcc. +
2. Command line invocation   Invocation of tcc (command line, options). +
3. C language support   ANSI C and extensions. +
4. TinyCC Assembler   Assembler syntax. +
5. TinyCC Linker   Output file generation and supported targets. +
6. TinyCC Memory and Bound checks   Automatic bounds-checking of C code. +
7. The libtcc library   The libtcc library. +
8. Developer's guide   Guide for Developers. +
+ + +
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

1. Introduction

+ +

TinyCC (aka TCC) is a small but hyper fast C compiler. Unlike other C +compilers, it is meant to be self-relying: you do not need an +external assembler or linker because TCC does that for you. +

+

TCC compiles so fast that even for big projects Makefiles may +not be necessary. +

+

TCC not only supports ANSI C, but also most of the new ISO C99 +standard and many GNUC extensions including inline assembly. +

+

TCC can also be used to make C scripts, i.e. pieces of C source +that you run as a Perl or Python script. Compilation is so fast that +your script will be as fast as if it was an executable. +

+

TCC can also automatically generate memory and bound checks +(see section TinyCC Memory and Bound checks) while allowing all C pointers operations. TCC can do +these checks even if non patched libraries are used. +

+

With libtcc, you can use TCC as a backend for dynamic code +generation (see section The libtcc library). +

+

TCC mainly supports the i386 target on Linux and Windows. There are alpha +ports for the ARM (arm-tcc) and the TMS320C67xx targets +(c67-tcc). More information about the ARM port is available at +http://lists.gnu.org/archive/html/tinycc-devel/2003-10/msg00044.html. +

+

For usage on Windows, see also tcc-win32.txt. +

+
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

2. Command line invocation

+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

2.1 Quick start

+ +
 
usage: tcc [options] [infile1 infile2…] [‘-run’ infile args…]
+
+ +

TCC options are a very much like gcc options. The main difference is that TCC +can also execute directly the resulting program and give it runtime +arguments. +

+

Here are some examples to understand the logic: +

+
+
‘tcc -run a.c’
+

Compile ‘a.c’ and execute it directly +

+
+
‘tcc -run a.c arg1’
+

Compile a.c and execute it directly. arg1 is given as first argument to +the main() of a.c. +

+
+
‘tcc a.c -run b.c arg1’
+

Compile ‘a.c’ and ‘b.c’, link them together and execute them. arg1 is given +as first argument to the main() of the resulting program. +

+
+
‘tcc -o myprog a.c b.c’
+

Compile ‘a.c’ and ‘b.c’, link them and generate the executable ‘myprog’. +

+
+
‘tcc -o myprog a.o b.o’
+

link ‘a.o’ and ‘b.o’ together and generate the executable ‘myprog’. +

+
+
‘tcc -c a.c’
+

Compile ‘a.c’ and generate object file ‘a.o’. +

+
+
‘tcc -c asmfile.S’
+

Preprocess with C preprocess and assemble ‘asmfile.S’ and generate +object file ‘asmfile.o’. +

+
+
‘tcc -c asmfile.s’
+

Assemble (but not preprocess) ‘asmfile.s’ and generate object file +‘asmfile.o’. +

+
+
‘tcc -r -o ab.o a.c b.c’
+

Compile ‘a.c’ and ‘b.c’, link them together and generate the object file ‘ab.o’. +

+
+
+ +

Scripting: +

+

TCC can be invoked from scripts, just as shell scripts. You just +need to add #!/usr/local/bin/tcc -run at the start of your C source: +

+
 
#!/usr/local/bin/tcc -run
+#include <stdio.h>
+
+int main() 
+{
+    printf("Hello World\n");
+    return 0;
+}
+
+ +

TCC can read C source code from standard input when ‘-’ is used in +place of ‘infile’. Example: +

+
 
echo 'main(){puts("hello");}' | tcc -run -
+
+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

2.2 Option summary

+ +

General Options: +

+
+
‘-v’
+

Display current TCC version, increase verbosity. +

+
+
‘-c’
+

Generate an object file (‘-o’ option must also be given). +

+
+
‘-o outfile’
+

Put object file, executable, or dll into output file ‘outfile’. +

+
+
‘-Bdir’
+

Set the path where the tcc internal libraries can be found (default is +‘PREFIX/lib/tcc’). +

+
+
‘-bench’
+

Output compilation statistics. +

+
+
‘-run source [args...]’
+

Compile file source and run it with the command line arguments +args. In order to be able to give more than one argument to a +script, several TCC options can be given after the +‘-run’ option, separated by spaces. Example: +

+
 
tcc "-run -L/usr/X11R6/lib -lX11" ex4.c
+
+ +

In a script, it gives the following header: +

+
 
#!/usr/local/bin/tcc -run -L/usr/X11R6/lib -lX11
+#include <stdlib.h>
+int main(int argc, char **argv)
+{
+    ...
+}
+
+ +
+
+ +

Preprocessor options: +

+
+
‘-Idir’
+

Specify an additional include path. Include paths are searched in the +order they are specified. +

+

System include paths are always searched after. The default system +include paths are: ‘/usr/local/include’, ‘/usr/include’ +and ‘PREFIX/lib/tcc/include’. (‘PREFIX’ is usually +‘/usr’ or ‘/usr/local’). +

+
+
‘-Dsym[=val]’
+

Define preprocessor symbol ‘sym’ to +val. If val is not present, its value is ‘1’. Function-like macros can +also be defined: ‘-DF(a)=a+1’ +

+
+
‘-Usym’
+

Undefine preprocessor symbol ‘sym’. +

+
+ +

Compilation flags: +

+

Note: each of the following warning options has a negative form beginning with +‘-fno-’. +

+
+
‘-funsigned-char’
+

Let the char type be unsigned. +

+
+
‘-fsigned-char’
+

Let the char type be signed. +

+
+
‘-fno-common’
+

Do not generate common symbols for uninitialized data. +

+
+
‘-fleading-underscore’
+

Add a leading underscore at the beginning of each C symbol. +

+
+
+ +

Warning options: +

+
+
‘-w’
+

Disable all warnings. +

+
+
+ +

Note: each of the following warning options has a negative form beginning with +‘-Wno-’. +

+
+
‘-Wimplicit-function-declaration’
+

Warn about implicit function declaration. +

+
+
‘-Wunsupported’
+

Warn about unsupported GCC features that are ignored by TCC. +

+
+
‘-Wwrite-strings’
+

Make string constants be of type const char * instead of char +*. +

+
+
‘-Werror’
+

Abort compilation if warnings are issued. +

+
+
‘-Wall’
+

Activate all warnings, except ‘-Werror’, ‘-Wunusupported’ and +‘-Wwrite-strings’. +

+
+
+ +

Linker options: +

+
+
‘-Ldir’
+

Specify an additional static library path for the ‘-l’ option. The +default library paths are ‘/usr/local/lib’, ‘/usr/lib’ and ‘/lib’. +

+
+
‘-lxxx’
+

Link your program with dynamic library libxxx.so or static library +libxxx.a. The library is searched in the paths specified by the +‘-L’ option. +

+
+
‘-shared’
+

Generate a shared library instead of an executable (‘-o’ option +must also be given). +

+
+
‘-static’
+

Generate a statically linked executable (default is a shared linked +executable) (‘-o’ option must also be given). +

+
+
‘-rdynamic’
+

Export global symbols to the dynamic linker. It is useful when a library +opened with dlopen() needs to access executable symbols. +

+
+
‘-r’
+

Generate an object file combining all input files (‘-o’ option must +also be given). +

+
+
‘-Wl,-Ttext,address’
+

Set the start of the .text section to address. +

+
+
‘-Wl,--oformat,fmt’
+

Use fmt as output format. The supported output formats are: +

+
elf32-i386
+

ELF output format (default) +

+
binary
+

Binary image (only for executable output) +

+
coff
+

COFF output format (only for executable output for TMS320C67xx target) +

+
+ +
+
+ +

Debugger options: +

+
+
‘-g’
+

Generate run time debug information so that you get clear run time +error messages: test.c:68: in function 'test5()': dereferencing +invalid pointer instead of the laconic Segmentation +fault. +

+
+
‘-b’
+

Generate additional support code to check +memory allocations and array/pointer bounds. ‘-g’ is implied. Note +that the generated code is slower and bigger in this case. +

+
+
‘-bt N’
+

Display N callers in stack traces. This is useful with ‘-g’ or +‘-b’. +

+
+
+ +

Note: GCC options ‘-Ox’, ‘-fx’ and ‘-mx’ are +ignored. +

+ +
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

3. C language support

+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

3.1 ANSI C

+ +

TCC implements all the ANSI C standard, including structure bit fields +and floating point numbers (long double, double, and +float fully supported). +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

3.2 ISOC99 extensions

+ +

TCC implements many features of the new C standard: ISO C99. Currently +missing items are: complex and imaginary numbers and variable length +arrays. +

+

Currently implemented ISOC99 features: +

+ + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

3.3 GNU C extensions

+ +

TCC implements some GNU C extensions: +

+ + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

3.4 TinyCC extensions

+ + + +
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

4. TinyCC Assembler

+ +

Since version 0.9.16, TinyCC integrates its own assembler. TinyCC +assembler supports a gas-like syntax (GNU assembler). You can +desactivate assembler support if you want a smaller TinyCC executable +(the C compiler does not rely on the assembler). +

+

TinyCC Assembler is used to handle files with ‘.S’ (C +preprocessed assembler) and ‘.s’ extensions. It is also used to +handle the GNU inline assembler with the asm keyword. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

4.1 Syntax

+ +

TinyCC Assembler supports most of the gas syntax. The tokens are the +same as C. +

+ + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

4.2 Expressions

+ + + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

4.3 Labels

+ + + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

4.4 Directives

+ +

All directives are preceeded by a '.'. The following directives are +supported: +

+ + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

4.5 X86 Assembler

+ +

All X86 opcodes are supported. Only ATT syntax is supported (source +then destination operand order). If no size suffix is given, TinyCC +tries to guess it from the operand sizes. +

+

Currently, MMX opcodes are supported but not SSE ones. +

+
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

5. TinyCC Linker

+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

5.1 ELF file generation

+ +

TCC can directly output relocatable ELF files (object files), +executable ELF files and dynamic ELF libraries without relying on an +external linker. +

+

Dynamic ELF libraries can be output but the C compiler does not generate +position independent code (PIC). It means that the dynamic library +code generated by TCC cannot be factorized among processes yet. +

+

TCC linker eliminates unreferenced object code in libraries. A single pass is +done on the object and library list, so the order in which object files and +libraries are specified is important (same constraint as GNU ld). No grouping +options (‘--start-group’ and ‘--end-group’) are supported. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

5.2 ELF file loader

+ +

TCC can load ELF object files, archives (.a files) and dynamic +libraries (.so). +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

5.3 PE-i386 file generation

+ +

TCC for Windows supports the native Win32 executable file format (PE-i386). It +generates EXE files (console and gui) and DLL files. +

+

For usage on Windows, see also tcc-win32.txt. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

5.4 GNU Linker Scripts

+ +

Because on many Linux systems some dynamic libraries (such as +‘/usr/lib/libc.so’) are in fact GNU ld link scripts (horrible!), +the TCC linker also supports a subset of GNU ld scripts. +

+

The GROUP and FILE commands are supported. OUTPUT_FORMAT +and TARGET are ignored. +

+

Example from ‘/usr/lib/libc.so’: +

 
/* GNU ld script
+   Use the shared library, but some functions are only in
+   the static library, so try that secondarily.  */
+GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a )
+
+ +
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

6. TinyCC Memory and Bound checks

+ +

This feature is activated with the ‘-b’ (see section Command line invocation). +

+

Note that pointer size is unchanged and that code generated +with bound checks is fully compatible with unchecked +code. When a pointer comes from unchecked code, it is assumed to be +valid. Even very obscure C code with casts should work correctly. +

+

For more information about the ideas behind this method, see +http://www.doc.ic.ac.uk/~phjk/BoundsChecking.html. +

+

Here are some examples of caught errors: +

+
+
Invalid range with standard string function:
+
 
{
+    char tab[10];
+    memset(tab, 0, 11);
+}
+
+ +
+
Out of bounds-error in global or local arrays:
+
 
{
+    int tab[10];
+    for(i=0;i<11;i++) {
+        sum += tab[i];
+    }
+}
+
+ +
+
Out of bounds-error in malloc'ed data:
+
 
{
+    int *tab;
+    tab = malloc(20 * sizeof(int));
+    for(i=0;i<21;i++) {
+        sum += tab4[i];
+    }
+    free(tab);
+}
+
+ +
+
Access of freed memory:
+
 
{
+    int *tab;
+    tab = malloc(20 * sizeof(int));
+    free(tab);
+    for(i=0;i<20;i++) {
+        sum += tab4[i];
+    }
+}
+
+ +
+
Double free:
+
 
{
+    int *tab;
+    tab = malloc(20 * sizeof(int));
+    free(tab);
+    free(tab);
+}
+
+ +
+
+ +
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

7. The libtcc library

+ +

The libtcc library enables you to use TCC as a backend for +dynamic code generation. +

+

Read the ‘libtcc.h’ to have an overview of the API. Read +‘libtcc_test.c’ to have a very simple example. +

+

The idea consists in giving a C string containing the program you want +to compile directly to libtcc. Then you can access to any global +symbol (function or variable) defined. +

+
+ + + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8. Developer's guide

+ +

This chapter gives some hints to understand how TCC works. You can skip +it if you do not intend to modify the TCC code. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.1 File reading

+ +

The BufferedFile structure contains the context needed to read a +file, including the current line number. tcc_open() opens a new +file and tcc_close() closes it. inp() returns the next +character. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.2 Lexer

+ +

next() reads the next token in the current +file. next_nomacro() reads the next token without macro +expansion. +

+

tok contains the current token (see TOK_xxx) +constants. Identifiers and keywords are also keywords. tokc +contains additional infos about the token (for example a constant value +if number or string token). +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.3 Parser

+ +

The parser is hardcoded (yacc is not necessary). It does only one pass, +except: +

+ + +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.4 Types

+ +

The types are stored in a single 'int' variable. It was choosen in the +first stages of development when tcc was much simpler. Now, it may not +be the best solution. +

+
 
#define VT_INT        0  /* integer type */
+#define VT_BYTE       1  /* signed byte type */
+#define VT_SHORT      2  /* short type */
+#define VT_VOID       3  /* void type */
+#define VT_PTR        4  /* pointer */
+#define VT_ENUM       5  /* enum definition */
+#define VT_FUNC       6  /* function type */
+#define VT_STRUCT     7  /* struct/union definition */
+#define VT_FLOAT      8  /* IEEE float */
+#define VT_DOUBLE     9  /* IEEE double */
+#define VT_LDOUBLE   10  /* IEEE long double */
+#define VT_BOOL      11  /* ISOC99 boolean type */
+#define VT_LLONG     12  /* 64 bit integer */
+#define VT_LONG      13  /* long integer (NEVER USED as type, only
+                            during parsing) */
+#define VT_BTYPE      0x000f /* mask for basic type */
+#define VT_UNSIGNED   0x0010  /* unsigned type */
+#define VT_ARRAY      0x0020  /* array type (also has VT_PTR) */
+#define VT_BITFIELD   0x0040  /* bitfield modifier */
+
+#define VT_STRUCT_SHIFT 16   /* structure/enum name shift (16 bits left) */
+
+ +

When a reference to another type is needed (for pointers, functions and +structures), the 32 - VT_STRUCT_SHIFT high order bits are used to +store an identifier reference. +

+

The VT_UNSIGNED flag can be set for chars, shorts, ints and long +longs. +

+

Arrays are considered as pointers VT_PTR with the flag +VT_ARRAY set. +

+

The VT_BITFIELD flag can be set for chars, shorts, ints and long +longs. If it is set, then the bitfield position is stored from bits +VT_STRUCT_SHIFT to VT_STRUCT_SHIFT + 5 and the bit field size is stored +from bits VT_STRUCT_SHIFT + 6 to VT_STRUCT_SHIFT + 11. +

+

VT_LONG is never used except during parsing. +

+

During parsing, the storage of an object is also stored in the type +integer: +

+
 
#define VT_EXTERN  0x00000080  /* extern definition */
+#define VT_STATIC  0x00000100  /* static variable */
+#define VT_TYPEDEF 0x00000200  /* typedef definition */
+
+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.5 Symbols

+ +

All symbols are stored in hashed symbol stacks. Each symbol stack +contains Sym structures. +

+

Sym.v contains the symbol name (remember +an idenfier is also a token, so a string is never necessary to store +it). Sym.t gives the type of the symbol. Sym.r is usually +the register in which the corresponding variable is stored. Sym.c is +usually a constant associated to the symbol. +

+

Four main symbol stacks are defined: +

+
+
define_stack
+

for the macros (#defines). +

+
+
global_stack
+

for the global variables, functions and types. +

+
+
local_stack
+

for the local variables, functions and types. +

+
+
global_label_stack
+

for the local labels (for goto). +

+
+
label_stack
+

for GCC block local labels (see the __label__ keyword). +

+
+
+ +

sym_push() is used to add a new symbol in the local symbol +stack. If no local symbol stack is active, it is added in the global +symbol stack. +

+

sym_pop(st,b) pops symbols from the symbol stack st until +the symbol b is on the top of stack. If b is NULL, the stack +is emptied. +

+

sym_find(v) return the symbol associated to the identifier +v. The local stack is searched first from top to bottom, then the +global stack. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.6 Sections

+ +

The generated code and datas are written in sections. The structure +Section contains all the necessary information for a given +section. new_section() creates a new section. ELF file semantics +is assumed for each section. +

+

The following sections are predefined: +

+
+
text_section
+

is the section containing the generated code. ind contains the +current position in the code section. +

+
+
data_section
+

contains initialized data +

+
+
bss_section
+

contains uninitialized data +

+
+
bounds_section
+
lbounds_section
+

are used when bound checking is activated +

+
+
stab_section
+
stabstr_section
+

are used when debugging is actived to store debug information +

+
+
symtab_section
+
strtab_section
+

contain the exported symbols (currently only used for debugging). +

+
+
+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.7 Code generation

+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.7.1 Introduction

+ +

The TCC code generator directly generates linked binary code in one +pass. It is rather unusual these days (see gcc for example which +generates text assembly), but it can be very fast and surprisingly +little complicated. +

+

The TCC code generator is register based. Optimization is only done at +the expression level. No intermediate representation of expression is +kept except the current values stored in the value stack. +

+

On x86, three temporary registers are used. When more registers are +needed, one register is spilled into a new temporary variable on the stack. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.7.2 The value stack

+ +

When an expression is parsed, its value is pushed on the value stack +(vstack). The top of the value stack is vtop. Each value +stack entry is the structure SValue. +

+

SValue.t is the type. SValue.r indicates how the value is +currently stored in the generated code. It is usually a CPU register +index (REG_xxx constants), but additional values and flags are +defined: +

+
 
#define VT_CONST     0x00f0
+#define VT_LLOCAL    0x00f1
+#define VT_LOCAL     0x00f2
+#define VT_CMP       0x00f3
+#define VT_JMP       0x00f4
+#define VT_JMPI      0x00f5
+#define VT_LVAL      0x0100
+#define VT_SYM       0x0200
+#define VT_MUSTCAST  0x0400
+#define VT_MUSTBOUND 0x0800
+#define VT_BOUNDED   0x8000
+#define VT_LVAL_BYTE     0x1000
+#define VT_LVAL_SHORT    0x2000
+#define VT_LVAL_UNSIGNED 0x4000
+#define VT_LVAL_TYPE     (VT_LVAL_BYTE | VT_LVAL_SHORT | VT_LVAL_UNSIGNED)
+
+ +
+
VT_CONST
+

indicates that the value is a constant. It is stored in the union +SValue.c, depending on its type. +

+
+
VT_LOCAL
+

indicates a local variable pointer at offset SValue.c.i in the +stack. +

+
+
VT_CMP
+

indicates that the value is actually stored in the CPU flags (i.e. the +value is the consequence of a test). The value is either 0 or 1. The +actual CPU flags used is indicated in SValue.c.i. +

+

If any code is generated which destroys the CPU flags, this value MUST be +put in a normal register. +

+
+
VT_JMP
+
VT_JMPI
+

indicates that the value is the consequence of a conditional jump. For VT_JMP, +it is 1 if the jump is taken, 0 otherwise. For VT_JMPI it is inverted. +

+

These values are used to compile the || and && logical +operators. +

+

If any code is generated, this value MUST be put in a normal +register. Otherwise, the generated code won't be executed if the jump is +taken. +

+
+
VT_LVAL
+

is a flag indicating that the value is actually an lvalue (left value of +an assignment). It means that the value stored is actually a pointer to +the wanted value. +

+

Understanding the use VT_LVAL is very important if you want to +understand how TCC works. +

+
+
VT_LVAL_BYTE
+
VT_LVAL_SHORT
+
VT_LVAL_UNSIGNED
+

if the lvalue has an integer type, then these flags give its real +type. The type alone is not enough in case of cast optimisations. +

+
+
VT_LLOCAL
+

is a saved lvalue on the stack. VT_LLOCAL should be eliminated +ASAP because its semantics are rather complicated. +

+
+
VT_MUSTCAST
+

indicates that a cast to the value type must be performed if the value +is used (lazy casting). +

+
+
VT_SYM
+

indicates that the symbol SValue.sym must be added to the constant. +

+
+
VT_MUSTBOUND
+
VT_BOUNDED
+

are only used for optional bound checking. +

+
+
+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.7.3 Manipulating the value stack

+ +

vsetc() and vset() pushes a new value on the value +stack. If the previous vtop was stored in a very unsafe place(for +example in the CPU flags), then some code is generated to put the +previous vtop in a safe storage. +

+

vpop() pops vtop. In some cases, it also generates cleanup +code (for example if stacked floating point registers are used as on +x86). +

+

The gv(rc) function generates code to evaluate vtop (the +top value of the stack) into registers. rc selects in which +register class the value should be put. gv() is the most +important function of the code generator. +

+

gv2() is the same as gv() but for the top two stack +entries. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.7.4 CPU dependent code generation

+

See the ‘i386-gen.c’ file to have an example. +

+
+
load()
+

must generate the code needed to load a stack value into a register. +

+
+
store()
+

must generate the code needed to store a register into a stack value +lvalue. +

+
+
gfunc_start()
+
gfunc_param()
+
gfunc_call()
+

should generate a function call +

+
+
gfunc_prolog()
+
gfunc_epilog()
+

should generate a function prolog/epilog. +

+
+
gen_opi(op)
+

must generate the binary integer operation op on the two top +entries of the stack which are guaranted to contain integer types. +

+

The result value should be put on the stack. +

+
+
gen_opf(op)
+

same as gen_opi() for floating point operations. The two top +entries of the stack are guaranted to contain floating point values of +same types. +

+
+
gen_cvt_itof()
+

integer to floating point conversion. +

+
+
gen_cvt_ftoi()
+

floating point to integer conversion. +

+
+
gen_cvt_ftof()
+

floating point to floating point of different size conversion. +

+
+
gen_bounded_ptr_add()
+
gen_bounded_ptr_deref()
+

are only used for bounds checking. +

+
+
+ +
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

8.8 Optimizations done

+

Constant propagation is done for all operations. Multiplications and +divisions are optimized to shifts when appropriate. Comparison +operators are optimized by maintaining a special cache for the +processor flags. &&, || and ! are optimized by maintaining a special +'jump target' value. No other jump optimization is currently performed +because it would require to store the code in a more abstract fashion. +

+
+ + + + + + + + + + + + + + + + +
[ < ][ > ]   [ << ][ Up ][ >> ]         [Top][Contents][Index][ ? ]
+

Concept Index

+
Jump to:   _ +   +
+A +   +B +   +C +   +D +   +E +   +F +   +G +   +I +   +J +   +L +   +M +   +O +   +P +   +Q +   +R +   +S +   +T +   +U +   +V +   +W +   +
+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Index Entry Section
_
__asm__3.3 GNU C extensions
A
align directive4.4 Directives
aligned attribute3.3 GNU C extensions
ascii directive4.4 Directives
asciz directive4.4 Directives
assembler4.5 X86 Assembler
assembler directives4.4 Directives
assembly, inline3.3 GNU C extensions
B
bound checks6. TinyCC Memory and Bound checks
bss directive4.4 Directives
byte directive4.4 Directives
C
caching processor flags8.8 Optimizations done
cdecl attribute3.3 GNU C extensions
code generation8.7 Code generation
comparison operators8.8 Optimizations done
constant propagation8.8 Optimizations done
CPU dependent8.7.4 CPU dependent code generation
D
data directive4.4 Directives
directives, assembler4.4 Directives
dllexport attribute3.3 GNU C extensions
E
ELF5.1 ELF file generation
F
FILE, linker command5.4 GNU Linker Scripts
fill directive4.4 Directives
flags, caching8.8 Optimizations done
G
gas3.3 GNU C extensions
global directive4.4 Directives
globl directive4.4 Directives
GROUP, linker command5.4 GNU Linker Scripts
I
inline assembly3.3 GNU C extensions
int directive4.4 Directives
J
jump optimization8.8 Optimizations done
L
linker5. TinyCC Linker
linker scripts5.4 GNU Linker Scripts
long directive4.4 Directives
M
memory checks6. TinyCC Memory and Bound checks
O
optimizations8.8 Optimizations done
org directive4.4 Directives
OUTPUT_FORMAT, linker command5.4 GNU Linker Scripts
P
packed attribute3.3 GNU C extensions
PE-i3865.3 PE-i386 file generation
previous directive4.4 Directives
Q
quad directive4.4 Directives
R
regparm attribute3.3 GNU C extensions
S
scripts, linker5.4 GNU Linker Scripts
section attribute3.3 GNU C extensions
section directive4.4 Directives
short directive4.4 Directives
skip directive4.4 Directives
space directive4.4 Directives
stdcall attribute3.3 GNU C extensions
strength reduction8.8 Optimizations done
string directive4.4 Directives
T
TARGET, linker command5.4 GNU Linker Scripts
text directive4.4 Directives
U
unused attribute3.3 GNU C extensions
V
value stack8.7.3 Manipulating the value stack
value stack, introduction8.7.2 The value stack
W
word directive4.4 Directives
+
Jump to:   _ +   +
+A +   +B +   +C +   +D +   +E +   +F +   +G +   +I +   +J +   +L +   +M +   +O +   +P +   +Q +   +R +   +S +   +T +   +U +   +V +   +W +   +
+ +
+ + + + + + +
[Top][Contents][Index][ ? ]
+

Table of Contents

+
+ + +
+
+ + + + + + +
[Top][Contents][Index][ ? ]
+

About This Document

+

+ This document was generated by gr on May, 18 2009 using texi2html 1.78. +

+

+ The buttons in the navigation panels have the following meaning: +

+ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Button Name Go to From 1.2.3 go to
[ < ] BackPrevious section in reading order1.2.2
[ > ] ForwardNext section in reading order1.2.4
[ << ] FastBackBeginning of this chapter or previous chapter1
[ Up ] UpUp section1.2
[ >> ] FastForwardNext chapter2
[Top] TopCover (top) of document  
[Contents] ContentsTable of contents  
[Index] IndexIndex  
[ ? ] AboutAbout (help)  
+ +

+ where the Example assumes that the current position is at Subsubsection One-Two-Three of a document of the following structure: +

+ + + +
+

+ + This document was generated by gr on May, 18 2009 using texi2html 1.78. + +
+ +

+ + -- cgit v1.2.3