From 826d1afd58c2e064a9c8fdb09eda1b08469de1a8 Mon Sep 17 00:00:00 2001 From: pommicket Date: Fri, 18 Feb 2022 12:36:57 -0500 Subject: newer version of tcc almost working --- 05/tcc-0.9.25/tcc-doc.html | 2241 -------------------------------------------- 1 file changed, 2241 deletions(-) delete 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 deleted file mode 100644 index e40532e..0000000 --- a/05/tcc-0.9.25/tcc-doc.html +++ /dev/null @@ -1,2241 +0,0 @@ - - - - - -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