Statistics
| Branch: | Revision:

root / tcg / README @ 36aa55dc

History | View | Annotate | Download (12.2 kB)

1
Tiny Code Generator - Fabrice Bellard.
2

    
3
1) Introduction
4

    
5
TCG (Tiny Code Generator) began as a generic backend for a C
6
compiler. It was simplified to be used in QEMU. It also has its roots
7
in the QOP code generator written by Paul Brook. 
8

    
9
2) Definitions
10

    
11
The TCG "target" is the architecture for which we generate the
12
code. It is of course not the same as the "target" of QEMU which is
13
the emulated architecture. As TCG started as a generic C backend used
14
for cross compiling, it is assumed that the TCG target is different
15
from the host, although it is never the case for QEMU.
16

    
17
A TCG "function" corresponds to a QEMU Translated Block (TB).
18

    
19
A TCG "temporary" is a variable only live in a basic
20
block. Temporaries are allocated explicitly in each function.
21

    
22
A TCG "local temporary" is a variable only live in a function. Local
23
temporaries are allocated explicitly in each function.
24

    
25
A TCG "global" is a variable which is live in all the functions
26
(equivalent of a C global variable). They are defined before the
27
functions defined. A TCG global can be a memory location (e.g. a QEMU
28
CPU register), a fixed host register (e.g. the QEMU CPU state pointer)
29
or a memory location which is stored in a register outside QEMU TBs
30
(not implemented yet).
31

    
32
A TCG "basic block" corresponds to a list of instructions terminated
33
by a branch instruction. 
34

    
35
3) Intermediate representation
36

    
37
3.1) Introduction
38

    
39
TCG instructions operate on variables which are temporaries, local
40
temporaries or globals. TCG instructions and variables are strongly
41
typed. Two types are supported: 32 bit integers and 64 bit
42
integers. Pointers are defined as an alias to 32 bit or 64 bit
43
integers depending on the TCG target word size.
44

    
45
Each instruction has a fixed number of output variable operands, input
46
variable operands and always constant operands.
47

    
48
The notable exception is the call instruction which has a variable
49
number of outputs and inputs.
50

    
51
In the textual form, output operands usually come first, followed by
52
input operands, followed by constant operands. The output type is
53
included in the instruction name. Constants are prefixed with a '$'.
54

    
55
add_i32 t0, t1, t2  (t0 <- t1 + t2)
56

    
57
3.2) Assumptions
58

    
59
* Basic blocks
60

    
61
- Basic blocks end after branches (e.g. brcond_i32 instruction),
62
  goto_tb and exit_tb instructions.
63
- Basic blocks end before legacy dyngen operations.
64
- Basic blocks start after the end of a previous basic block, at a
65
  set_label instruction or after a legacy dyngen operation.
66

    
67
After the end of a basic block, the content of temporaries is
68
destroyed, but local temporaries and globals are preserved.
69

    
70
* Floating point types are not supported yet
71

    
72
* Pointers: depending on the TCG target, pointer size is 32 bit or 64
73
  bit. The type TCG_TYPE_PTR is an alias to TCG_TYPE_I32 or
74
  TCG_TYPE_I64.
75

    
76
* Helpers:
77

    
78
Using the tcg_gen_helper_x_y it is possible to call any function
79
taking i32, i64 or pointer types. Before calling an helper, all
80
globals are stored at their canonical location and it is assumed that
81
the function can modify them. In the future, function modifiers will
82
be allowed to tell that the helper does not read or write some globals.
83

    
84
On some TCG targets (e.g. x86), several calling conventions are
85
supported.
86

    
87
* Branches:
88

    
89
Use the instruction 'br' to jump to a label. Use 'jmp' to jump to an
90
explicit address. Conditional branches can only jump to labels.
91

    
92
3.3) Code Optimizations
93

    
94
When generating instructions, you can count on at least the following
95
optimizations:
96

    
97
- Single instructions are simplified, e.g.
98

    
99
   and_i32 t0, t0, $0xffffffff
