Go to most recent revision | Details | Last modification | View Log | RSS feed
Rev | Author | Line No. | Line |
---|---|---|---|
145 | halyavin | 1 | |
2 | |||
3 | |||
4 | |||
5 |
|
||
6 | |||
7 | |||
8 |
|
||
9 | |||
10 | |||
11 |
|
||
12 | |||
13 | |||
14 | |||
15 | |||
16 | |||
17 | |||
18 | |||
19 | |||
20 | |||
21 | |||
22 | |||
23 | |||
24 | |||
25 | |||
26 | |||
27 | |||
28 | |||
29 | |||
30 | |||
31 | |||
32 | |||
33 | |||
34 | |||
35 | |||
36 | |||
37 | |||
38 | |||
39 | |||
40 | |||
41 | |||
42 | libtcc library |
||
43 | |||
44 | |||
45 | |||
46 | |||
47 | |||
48 | |||
49 | |||
50 | |||
51 | |||
52 | |||
53 | |||
54 | |||
55 | |||
56 | |||
57 | |||
58 | |||
59 | |||
60 | |||
61 | |||
62 | |||
63 | |||
64 | |||
65 |
|
||
66 | |||
67 | |||
68 | TinyCC (aka TCC) is a small but hyper fast C compiler. Unlike other C |
||
69 | compilers, it is meant to be self-relying: you do not need an |
||
70 | external assembler or linker because TCC does that for you. |
||
71 | |||
72 | |||
73 | |||
74 | TCC compiles so fast that even for big projects |
||
75 | not be necessary. |
||
76 | |||
77 | |||
78 | |||
79 | TCC not only supports ANSI C, but also most of the new ISO C99 |
||
80 | standard and many GNUC extensions including inline assembly. |
||
81 | |||
82 | |||
83 | |||
84 | TCC can also be used to make C scripts, i.e. pieces of C source |
||
85 | that you run as a Perl or Python script. Compilation is so fast that |
||
86 | your script will be as fast as if it was an executable. |
||
87 | |||
88 | |||
89 | |||
90 | TCC can also automatically generate memory and bound checks |
||
91 | (see section 6. TinyCC Memory and Bound checks) while allowing all C pointers operations. TCC can do |
||
92 | these checks even if non patched libraries are used. |
||
93 | |||
94 | |||
95 | |||
96 | With |
||
97 | generation (see section 7. The |
||
98 | |||
99 | |||
100 | |||
101 | TCC mainly supports the i386 target on Linux and Windows. There are alpha |
||
102 | ports for the ARM ( |
||
103 | ( |
||
104 | http://lists.gnu.org/archive/html/tinycc-devel/2003-10/msg00044.html. |
||
105 | |||
106 | |||
107 | |||
108 | |||
109 |
|
||
110 | |||
111 | |||
112 | [This manual documents version 0.9.23 of the Tiny C Compiler] |
||
113 | |||
114 | |||
115 | |||
116 | |||
117 |
|
||
118 | |||
119 | |||
120 | |||
121 | usage: tcc [options] [infile1 infile2...] [`-run' infile args...] |
||
122 | |||
123 | |||
124 | |||
125 | TCC options are a very much like gcc options. The main difference is that TCC |
||
126 | can also execute directly the resulting program and give it runtime |
||
127 | arguments. |
||
128 | |||
129 | |||
130 | |||
131 | Here are some examples to understand the logic: |
||
132 | |||
133 | |||
134 | |||
135 | |||
136 | `tcc -run a.c' |
||
137 | |||
138 | Compile `a.c' and execute it directly |
||
139 | |||
140 | `tcc -run a.c arg1' |
||
141 | |||
142 | Compile a.c and execute it directly. arg1 is given as first argument to |
||
143 | the |
||
144 | |||
145 | `tcc a.c -run b.c arg1' |
||
146 | |||
147 | Compile `a.c' and `b.c', link them together and execute them. arg1 is given |
||
148 | as first argument to the |
||
149 | multiple C files are specified, `--' are necessary to clearly separate the |
||
150 | program arguments from the TCC options. |
||
151 | |||
152 | `tcc -o myprog a.c b.c' |
||
153 | |||
154 | Compile `a.c' and `b.c', link them and generate the executable `myprog'. |
||
155 | |||
156 | `tcc -o myprog a.o b.o' |
||
157 | |||
158 | link `a.o' and `b.o' together and generate the executable `myprog'. |
||
159 | |||
160 | `tcc -c a.c' |
||
161 | |||
162 | Compile `a.c' and generate object file `a.o'. |
||
163 | |||
164 | `tcc -c asmfile.S' |
||
165 | |||
166 | Preprocess with C preprocess and assemble `asmfile.S' and generate |
||
167 | object file `asmfile.o'. |
||
168 | |||
169 | `tcc -c asmfile.s' |
||
170 | |||
171 | Assemble (but not preprocess) `asmfile.s' and generate object file |
||
172 | `asmfile.o'. |
||
173 | |||
174 | `tcc -r -o ab.o a.c b.c' |
||
175 | |||
176 | Compile `a.c' and `b.c', link them together and generate the object file `ab.o'. |
||
177 | |||
178 | |||
179 | |||
180 | |||
181 | Scripting: |
||
182 | |||
183 | |||
184 | |||
185 | TCC can be invoked from scripts, just as shell scripts. You just |
||
186 | need to add |
||
187 | |||
188 | |||
189 | |||
190 | |||
191 | #!/usr/local/bin/tcc -run |
||
192 | #include <stdio.h> |
||
193 | |||
194 | int main() |
||
195 | { |
||
196 | printf("Hello World\n"); |
||
197 | return 0; |
||
198 | } |
||
199 | |||
200 | |||
201 | |||
202 | |||
203 |
|
||
204 | |||
205 | |||
206 | General Options: |
||
207 | |||
208 | |||
209 | |||
210 | |||
211 | |||
212 | |||
213 | Display current TCC version. |
||
214 | |||
215 | |||
216 | |||
217 | Generate an object file (`-o' option must also be given). |
||
218 | |||
219 | |||
220 | |||
221 | Put object file, executable, or dll into output file `outfile'. |
||
222 | |||
223 | |||
224 | |||
225 | Set the path where the tcc internal libraries can be found (default is |
||
226 | `PREFIX/lib/tcc'). |
||
227 | |||
228 | |||
229 | |||
230 | Output compilation statistics. |
||
231 | |||
232 | |||
233 | |||
234 | Compile file source and run it with the command line arguments |
||
235 | args. In order to be able to give more than one argument to a |
||
236 | script, several TCC options can be given after the |
||
237 | `-run' option, separated by spaces. Example: |
||
238 | |||
239 | |||
240 | |||
241 | tcc "-run -L/usr/X11R6/lib -lX11" ex4.c |
||
242 | |||
243 | |||
244 | In a script, it gives the following header: |
||
245 | |||
246 | |||
247 | |||
248 | #!/usr/local/bin/tcc -run -L/usr/X11R6/lib -lX11 |
||
249 | #include <stdlib.h> |
||
250 | int main(int argc, char **argv) |
||
251 | { |
||
252 | ... |
||
253 | } |
||
254 | |||
255 | |||
256 | |||
257 | |||
258 | |||
259 | Preprocessor options: |
||
260 | |||
261 | |||
262 | |||
263 | |||
264 | |||
265 | |||
266 | Specify an additional include path. Include paths are searched in the |
||
267 | order they are specified. |
||
268 | |||
269 | System include paths are always searched after. The default system |
||
270 | include paths are: `/usr/local/include', `/usr/include' |
||
271 | and `PREFIX/lib/tcc/include'. (`PREFIX' is usually |
||
272 | `/usr' or `/usr/local'). |
||
273 | |||
274 | |||
275 | |||
276 | Define preprocessor symbol `sym' to |
||
277 | val. If val is not present, its value is `1'. Function-like macros can |
||
278 | also be defined: `-DF(a)=a+1' |
||
279 | |||
280 | |||
281 | |||
282 | Undefine preprocessor symbol `sym'. |
||
283 | |||
284 | |||
285 | |||
286 | Compilation flags: |
||
287 | |||
288 | |||
289 | |||
290 | Note: each of the following warning options has a negative form beginning with |
||
291 | `-fno-'. |
||
292 | |||
293 | |||
294 | |||
295 | |||
296 | |||
297 | |||
298 | Let the |
||
299 | |||
300 | |||
301 | |||
302 | Let the |
||
303 | |||
304 | |||
305 | |||
306 | Do not generate common symbols for uninitialized data. |
||
307 | |||
308 | |||
309 | |||
310 | Add a leading underscore at the beginning of each C symbol. |
||
311 | |||
312 | |||
313 | |||
314 | |||
315 | Warning options: |
||
316 | |||
317 | |||
318 | |||
319 | |||
320 | |||
321 | |||
322 | Disable all warnings. |
||
323 | |||
324 | |||
325 | |||
326 | |||
327 | Note: each of the following warning options has a negative form beginning with |
||
328 | `-Wno-'. |
||
329 | |||
330 | |||
331 | |||
332 | |||
333 | |||
334 | |||
335 | Warn about implicit function declaration. |
||
336 | |||
337 | |||
338 | |||
339 | Warn about unsupported GCC features that are ignored by TCC. |
||
340 | |||
341 | |||
342 | |||
343 | Make string constants be of type |
||
344 | *. |
||
345 | |||
346 | |||
347 | |||
348 | Abort compilation if warnings are issued. |
||
349 | |||
350 | |||
351 | |||
352 | Activate all warnings, except `-Werror', `-Wunusupported' and |
||
353 | `-Wwrite-strings'. |
||
354 | |||
355 | |||
356 | |||
357 | |||
358 | Linker options: |
||
359 | |||
360 | |||
361 | |||
362 | |||
363 | |||
364 | |||
365 | Specify an additional static library path for the `-l' option. The |
||
366 | default library paths are `/usr/local/lib', `/usr/lib' and `/lib'. |
||
367 | |||
368 | |||
369 | |||
370 | Link your program with dynamic library libxxx.so or static library |
||
371 | libxxx.a. The library is searched in the paths specified by the |
||
372 | `-L' option. |
||
373 | |||
374 | |||
375 | |||
376 | Generate a shared library instead of an executable (`-o' option |
||
377 | must also be given). |
||
378 | |||
379 | |||
380 | |||
381 | Generate a statically linked executable (default is a shared linked |
||
382 | executable) (`-o' option must also be given). |
||
383 | |||
384 | |||
385 | |||
386 | Export global symbols to the dynamic linker. It is useful when a library |
||
387 | opened with |
||
388 | |||
389 | |||
390 | |||
391 | Generate an object file combining all input files (`-o' option must |
||
392 | also be given). |
||
393 | |||
394 | |||
395 | |||
396 | Set the start of the .text section to address. |
||
397 | |||
398 | |||
399 | |||
400 | Use fmt as output format. The supported output formats are: |
||
401 | |||
402 | |||
403 | elf32-i386 |
||
404 | |||
405 | ELF output format (default) |
||
406 | binary |
||
407 | |||
408 | Binary image (only for executable output) |
||
409 | coff |
||
410 | |||
411 | COFF output format (only for executable output for TMS320C67xx target) |
||
412 | |||
413 | |||
414 | |||
415 | |||
416 | |||
417 | Debugger options: |
||
418 | |||
419 | |||
420 | |||
421 | |||
422 | |||
423 | |||
424 | Generate run time debug information so that you get clear run time |
||
425 | error messages: |
||
426 | invalid pointer instead of the laconic |
||
427 | fault. |
||
428 | |||
429 | |||
430 | |||
431 | Generate additional support code to check |
||
432 | memory allocations and array/pointer bounds. `-g' is implied. Note |
||
433 | that the generated code is slower and bigger in this case. |
||
434 | |||
435 | |||
436 | |||
437 | Display N callers in stack traces. This is useful with `-g' or |
||
438 | `-b'. |
||
439 | |||
440 | |||
441 | |||
442 | |||
443 | Note: GCC options `-Ox', `-fx' and `-mx' are |
||
444 | ignored. |
||
445 | |||
446 | |||
447 | |||
448 | |||
449 |
|
||
450 | |||
451 | |||
452 | |||
453 |
|
||
454 | |||
455 | |||
456 | TCC implements all the ANSI C standard, including structure bit fields |
||
457 | and floating point numbers ( |
||
458 |
|
||
459 | |||
460 | |||
461 | |||
462 | |||
463 |
|
||
464 | |||
465 | |||
466 | TCC implements many features of the new C standard: ISO C99. Currently |
||
467 | missing items are: complex and imaginary numbers and variable length |
||
468 | arrays. |
||
469 | |||
470 | |||
471 | |||
472 | Currently implemented ISOC99 features: |
||
473 | |||
474 | |||
475 | |||
476 | |||
477 | |||
478 | long long types are fully supported. |
||
479 | |||
480 | _Bool is supported. |
||
481 | |||
482 | __func__ is a string variable containing the current |
||
483 | |||
484 | function name. |
||
485 | |||
486 | __VA_ARGS__ can be used for |
||
487 | |||
488 | function-like macros: |
||
489 | |||
490 | |||
491 | #define dprintf(level, __VA_ARGS__) printf(__VA_ARGS__) |
||
492 | |||
493 | |||
494 |
|
||
495 | |||
496 | |||
497 | |||
498 | |||
499 | |||
500 | using designators: |
||
501 | |||
502 | |||
503 | struct { int x, y; } st[10] = { [0].x = 1, [0].y = 2 }; |
||
504 | |||
505 | int tab[10] = { 1, 2, [5] = 5, [9] = 9}; |
||
506 | |||
507 | |||
508 | |||
509 | |||
510 | |||
511 | |||
512 | |||
513 | int *p = (int []){ 1, 2, 3 }; |
||
514 | |||
515 | |||
516 | to initialize a pointer pointing to an initialized array. The same |
||
517 | works for structures and strings. |
||
518 | |||
519 | |||
520 | |||
521 | |||
522 | |||
523 | double d = 0x1234p10; |
||
524 | |||
525 | |||
526 | is the same as writing |
||
527 | |||
528 | |||
529 | double d = 4771840.0; |
||
530 | |||
531 | |||
532 | inline keyword is ignored. |
||
533 | |||
534 | restrict keyword is ignored. |
||
535 | |||
536 | |||
537 | |||
538 | |||
539 | |||
540 |
|
||
541 | |||
542 | |||
543 | |||
544 | |||
545 | |||
546 | |||
547 | |||
548 | |||
549 | |||
550 | |||
551 | |||
552 | TCC implements some GNU C extensions: |
||
553 | |||
554 | |||
555 | |||
556 | |||
557 | |||
558 | |||
559 | |||
560 | |||
561 | |||
562 | int a[10] = { [0] 1, [5] 2, 3, 4 }; |
||
563 | |||
564 | |||
565 | |||
566 | |||
567 | |||
568 | |||
569 | struct { int x, y; } st = { x: 1, y: 1}; |
||
570 | |||
571 | |||
572 | instead of |
||
573 | |||
574 | |||
575 | struct { int x, y; } st = { .x = 1, .y = 1}; |
||
576 | |||
577 | |||
578 | \e is ASCII character 27. |
||
579 | |||
580 | case s: |
||
581 | |||
582 | |||
583 | |||
584 | switch(a) { |
||
585 | case 1 ... 9: |
||
586 | printf("range 1 to 9\n"); |
||
587 | break; |
||
588 | default: |
||
589 | printf("unexpected\n"); |
||
590 | break; |
||
591 | } |
||
592 | |||
593 | |||
594 | __attribute__ is handled to specify variable or |
||
595 | |||
596 | function attributes. The following attributes are supported: |
||
597 | |||
598 | |||
599 | |||
600 | aligned(n) : align a variable or a structure field to n bytes |
||
601 | |||
602 | (must be a power of two). |
||
603 | |||
604 | packed : force alignment of a variable or a structure field to |
||
605 | |||
606 | 1. |
||
607 | |||
608 | section(name) : generate function or data in assembly section |
||
609 | |||
610 | name (name is a string containing the section name) instead of the default |
||
611 | section. |
||
612 | |||
613 | unused : specify that the variable or the function is unused. |
||
614 | |||
615 | cdecl : use standard C calling convention (default). |
||
616 | |||
617 | stdcall : use Pascal-like calling convention. |
||
618 | |||
619 | regparm(n) : use fast i386 calling convention. n must be |
||
620 | |||
621 | between 1 and 3. The first n function parameters are respectively put in |
||
622 | registers |
||
623 | |||
624 | |||
625 | |||
626 | Here are some examples: |
||
627 | |||
628 | |||
629 | int a __attribute__ ((aligned(8), section(".mysection"))); |
||
630 | |||
631 | |||
632 | align variable |
||
633 | |||
634 | |||
635 | |||
636 | int my_add(int a, int b) __attribute__ ((section(".mycodesection"))) |
||
637 | { |
||
638 | return a + b; |
||
639 | } |
||
640 | |||
641 | |||
642 | generate function |
||
643 | |||
644 | |||
645 | |||
646 | |||
647 | |||
648 | #define dprintf(fmt, args...) printf(fmt, ## args) |
||
649 | |||
650 | dprintf("no arg\n"); |
||
651 | dprintf("one arg %d\n", 1); |
||
652 | |||
653 | |||
654 | __FUNCTION__ is interpreted as C99 __func__ |
||
655 | |||
656 | (so it has not exactly the same semantics as string literal GNUC |
||
657 | where it is a string literal). |
||
658 | |||
659 | __alignof__ keyword can be used as sizeof |
||
660 | |||
661 | to get the alignment of a type or an expression. |
||
662 | |||
663 | typeof(x) returns the type of x . |
||
664 | |||
665 |
|
||
666 | |||
667 | &&label returns a pointer of type |
||
668 | |||
669 |
|
||
670 | used to jump on the pointer resulting from |
||
671 | |||
672 | |||
673 | |||
674 | |||
675 | |||
676 | |||
677 | |||
678 | |||
679 | static inline void * my_memcpy(void * to, const void * from, size_t n) |
||
680 | { |
||
681 | int d0, d1, d2; |
||
682 | __asm__ __volatile__( |
||
683 | "rep ; movsl\n\t" |
||
684 | "testb $2,%b4\n\t" |
||
685 | "je 1f\n\t" |
||
686 | "movsw\n" |
||
687 | "1:\ttestb $1,%b4\n\t" |
||
688 | "je 2f\n\t" |
||
689 | "movsb\n" |
||
690 | "2:" |
||
691 | : "=&c" (d0), "=&D" (d1), "=&S" (d2) |
||
692 | :"0" (n/4), "q" (n),"1" ((long) to),"2" ((long) from) |
||
693 | : "memory"); |
||
694 | return (to); |
||
695 | } |
||
696 | |||
697 | |||
698 | |||
699 | TCC includes its own x86 inline assembler with a |
||
700 | assembler) syntax. No intermediate files are generated. GCC 3.x named |
||
701 | operands are supported. |
||
702 | |||
703 | __builtin_types_compatible_p() and __builtin_constant_p() |
||
704 | |||
705 | are supported. |
||
706 | |||
707 | #pragma pack is supported for win32 compatibility. |
||
708 | |||
709 | |||
710 | |||
711 | |||
712 | |||
713 |
|
||
714 | |||
715 | |||
716 | |||
717 | |||
718 | __TINYC__ is a predefined macro to 1 to |
||
719 | |||
720 | indicate that you use TCC. |
||
721 | |||
722 | #! at the start of a line is ignored to allow scripting. |
||
723 | |||
724 | 0b101 instead of |
||
725 | |||
726 |
|
||
727 | |||
728 | __BOUNDS_CHECKING_ON is defined if bound checking is activated. |
||
729 | |||
730 | |||
731 | |||
732 | |||
733 | |||
734 |
|
||
735 | |||
736 | |||
737 | Since version 0.9.16, TinyCC integrates its own assembler. TinyCC |
||
738 | assembler supports a gas-like syntax (GNU assembler). You can |
||
739 | desactivate assembler support if you want a smaller TinyCC executable |
||
740 | (the C compiler does not rely on the assembler). |
||
741 | |||
742 | |||
743 | |||
744 | TinyCC Assembler is used to handle files with `.S' (C |
||
745 | preprocessed assembler) and `.s' extensions. It is also used to |
||
746 | handle the GNU inline assembler with the |
||
747 | |||
748 | |||
749 | |||
750 | |||
751 |
|
||
752 | |||
753 | |||
754 | TinyCC Assembler supports most of the gas syntax. The tokens are the |
||
755 | same as C. |
||
756 | |||
757 | |||
758 | |||
759 | |||
760 | |||
761 | |||
762 | |||
763 | |||
764 | |||
765 | |||
766 | |||
767 | |||
768 | |||
769 | |||
770 | |||
771 |
|
||
772 | |||
773 | |||
774 | |||
775 | |||
776 | |||
777 | |||
778 | |||
779 | |||
780 | |||
781 | |||
782 | |||
783 | |||
784 | |||
785 | |||
786 | |||
787 | |||
788 | |||
789 | |||
790 | |||
791 | |||
792 | |||
793 | |||
794 | All operators accept absolute values except '+' and '-'. '+' or '-' can be |
||
795 | used to add an offset to a label. '-' supports two labels only if they |
||
796 | are the same or if they are both defined and in the same section. |
||
797 | |||
798 | |||
799 | |||
800 | |||
801 | |||
802 |
|
||
803 | |||
804 | |||
805 | |||
806 | |||
807 | |||
808 | |||
809 | gas -like labels. |
||
810 | |||
811 | They can be defined several times in the same source. Use 'b' |
||
812 | (backward) or 'f' (forward) as suffix to reference them: |
||
813 | |||
814 | |||
815 | |||
816 | 1: |
||
817 | jmp 1b /* jump to '1' label before */ |
||
818 | jmp 1f /* jump to '1' label after */ |
||
819 | 1: |
||
820 | |||
821 | |||
822 | |||
823 | |||
824 | |||
825 | |||
826 |
|
||
827 | |||
828 | |||
829 | |||
830 | |||
831 | |||
832 | |||
833 | |||
834 | |||
835 | |||
836 | |||
837 | |||
838 | |||
839 | |||
840 | |||
841 | |||
842 | |||
843 | |||
844 | |||
845 | |||
846 | |||
847 | |||
848 | |||
849 | |||
850 | |||
851 | |||
852 | |||
853 | |||
854 | All directives are preceeded by a '.'. The following directives are |
||
855 | supported: |
||
856 | |||
857 | |||
858 | |||
859 | |||
860 | |||
861 | |||
862 | |||
863 | |||
864 | |||
865 | |||
866 | |||
867 | |||
868 | |||
869 | |||
870 | |||
871 | |||
872 | |||
873 | |||
874 | |||
875 | |||
876 | |||
877 | |||
878 | |||
879 | |||
880 | |||
881 | |||
882 | |||
883 | |||
884 | |||
885 | |||
886 | |||
887 | |||
888 | |||
889 | |||
890 | |||
891 | |||
892 | |||
893 | |||
894 | |||
895 | |||
896 | |||
897 | |||
898 | |||
899 | |||
900 | |||
901 | |||
902 | |||
903 | |||
904 | |||
905 | |||
906 |
|
||
907 | |||
908 | |||
909 | |||
910 | |||
911 | |||
912 | All X86 opcodes are supported. Only ATT syntax is supported (source |
||
913 | then destination operand order). If no size suffix is given, TinyCC |
||
914 | tries to guess it from the operand sizes. |
||
915 | |||
916 | |||
917 | |||
918 | Currently, MMX opcodes are supported but not SSE ones. |
||
919 | |||
920 | |||
921 | |||
922 | |||
923 |
|
||
924 | |||
925 | |||
926 | |||
927 | |||
928 | |||
929 | |||
930 |
|
||
931 | |||
932 | |||
933 | |||
934 | |||
935 | |||
936 | TCC can directly output relocatable ELF files (object files), |
||
937 | executable ELF files and dynamic ELF libraries without relying on an |
||
938 | external linker. |
||
939 | |||
940 | |||
941 | |||
942 | Dynamic ELF libraries can be output but the C compiler does not generate |
||
943 | position independent code (PIC). It means that the dynamic library |
||
944 | code generated by TCC cannot be factorized among processes yet. |
||
945 | |||
946 | |||
947 | |||
948 | TCC linker eliminates unreferenced object code in libraries. A single pass is |
||
949 | done on the object and library list, so the order in which object files and |
||
950 | libraries are specified is important (same constraint as GNU ld). No grouping |
||
951 | options (`--start-group' and `--end-group') are supported. |
||
952 | |||
953 | |||
954 | |||
955 | |||
956 |
|
||
957 | |||
958 | |||
959 | TCC can load ELF object files, archives (.a files) and dynamic |
||
960 | libraries (.so). |
||
961 | |||
962 | |||
963 | |||
964 | |||
965 |
|
||
966 | |||
967 | |||
968 | |||
969 | |||
970 | |||
971 | TCC for Windows supports the native Win32 executable file format (PE-i386). It |
||
972 | generates both EXE and DLL files. DLL symbols can be imported thru DEF files |
||
973 | generated with the |
||
974 | |||
975 | |||
976 | |||
977 | Currently TCC for Windows cannot generate nor read PE object files, so ELF |
||
978 | object files are used for that purpose. It can be a problem if |
||
979 | interoperability with MSVC is needed. Moreover, no leading underscore is |
||
980 | currently generated in the ELF symbols. |
||
981 | |||
982 | |||
983 | |||
984 | |||
985 |
|
||
986 | |||
987 | |||
988 | |||
989 | |||
990 | |||
991 | |||
992 | |||
993 | |||
994 | |||
995 | |||
996 | Because on many Linux systems some dynamic libraries (such as |
||
997 | `/usr/lib/libc.so') are in fact GNU ld link scripts (horrible!), |
||
998 | the TCC linker also supports a subset of GNU ld scripts. |
||
999 | |||
1000 | |||
1001 | |||
1002 | The |
||
1003 | and |
||
1004 | |||
1005 | |||
1006 | |||
1007 | Example from `/usr/lib/libc.so': |
||
1008 | |||
1009 | |||
1010 | /* GNU ld script |
||
1011 | Use the shared library, but some functions are only in |
||
1012 | the static library, so try that secondarily. */ |
||
1013 | GROUP ( /lib/libc.so.6 /usr/lib/libc_nonshared.a ) |
||
1014 | |||
1015 | |||
1016 | |||
1017 | |||
1018 |
|
||
1019 | |||
1020 | |||
1021 | |||
1022 | |||
1023 | |||
1024 | |||
1025 | This feature is activated with the `-b' (see section 2. Command line invocation). |
||
1026 | |||
1027 | |||
1028 | |||
1029 | Note that pointer size is unchanged and that code generated |
||
1030 | with bound checks is fully compatible with unchecked |
||
1031 | code. When a pointer comes from unchecked code, it is assumed to be |
||
1032 | valid. Even very obscure C code with casts should work correctly. |
||
1033 | |||
1034 | |||
1035 | |||
1036 | For more information about the ideas behind this method, see |
||
1037 | http://www.doc.ic.ac.uk/~phjk/BoundsChecking.html. |
||
1038 | |||
1039 | |||
1040 | |||
1041 | Here are some examples of caught errors: |
||
1042 | |||
1043 | |||
1044 | |||
1045 | |||
1046 | |||
1047 | |||
1048 | |||
1049 | |||
1050 | { |
||
1051 | char tab[10]; |
||
1052 | memset(tab, 0, 11); |
||
1053 | } |
||
1054 | |||
1055 | |||
1056 | |||
1057 | |||
1058 | |||
1059 | |||
1060 | { |
||
1061 | int tab[10]; |
||
1062 | for(i=0;i<11;i++) { |
||
1063 | sum += tab[i]; |
||
1064 | } |
||
1065 | } |
||
1066 | |||
1067 | |||
1068 | |||
1069 | |||
1070 | |||
1071 | |||
1072 | { |
||
1073 | int *tab; |
||
1074 | tab = malloc(20 * sizeof(int)); |
||
1075 | for(i=0;i<21;i++) { |
||
1076 | sum += tab4[i]; |
||
1077 | } |
||
1078 | free(tab); |
||
1079 | } |
||
1080 | |||
1081 | |||
1082 | |||
1083 | |||
1084 | |||
1085 | |||
1086 | { |
||
1087 | int *tab; |
||
1088 | tab = malloc(20 * sizeof(int)); |
||
1089 | free(tab); |
||
1090 | for(i=0;i<20;i++) { |
||
1091 | sum += tab4[i]; |
||
1092 | } |
||
1093 | } |
||
1094 | |||
1095 | |||
1096 | |||
1097 | |||
1098 | |||
1099 | |||
1100 | { |
||
1101 | int *tab; |
||
1102 | tab = malloc(20 * sizeof(int)); |
||
1103 | free(tab); |
||
1104 | free(tab); |
||
1105 | } |
||
1106 | |||
1107 | |||
1108 | |||
1109 | |||
1110 | |||
1111 | |||
1112 |
|
||
1113 | |||
1114 | |||
1115 | The |
||
1116 | dynamic code generation. |
||
1117 | |||
1118 | |||
1119 | |||
1120 | Read the `libtcc.h' to have an overview of the API. Read |
||
1121 | `libtcc_test.c' to have a very simple example. |
||
1122 | |||
1123 | |||
1124 | |||
1125 | The idea consists in giving a C string containing the program you want |
||
1126 | to compile directly to |
||
1127 | symbol (function or variable) defined. |
||
1128 | |||
1129 | |||
1130 | |||
1131 | |||
1132 |
|
||
1133 | |||
1134 | |||
1135 | This chapter gives some hints to understand how TCC works. You can skip |
||
1136 | it if you do not intend to modify the TCC code. |
||
1137 | |||
1138 | |||
1139 | |||
1140 | |||
1141 |
|
||
1142 | |||
1143 | |||
1144 | The |
||
1145 | file, including the current line number. |
||
1146 | file and |
||
1147 | character. |
||
1148 | |||
1149 | |||
1150 | |||
1151 | |||
1152 |
|
||
1153 | |||
1154 | |||
1155 |
|
||
1156 | file. |
||
1157 | expansion. |
||
1158 | |||
1159 | |||
1160 | |||
1161 |
|
||
1162 | constants. Identifiers and keywords are also keywords. |
||
1163 | contains additional infos about the token (for example a constant value |
||
1164 | if number or string token). |
||
1165 | |||
1166 | |||
1167 | |||
1168 | |||
1169 |
|
||
1170 | |||
1171 | |||
1172 | The parser is hardcoded (yacc is not necessary). It does only one pass, |
||
1173 | except: |
||
1174 | |||
1175 | |||
1176 | |||
1177 | |||
1178 | |||
1179 | |||
1180 | |||
1181 | is done to count the number of elements. |
||
1182 | |||
1183 | |||
1184 | |||
1185 | reverse order, a first pass is done to reverse the argument order. |
||
1186 | |||
1187 | |||
1188 | |||
1189 | |||
1190 | |||
1191 |
|
||
1192 | |||
1193 | |||
1194 | The types are stored in a single 'int' variable. It was choosen in the |
||
1195 | first stages of development when tcc was much simpler. Now, it may not |
||
1196 | be the best solution. |
||
1197 | |||
1198 | |||
1199 | |||
1200 | |||
1201 | #define VT_INT 0 /* integer type */ |
||
1202 | #define VT_BYTE 1 /* signed byte type */ |
||
1203 | #define VT_SHORT 2 /* short type */ |
||
1204 | #define VT_VOID 3 /* void type */ |
||
1205 | #define VT_PTR 4 /* pointer */ |
||
1206 | #define VT_ENUM 5 /* enum definition */ |
||
1207 | #define VT_FUNC 6 /* function type */ |
||
1208 | #define VT_STRUCT 7 /* struct/union definition */ |
||
1209 | #define VT_FLOAT 8 /* IEEE float */ |
||
1210 | #define VT_DOUBLE 9 /* IEEE double */ |
||
1211 | #define VT_LDOUBLE 10 /* IEEE long double */ |
||
1212 | #define VT_BOOL 11 /* ISOC99 boolean type */ |
||
1213 | #define VT_LLONG 12 /* 64 bit integer */ |
||
1214 | #define VT_LONG 13 /* long integer (NEVER USED as type, only |
||
1215 | during parsing) */ |
||
1216 | #define VT_BTYPE 0x000f /* mask for basic type */ |
||
1217 | #define VT_UNSIGNED 0x0010 /* unsigned type */ |
||
1218 | #define VT_ARRAY 0x0020 /* array type (also has VT_PTR) */ |
||
1219 | #define VT_BITFIELD 0x0040 /* bitfield modifier */ |
||
1220 | |||
1221 | #define VT_STRUCT_SHIFT 16 /* structure/enum name shift (16 bits left) */ |
||
1222 | |||
1223 | |||
1224 | |||
1225 | When a reference to another type is needed (for pointers, functions and |
||
1226 | structures), the |
||
1227 | store an identifier reference. |
||
1228 | |||
1229 | |||
1230 | |||
1231 | The |
||
1232 | longs. |
||
1233 | |||
1234 | |||
1235 | |||
1236 | Arrays are considered as pointers |
||
1237 |
|
||
1238 | |||
1239 | |||
1240 | |||
1241 | The |
||
1242 | longs. If it is set, then the bitfield position is stored from bits |
||
1243 | VT_STRUCT_SHIFT to VT_STRUCT_SHIFT + 5 and the bit field size is stored |
||
1244 | from bits VT_STRUCT_SHIFT + 6 to VT_STRUCT_SHIFT + 11. |
||
1245 | |||
1246 | |||
1247 | |||
1248 |
|
||
1249 | |||
1250 | |||
1251 | |||
1252 | During parsing, the storage of an object is also stored in the type |
||
1253 | integer: |
||
1254 | |||
1255 | |||
1256 | |||
1257 | |||
1258 | #define VT_EXTERN 0x00000080 /* extern definition */ |
||
1259 | #define VT_STATIC 0x00000100 /* static variable */ |
||
1260 | #define VT_TYPEDEF 0x00000200 /* typedef definition */ |
||
1261 | |||
1262 | |||
1263 | |||
1264 | |||
1265 |
|
||
1266 | |||
1267 | |||
1268 | All symbols are stored in hashed symbol stacks. Each symbol stack |
||
1269 | contains |
||
1270 | |||
1271 | |||
1272 | |||
1273 |
|
||
1274 | an idenfier is also a token, so a string is never necessary to store |
||
1275 | it). |
||
1276 | the register in which the corresponding variable is stored. |
||
1277 | usually a constant associated to the symbol. |
||
1278 | |||
1279 | |||
1280 | |||
1281 | Four main symbol stacks are defined: |
||
1282 | |||
1283 | |||
1284 | |||
1285 | |||
1286 | define_stack |
||
1287 | |||
1288 | for the macros ( |
||
1289 | |||
1290 | global_stack |
||
1291 | |||
1292 | for the global variables, functions and types. |
||
1293 | |||
1294 | local_stack |
||
1295 | |||
1296 | for the local variables, functions and types. |
||
1297 | |||
1298 | global_label_stack |
||
1299 | |||
1300 | for the local labels (for |
||
1301 | |||
1302 | label_stack |
||
1303 | |||
1304 | for GCC block local labels (see the |
||
1305 | |||
1306 | |||
1307 | |||
1308 | |||
1309 |
|
||
1310 | stack. If no local symbol stack is active, it is added in the global |
||
1311 | symbol stack. |
||
1312 | |||
1313 | |||
1314 | |||
1315 |
|
||
1316 | the symbol b is on the top of stack. If b is NULL, the stack |
||
1317 | is emptied. |
||
1318 | |||
1319 | |||
1320 | |||
1321 |
|
||
1322 | v. The local stack is searched first from top to bottom, then the |
||
1323 | global stack. |
||
1324 | |||
1325 | |||
1326 | |||
1327 | |||
1328 |
|
||
1329 | |||
1330 | |||
1331 | The generated code and datas are written in sections. The structure |
||
1332 |
|
||
1333 | section. |
||
1334 | is assumed for each section. |
||
1335 | |||
1336 | |||
1337 | |||
1338 | The following sections are predefined: |
||
1339 | |||
1340 | |||
1341 | |||
1342 | |||
1343 | text_section |
||
1344 | |||
1345 | is the section containing the generated code. ind contains the |
||
1346 | current position in the code section. |
||
1347 | |||
1348 | data_section |
||
1349 | |||
1350 | contains initialized data |
||
1351 | |||
1352 | bss_section |
||
1353 | |||
1354 | contains uninitialized data |
||
1355 | |||
1356 | bounds_section |
||
1357 | |||
1358 | lbounds_section |
||
1359 | |||
1360 | are used when bound checking is activated |
||
1361 | |||
1362 | stab_section |
||
1363 | |||
1364 | stabstr_section |
||
1365 | |||
1366 | are used when debugging is actived to store debug information |
||
1367 | |||
1368 | symtab_section |
||
1369 | |||
1370 | strtab_section |
||
1371 | |||
1372 | contain the exported symbols (currently only used for debugging). |
||
1373 | |||
1374 | |||
1375 | |||
1376 | |||
1377 | |||
1378 |
|
||
1379 | |||
1380 | |||
1381 | |||
1382 | |||
1383 | |||
1384 | |||
1385 |
|
||
1386 | |||
1387 | |||
1388 | The TCC code generator directly generates linked binary code in one |
||
1389 | pass. It is rather unusual these days (see gcc for example which |
||
1390 | generates text assembly), but it can be very fast and surprisingly |
||
1391 | little complicated. |
||
1392 | |||
1393 | |||
1394 | |||
1395 | The TCC code generator is register based. Optimization is only done at |
||
1396 | the expression level. No intermediate representation of expression is |
||
1397 | kept except the current values stored in the value stack. |
||
1398 | |||
1399 | |||
1400 | |||
1401 | On x86, three temporary registers are used. When more registers are |
||
1402 | needed, one register is spilled into a new temporary variable on the stack. |
||
1403 | |||
1404 | |||
1405 | |||
1406 | |||
1407 |
|
||
1408 | |||
1409 | |||
1410 | |||
1411 | |||
1412 | |||
1413 | When an expression is parsed, its value is pushed on the value stack |
||
1414 | (vstack). The top of the value stack is vtop. Each value |
||
1415 | stack entry is the structure |
||
1416 | |||
1417 | |||
1418 | |||
1419 |
|
||
1420 | currently stored in the generated code. It is usually a CPU register |
||
1421 | index ( |
||
1422 | defined: |
||
1423 | |||
1424 | |||
1425 | |||
1426 | |||
1427 | #define VT_CONST 0x00f0 |
||
1428 | #define VT_LLOCAL 0x00f1 |
||
1429 | #define VT_LOCAL 0x00f2 |
||
1430 | #define VT_CMP 0x00f3 |
||
1431 | #define VT_JMP 0x00f4 |
||
1432 | #define VT_JMPI 0x00f5 |
||
1433 | #define VT_LVAL 0x0100 |
||
1434 | #define VT_SYM 0x0200 |
||
1435 | #define VT_MUSTCAST 0x0400 |
||
1436 | #define VT_MUSTBOUND 0x0800 |
||
1437 | #define VT_BOUNDED 0x8000 |
||
1438 | #define VT_LVAL_BYTE 0x1000 |
||
1439 | #define VT_LVAL_SHORT 0x2000 |
||
1440 | #define VT_LVAL_UNSIGNED 0x4000 |
||
1441 | #define VT_LVAL_TYPE (VT_LVAL_BYTE | VT_LVAL_SHORT | VT_LVAL_UNSIGNED) |
||
1442 | |||
1443 | |||
1444 | |||
1445 | |||
1446 | VT_CONST |
||
1447 | |||
1448 | indicates that the value is a constant. It is stored in the union |
||
1449 |
|
||
1450 | |||
1451 | VT_LOCAL |
||
1452 | |||
1453 | indicates a local variable pointer at offset |
||
1454 | stack. |
||
1455 | |||
1456 | VT_CMP |
||
1457 | |||
1458 | indicates that the value is actually stored in the CPU flags (i.e. the |
||
1459 | value is the consequence of a test). The value is either 0 or 1. The |
||
1460 | actual CPU flags used is indicated in |
||
1461 | |||
1462 | If any code is generated which destroys the CPU flags, this value MUST be |
||
1463 | put in a normal register. |
||
1464 | |||
1465 | VT_JMP |
||
1466 | |||
1467 | VT_JMPI |
||
1468 | |||
1469 | indicates that the value is the consequence of a conditional jump. For VT_JMP, |
||
1470 | it is 1 if the jump is taken, 0 otherwise. For VT_JMPI it is inverted. |
||
1471 | |||
1472 | These values are used to compile the |
||
1473 | operators. |
||
1474 | |||
1475 | If any code is generated, this value MUST be put in a normal |
||
1476 | register. Otherwise, the generated code won't be executed if the jump is |
||
1477 | taken. |
||
1478 | |||
1479 | VT_LVAL |
||
1480 | |||
1481 | is a flag indicating that the value is actually an lvalue (left value of |
||
1482 | an assignment). It means that the value stored is actually a pointer to |
||
1483 | the wanted value. |
||
1484 | |||
1485 | Understanding the use |
||
1486 | understand how TCC works. |
||
1487 | |||
1488 | VT_LVAL_BYTE |
||
1489 | |||
1490 | VT_LVAL_SHORT |
||
1491 | |||
1492 | VT_LVAL_UNSIGNED |
||
1493 | |||
1494 | if the lvalue has an integer type, then these flags give its real |
||
1495 | type. The type alone is not enough in case of cast optimisations. |
||
1496 | |||
1497 | VT_LLOCAL |
||
1498 | |||
1499 | is a saved lvalue on the stack. |
||
1500 | ASAP because its semantics are rather complicated. |
||
1501 | |||
1502 | VT_MUSTCAST |
||
1503 | |||
1504 | indicates that a cast to the value type must be performed if the value |
||
1505 | is used (lazy casting). |
||
1506 | |||
1507 | VT_SYM |
||
1508 | |||
1509 | indicates that the symbol |
||
1510 | |||
1511 | VT_MUSTBOUND |
||
1512 | |||
1513 | VT_BOUNDED |
||
1514 | |||
1515 | are only used for optional bound checking. |
||
1516 | |||
1517 | |||
1518 | |||
1519 | |||
1520 | |||
1521 |
|
||
1522 | |||
1523 | |||
1524 | |||
1525 | |||
1526 | |||
1527 |
|
||
1528 | stack. If the previous vtop was stored in a very unsafe place(for |
||
1529 | example in the CPU flags), then some code is generated to put the |
||
1530 | previous vtop in a safe storage. |
||
1531 | |||
1532 | |||
1533 | |||
1534 |
|
||
1535 | code (for example if stacked floating point registers are used as on |
||
1536 | x86). |
||
1537 | |||
1538 | |||
1539 | |||
1540 | The |
||
1541 | top value of the stack) into registers. rc selects in which |
||
1542 | register class the value should be put. |
||
1543 | important function of the code generator. |
||
1544 | |||
1545 | |||
1546 | |||
1547 |
|
||
1548 | entries. |
||
1549 | |||
1550 | |||
1551 | |||
1552 | |||
1553 |
|
||
1554 | |||
1555 | |||
1556 | See the `i386-gen.c' file to have an example. |
||
1557 | |||
1558 | |||
1559 | |||
1560 | |||
1561 | load() |
||
1562 | |||
1563 | must generate the code needed to load a stack value into a register. |
||
1564 | |||
1565 | store() |
||
1566 | |||
1567 | must generate the code needed to store a register into a stack value |
||
1568 | lvalue. |
||
1569 | |||
1570 | gfunc_start() |
||
1571 | |||
1572 | gfunc_param() |
||
1573 | |||
1574 | gfunc_call() |
||
1575 | |||
1576 | should generate a function call |
||
1577 | |||
1578 | gfunc_prolog() |
||
1579 | |||
1580 | gfunc_epilog() |
||
1581 | |||
1582 | should generate a function prolog/epilog. |
||
1583 | |||
1584 | gen_opi(op) |
||
1585 | |||
1586 | must generate the binary integer operation op on the two top |
||
1587 | entries of the stack which are guaranted to contain integer types. |
||
1588 | |||
1589 | The result value should be put on the stack. |
||
1590 | |||
1591 | gen_opf(op) |
||
1592 | |||
1593 | same as |
||
1594 | entries of the stack are guaranted to contain floating point values of |
||
1595 | same types. |
||
1596 | |||
1597 | gen_cvt_itof() |
||
1598 | |||
1599 | integer to floating point conversion. |
||
1600 | |||
1601 | gen_cvt_ftoi() |
||
1602 | |||
1603 | floating point to integer conversion. |
||
1604 | |||
1605 | gen_cvt_ftof() |
||
1606 | |||
1607 | floating point to floating point of different size conversion. |
||
1608 | |||
1609 | gen_bounded_ptr_add() |
||
1610 | |||
1611 | gen_bounded_ptr_deref() |
||
1612 | |||
1613 | are only used for bounds checking. |
||
1614 | |||
1615 | |||
1616 | |||
1617 | |||
1618 | |||
1619 |
|
||
1620 | |||
1621 | |||
1622 | |||
1623 | |||
1624 | |||
1625 | |||
1626 | |||
1627 | |||
1628 | Constant propagation is done for all operations. Multiplications and |
||
1629 | divisions are optimized to shifts when appropriate. Comparison |
||
1630 | operators are optimized by maintaining a special cache for the |
||
1631 | processor flags. &&, || and ! are optimized by maintaining a special |
||
1632 | 'jump target' value. No other jump optimization is currently performed |
||
1633 | because it would require to store the code in a more abstract fashion. |
||
1634 | |||
1635 | |||
1636 | |||
1637 | |||
1638 |
|
||
1639 | |||
1640 | Jump to: |
||
1641 | _ |
||
1642 | - |
||
1643 | a |
||
1644 | - |
||
1645 | b |
||
1646 | - |
||
1647 | c |
||
1648 | - |
||
1649 | d |
||
1650 | - |
||
1651 | e |
||
1652 | - |
||
1653 | f |
||
1654 | - |
||
1655 | g |
||
1656 | - |
||
1657 | i |
||
1658 | - |
||
1659 | j |
||
1660 | - |
||
1661 | l |
||
1662 | - |
||
1663 | m |
||
1664 | - |
||
1665 | o |
||
1666 | - |
||
1667 | p |
||
1668 | - |
||
1669 | q |
||
1670 | - |
||
1671 | r |
||
1672 | - |
||
1673 | s |
||
1674 | - |
||
1675 | t |
||
1676 | - |
||
1677 | u |
||
1678 | - |
||
1679 | v |
||
1680 | - |
||
1681 | w |
||
1682 | |||
1683 |
|
||
1684 | |||
1685 | |||
1686 | |||
1687 |
|
||
1688 | |||
1689 | |||
1690 | |||
1691 | |||
1692 | |||
1693 | |||
1694 | |||
1695 | |||
1696 | |||
1697 |
|
||
1698 | |||
1699 | |||
1700 | |||
1701 | |||
1702 | |||
1703 |
|
||
1704 | |||
1705 | |||
1706 | |||
1707 | |||
1708 | |||
1709 | |||
1710 | |||
1711 | |||
1712 |
|
||
1713 | |||
1714 | |||
1715 | |||
1716 | |||
1717 |
|
||
1718 | |||
1719 | |||
1720 | |||
1721 |
|
||
1722 | |||
1723 | |||
1724 | |||
1725 | |||
1726 | |||
1727 |
|
||
1728 | |||
1729 | |||
1730 | |||
1731 | |||
1732 | |||
1733 | |||
1734 |
|
||
1735 | |||
1736 | |||
1737 | |||
1738 | |||
1739 |
|
||
1740 | |||
1741 | |||
1742 | |||
1743 |
|
||
1744 | |||
1745 | |||
1746 | |||
1747 | |||
1748 | |||
1749 |
|
||
1750 | |||
1751 | |||
1752 | |||
1753 |
|
||
1754 | |||
1755 | |||
1756 | |||
1757 | |||
1758 | |||
1759 |
|
||
1760 | |||
1761 | |||
1762 | |||
1763 | |||
1764 | |||
1765 |
|
||
1766 | |||
1767 | |||
1768 | |||
1769 |
|
||
1770 | |||
1771 | |||
1772 | |||
1773 |
|
||
1774 | |||
1775 | |||
1776 | |||
1777 | |||
1778 | |||
1779 | |||
1780 | |||
1781 | |||
1782 | |||
1783 | |||
1784 | |||
1785 |
|
||
1786 | |||
1787 | |||
1788 | |||
1789 | |||
1790 |
|
||
1791 | |||
1792 | |||
1793 | |||
1794 |
|
||
1795 | |||
1796 | |||
1797 | |||
1798 | |||
1799 |
|
||
1800 | |||
1801 | |||
1802 | |||
1803 | |||
1804 | |||
1805 | |||
1806 | This document was generated on 18 June 2005 using |
||
1807 | texi2html 1.56k. |
||
1808 | |||
1809 | !--> |