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
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
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
|
# dietC: a C backend for chibicc
What: desugar C code
Why: easier program analysis and transformation
How: fork of Rui Ueyama's great chibicc compiler, replacing the x86 assembly
backend with a C backend
Quick Example:
$ cat tests/super_simple.c
int main(void) {
int x = 1;
int y = 2;
return y;
}
$ make
...
$ ./dietc tests/super_simple.c
#include "/home/matthew/repos/dietc/scripts/dietc_helpers.h"
typedef int Type_1 ;
...
extern Type_5 main ;
...
Type_1 main ( ) {
Type_1 t1 ;
...
t3 = 1 ;
* t5 = t3 ;
...
return t1 ;
}
Selling points:
- Guaranteed space-separated tokens
- Extremely restricted grammar, super easy to parse; see docs/LANGUAGE.txt
- Maintains all type information (except qualifiers like const)
- Comes with a wrapper to replace GCC in existing build scripts; see
docs/DIETCC.txt
- Can extract an entire project to a single directory with multiple .c files
for easy analysis; see docs/FOLDERCC.txt
Known to be unsupported:
- dietC is ... optimistic about identifier conflicts with its generated
labels. It likely will not work if you run it on its own output. This is
very fixable, will do soon.
- chibicc does not have good support for long double; specifically, long
doubles cannot be used in constant expressions. This is fixable, but
requires non-trivial modifications to the chibicc side of the code.
- chibicc does not parse const, volatile, etc. type qualifiers. it would not
be too hard to support this if desired.
Options:
- Passing "--line-numbers" enables (very WIP) support for outputting #line
directives. The dietcc wrapper will attempt to automatically strip those
before calling passes & then re-insert them, so that it all happens
"automagically." Of course, it doesn't really. You'll probably find that it
has roughly the right file, but totally wrong line.
- Passing "--type-builtins" will output "sizeof(Type_%d)" and
"alignof(Type_%d)" instead of pre-computing these operations.
Why not cilly?
- cilly performs both not enough and too much lowering.
- it often compiles a struct field acces a->foo into a literal offset like
*(a + 16).
- even after simplification it has multiple control flow constructs: loop,
etc.
- it's written in OCAML, and hard to parse the result outside of OCAML
Why not C--, assembly, QBE?
- all these are strictly lower level than cilly. They preserve almost no type
information at all.
Why not LLVM?
- LLVM has breaking changes approximately every 5ns and preservation of
high-level type information is not guaranteed.
- mostly forced to use LLVM's C++ interfaces and then compile with LLVM
License:
- the underlying chibicc code is licensed under the MIT license
- my modifications are licensed under the AGPLv3
|