100
    
101
  is suppressed.
102

    
103
- A liveness analysis is done at the basic block level. The
104
  information is used to suppress moves from a dead variable to
105
  another one. It is also used to remove instructions which compute
106
  dead results. The later is especially useful for condition code
107
  optimization in QEMU.
108

    
109
  In the following example:
110

    
111
  add_i32 t0, t1, t2
112
  add_i32 t0, t0, $1
113
  mov_i32 t0, $1
114

    
115
  only the last instruction is kept.
116

    
117
3.4) Instruction Reference
118

    
119
********* Function call
120

    
121
* call <ret> <params> ptr
122

    
123
call function 'ptr' (pointer type)
124

    
125
<ret> optional 32 bit or 64 bit return value
126
<params> optional 32 bit or 64 bit parameters
127

    
128
********* Jumps/Labels
129

    
130
* jmp t0
131

    
132
Absolute jump to address t0 (pointer type).
133

    
134
* set_label $label
135

    
136
Define label 'label' at the current program point.
137

    
138
* br $label
139

    
140
Jump to label.
141

    
142
* brcond_i32/i64 cond, t0, t1, label
143

    
144
Conditional jump if t0 cond t1 is true. cond can be:
145
    TCG_COND_EQ
146
    TCG_COND_NE
147
    TCG_COND_LT /* signed */
148
    TCG_COND_GE /* signed */
149
    TCG_COND_LE /* signed */
150
    TCG_COND_GT /* signed */
151
    TCG_COND_LTU /* unsigned */
152
    TCG_COND_GEU /* unsigned */
153
    TCG_COND_LEU /* unsigned */
154
    TCG_COND_GTU /* unsigned */
155

    
156
********* Arithmetic
157

    
158
* add_i32/i64 t0, t1, t2
159

    
160
t0=t1+t2
161

    
162
* sub_i32/i64 t0, t1, t2
163

    
164
t0=t1-t2
165

    
166
* neg_i32/i64 t0, t1
167

    
168
t0=-t1 (two's complement)
169

    
170
* mul_i32/i64 t0, t1, t2
171

    
172
t0=t1*t2
173

    
174
* div_i32/i64 t0, t1, t2
175

    
176
t0=t1/t2 (signed). Undefined behavior if division by zero or overflow.
177

    
178
* divu_i32/i64 t0, t1, t2
179

    
180
t0=t1/t2 (unsigned). Undefined behavior if division by zero.
181

    
182
* rem_i32/i64 t0, t1, t2
183

    
184
t0=t1%t2 (signed). Undefined behavior if division by zero or overflow.
185

    
186
* remu_i32/i64 t0, t1, t2
187

    
188
t0=t1%t2 (unsigned). Undefined behavior if division by zero.
189

    
190
********* Logical
191

    
192
* and_i32/i64 t0, t1, t2
193

    
194
t0=t1&t2
195

    
196
* or_i32/i64 t0, t1, t2
197

    
198
t0=t1|t2
199

    
200
* xor_i32/i64 t0, t1, t2
201

    
202
t0=t1^t2
203

    
204
* not_i32/i64 t0, t1
205

    
206
t0=~t1
207

    
208
********* Shifts
209

    
210
* shl_i32/i64 t0, t1, t2
211

    
212
t0=t1 << t2. Undefined behavior if t2 < 0 or t2 >= 32 (resp 64)
213

    
214
* shr_i32/i64 t0, t1, t2
215

    
216
t0=t1 >> t2 (unsigned). Undefined behavior if t2 < 0 or t2 >= 32 (resp 64)
217

    
218
* sar_i32/i64 t0, t1, t2
219

    
220
t0=t1 >> t2 (signed). Undefined behavior if t2 < 0 or t2 >= 32 (resp 64)
221

    
222
********* Misc
223

    
224
* mov_i32/i64 t0, t1
225

    
226
t0 = t1
227

    
228
Move t1 to t0 (both operands must have the same type).
229

    
230
* ext8s_i32/i64 t0, t1
231
ext8u_i32/i64 t0, t1
232
ext16s_i32/i64 t0, t1
233
ext16u_i32/i64 t0, t1
234
ext32s_i64 t0, t1
235
ext32u_i64 t0, t1
236

    
237
8, 16 or 32 bit sign/zero extension (both operands must have the same type)
238

    
239
* bswap16_i32 t0, t1
240

    
241
16 bit byte swap on a 32 bit value. The two high order bytes must be set
242
to zero.
243

    
244
* bswap_i32 t0, t1
245

    
246
32 bit byte swap
247

    
248
* bswap_i64 t0, t1
249

    
250
64 bit byte swap
251

    
252
* discard_i32/i64 t0
253

    
254
Indicate that the value of t0 won't be used later. It is useful to
255
force dead code elimination.
256

    
257
********* Type conversions
258

    
259
* ext_i32_i64 t0, t1
260
Convert t1 (32 bit) to t0 (64 bit) and does sign extension
261

    
262
* extu_i32_i64 t0, t1
263
Convert t1 (32 bit) to t0 (64 bit) and does zero extension
264

    
265
* trunc_i64_i32 t0, t1
266
Truncate t1 (64 bit) to t0 (32 bit)
267

    
268
* concat_i32_i64 t0, t1, t2
269
Construct t0 (64-bit) taking the low half from t1 (32 bit) and the high half
270
from t2 (32 bit).
271

    
272
********* Load/Store
273

    
274
* ld_i32/i64 t0, t1, offset
275
ld8s_i32/i64 t0, t1, offset
276
ld8u_i32/i64 t0, t1, offset
277
ld16s_i32/i64 t0, t1, offset
278
ld16u_i32/i64 t0, t1, offset
279
ld32s_i64 t0, t1, offset
280
ld32u_i64 t0, t1, offset
281

    
282
t0 = read(t1 + offset)
283
Load 8, 16, 32 or 64 bits with or without sign extension from host memory. 
284
offset must be a constant.
285

    
286
* st_i32/i64 t0, t1, offset
287
st8_i32/i64 t0, t1, offset
288
st16_i32/i64 t0, t1, offset
289
st32_i64 t0, t1, offset
290

    
291
write(t0, t1 + offset)
292
Write 8, 16, 32 or 64 bits to host memory.
293

    
294
********* QEMU specific operations
295

    
296
* tb_exit t0
297

    
298
Exit the current TB and return the value t0 (word type).
299

    
300
* goto_tb index
301

    
302
Exit the current TB and jump to the TB index 'index' (constant) if the
303
current TB was linked to this TB. Otherwise execute the next
304
instructions.
305

    
306
* qemu_ld_i32/i64 t0, t1, flags
307
qemu_ld8u_i32/i64 t0, t1, flags
308
qemu_ld8s_i32/i64 t0, t1, flags
309
qemu_ld16u_i32/i64 t0, t1, flags
310
qemu_ld16s_i32/i64 t0, t1, flags
311
qemu_ld32u_i64 t0, t1, flags
312
qemu_ld32s_i64 t0, t1, flags
313

    
314
Load data at the QEMU CPU address t1 into t0. t1 has the QEMU CPU
315
address type. 'flags' contains the QEMU memory index (selects user or
316
kernel access) for example.
317

    
318
* qemu_st_i32/i64 t0, t1, flags
319
qemu_st8_i32/i64 t0, t1, flags
320
qemu_st16_i32/i64 t0, t1, flags
321
qemu_st32_i64 t0, t1, flags
322

    
323
Store the data t0 at the QEMU CPU Address t1. t1 has the QEMU CPU
324
address type. 'flags' contains the QEMU memory index (selects user or
325
kernel access) for example.
326

    
327
Note 1: Some shortcuts are defined when the last operand is known to be
328
a constant (e.g. addi for add, movi for mov).
329

    
330
Note 2: When using TCG, the opcodes must never be generated directly
331
as some of them may not be available as "real" opcodes. Always use the
332
function tcg_gen_xxx(args).
333

    
334
4) Backend
335

    
336
tcg-target.h contains the target specific definitions. tcg-target.c
337
contains the target specific code.
338

    
339
4.1) Assumptions
340

    
341
The target word size (TCG_TARGET_REG_BITS) is expected to be 32 bit or
342
64 bit. It is expected that the pointer has the same size as the word.
343

    
344
On a 32 bit target, all 64 bit operations are converted to 32 bits. A
345
few specific operations must be implemented to allow it (see add2_i32,
346
sub2_i32, brcond2_i32).
347

    
348
Floating point operations are not supported in this version. A
349
previous incarnation of the code generator had full support of them,
350
but it is better to concentrate on integer operations first.
351

    
352
On a 64 bit target, no assumption is made in TCG about the storage of
353
the 32 bit values in 64 bit registers.
354

    
355
4.2) Constraints
356

    
357
GCC like constraints are used to define the constraints of every
358
instruction. Memory constraints are not supported in this
359
version. Aliases are specified in the input operands as for GCC.
360

    
361
A target can define specific register or constant constraints. If an
362
operation uses a constant input constraint which does not allow all
363
constants, it must also accept registers in order to have a fallback.
364

    
365
The movi_i32 and movi_i64 operations must accept any constants.
366

    
367
The mov_i32 and mov_i64 operations must accept any registers of the
368
same type.
369

    
370
The ld/st instructions must accept signed 32 bit constant offsets. It
371
can be implemented by reserving a specific register to compute the
372
address if the offset is too big.
373

    
374
The ld/st instructions must accept any destination (ld) or source (st)
375
register.
376

    
377
4.3) Function call assumptions
378

    
379
- The only supported types for parameters and return value are: 32 and
380
  64 bit integers and pointer.
381
- The stack grows downwards.
382
- The first N parameters are passed in registers.
383
- The next parameters are passed on the stack by storing them as words.
384
- Some registers are clobbered during the call. 
385
- The function can return 0 or 1 value in registers. On a 32 bit
386
  target, functions must be able to return 2 values in registers for
387
  64 bit return type.
388

    
389
5) Migration from dyngen to TCG
390

    
391
TCG is backward compatible with QEMU "dyngen" operations. It means
392
that TCG instructions can be freely mixed with dyngen operations. It
393
is expected that QEMU targets will be progressively fully converted to
394
TCG. Once a target is fully converted to TCG, it will be possible
395
to apply more optimizations because more registers will be free for
396
the generated code.
397

    
398
The exception model is the same as the dyngen one.
399

    
400
6) Recommended coding rules for best performance
401

    
402
- Use globals to represent the parts of the QEMU CPU state which are
403
  often modified, e.g. the integer registers and the condition
404
  codes. TCG will be able to use host registers to store them.
405

    
406
- Avoid globals stored in fixed registers. They must be used only to
407
  store the pointer to the CPU state and possibly to store a pointer
408
  to a register window. The other uses are to ensure backward
409
  compatibility with dyngen during the porting a new target to TCG.
410

    
411
- Use temporaries. Use local temporaries only when really needed,
412
  e.g. when you need to use a value after a jump. Local temporaries
413
  introduce a performance hit in the current TCG implementation: their
414
  content is saved to memory at end of each basic block.
415

    
416
- Free temporaries and local temporaries when they are no longer used
417
  (tcg_temp_free). Since tcg_const_x() also creates a temporary, you
418
  should free it after it is used. Freeing temporaries does not yield
419
  a better generated code, but it reduces the memory usage of TCG and
420
  the speed of the translation.
421

    
422
- Don't hesitate to use helpers for complicated or seldom used target
423
  intructions. There is little performance advantage in using TCG to
424
  implement target instructions taking more than about twenty TCG
425
  instructions.
426

    
427
- Use the 'discard' instruction if you know that TCG won't be able to
428
  prove that a given global is "dead" at a given program point. The
429
  x86 target uses it to improve the condition codes optimisation.