Statistics
| Branch: | Revision:

root / tcg / README @ f24cb33e

History | View | Annotate | Download (12.5 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
* andc_i32/i64 t0, t1, t2
209

    
210
t0=t1&~t2
211

    
212
* eqv_i32/i64 t0, t1, t2
213

    
214
t0=~(t1^t2)
215

    
216
* nand_i32/i64 t0, t1, t2
217

    
218
t0=~(t1&t2)
219

    
220
* nor_i32/i64 t0, t1, t2
221

    
222
t0=~(t1|t2)
223

    
224
* orc_i32/i64 t0, t1, t2
225

    
226
t0=t1|~t2
227

    
228
********* Shifts
229

    
230
* shl_i32/i64 t0, t1, t2
231

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

    
234
* shr_i32/i64 t0, t1, t2
235

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

    
238
* sar_i32/i64 t0, t1, t2
239

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

    
242
********* Misc
243

    
244
* mov_i32/i64 t0, t1
245

    
246
t0 = t1
247

    
248
Move t1 to t0 (both operands must have the same type).
249

    
250
* ext8s_i32/i64 t0, t1
251
ext8u_i32/i64 t0, t1
252
ext16s_i32/i64 t0, t1
253
ext16u_i32/i64 t0, t1
254
ext32s_i64 t0, t1
255
ext32u_i64 t0, t1
256

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

    
259
* bswap16_i32 t0, t1
260

    
261
16 bit byte swap on a 32 bit value. The two high order bytes must be set
262
to zero.
263

    
264
* bswap_i32 t0, t1
265

    
266
32 bit byte swap
267

    
268
* bswap_i64 t0, t1
269

    
270
64 bit byte swap
271

    
272
* discard_i32/i64 t0
273

    
274
Indicate that the value of t0 won't be used later. It is useful to
275
force dead code elimination.
276

    
277
********* Type conversions
278

    
279
* ext_i32_i64 t0, t1
280
Convert t1 (32 bit) to t0 (64 bit) and does sign extension
281

    
282
* extu_i32_i64 t0, t1
283
Convert t1 (32 bit) to t0 (64 bit) and does zero extension
284

    
285
* trunc_i64_i32 t0, t1
286
Truncate t1 (64 bit) to t0 (32 bit)
287

    
288
* concat_i32_i64 t0, t1, t2
289
Construct t0 (64-bit) taking the low half from t1 (32 bit) and the high half
290
from t2 (32 bit).
291

    
292
* concat32_i64 t0, t1, t2
293
Construct t0 (64-bit) taking the low half from t1 (64 bit) and the high half
294
from t2 (64 bit).
295

    
296
********* Load/Store
297

    
298
* ld_i32/i64 t0, t1, offset
299
ld8s_i32/i64 t0, t1, offset
300
ld8u_i32/i64 t0, t1, offset
301
ld16s_i32/i64 t0, t1, offset
302
ld16u_i32/i64 t0, t1, offset
303
ld32s_i64 t0, t1, offset
304
ld32u_i64 t0, t1, offset
305

    
306
t0 = read(t1 + offset)
307
Load 8, 16, 32 or 64 bits with or without sign extension from host memory. 
308
offset must be a constant.
309

    
310
* st_i32/i64 t0, t1, offset
311
st8_i32/i64 t0, t1, offset
312
st16_i32/i64 t0, t1, offset
313
st32_i64 t0, t1, offset
314

    
315
write(t0, t1 + offset)
316
Write 8, 16, 32 or 64 bits to host memory.
317

    
318
********* QEMU specific operations
319

    
320
* tb_exit t0
321

    
322
Exit the current TB and return the value t0 (word type).
323

    
324
* goto_tb index
325

    
326
Exit the current TB and jump to the TB index 'index' (constant) if the
327
current TB was linked to this TB. Otherwise execute the next
328
instructions.
329

    
330
* qemu_ld_i32/i64 t0, t1, flags
331
qemu_ld8u_i32/i64 t0, t1, flags
332
qemu_ld8s_i32/i64 t0, t1, flags
333
qemu_ld16u_i32/i64 t0, t1, flags
334
qemu_ld16s_i32/i64 t0, t1, flags
335
qemu_ld32u_i64 t0, t1, flags
336
qemu_ld32s_i64 t0, t1, flags
337

    
338
Load data at the QEMU CPU address t1 into t0. t1 has the QEMU CPU
339
address type. 'flags' contains the QEMU memory index (selects user or
340
kernel access) for example.
341

    
342
* qemu_st_i32/i64 t0, t1, flags
343
qemu_st8_i32/i64 t0, t1, flags
344
qemu_st16_i32/i64 t0, t1, flags
345
qemu_st32_i64 t0, t1, flags
346

    
347
Store the data t0 at the QEMU CPU Address t1. t1 has the QEMU CPU
348
address type. 'flags' contains the QEMU memory index (selects user or
349
kernel access) for example.
350

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

    
354
Note 2: When using TCG, the opcodes must never be generated directly
355
as some of them may not be available as "real" opcodes. Always use the
356
function tcg_gen_xxx(args).
357

    
358
4) Backend
359

    
360
tcg-target.h contains the target specific definitions. tcg-target.c
361
contains the target specific code.
362

    
363
4.1) Assumptions
364

    
365
The target word size (TCG_TARGET_REG_BITS) is expected to be 32 bit or
366
64 bit. It is expected that the pointer has the same size as the word.
367

    
368
On a 32 bit target, all 64 bit operations are converted to 32 bits. A
369
few specific operations must be implemented to allow it (see add2_i32,
370
sub2_i32, brcond2_i32).
371

    
372
Floating point operations are not supported in this version. A
373
previous incarnation of the code generator had full support of them,
374
but it is better to concentrate on integer operations first.
375

    
376
On a 64 bit target, no assumption is made in TCG about the storage of
377
the 32 bit values in 64 bit registers.
378

    
379
4.2) Constraints
380

    
381
GCC like constraints are used to define the constraints of every
382
instruction. Memory constraints are not supported in this
383
version. Aliases are specified in the input operands as for GCC.
384

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

    
389
The movi_i32 and movi_i64 operations must accept any constants.
390

    
391
The mov_i32 and mov_i64 operations must accept any registers of the
392
same type.
393

    
394
The ld/st instructions must accept signed 32 bit constant offsets. It
395
can be implemented by reserving a specific register to compute the
396
address if the offset is too big.
397

    
398
The ld/st instructions must accept any destination (ld) or source (st)
399
register.
400

    
401
4.3) Function call assumptions
402

    
403
- The only supported types for parameters and return value are: 32 and
404
  64 bit integers and pointer.
405
- The stack grows downwards.
406
- The first N parameters are passed in registers.
407
- The next parameters are passed on the stack by storing them as words.
408
- Some registers are clobbered during the call. 
409
- The function can return 0 or 1 value in registers. On a 32 bit
410
  target, functions must be able to return 2 values in registers for
411
  64 bit return type.
412

    
413
5) Migration from dyngen to TCG
414

    
415
TCG is backward compatible with QEMU "dyngen" operations. It means
416
that TCG instructions can be freely mixed with dyngen operations. It
417
is expected that QEMU targets will be progressively fully converted to
418
TCG. Once a target is fully converted to TCG, it will be possible
419
to apply more optimizations because more registers will be free for
420
the generated code.
421

    
422
The exception model is the same as the dyngen one.
423

    
424
6) Recommended coding rules for best performance
425

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

    
430
- Avoid globals stored in fixed registers. They must be used only to
431
  store the pointer to the CPU state and possibly to store a pointer
432
  to a register window. The other uses are to ensure backward
433
  compatibility with dyngen during the porting a new target to TCG.
434

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

    
440
- Free temporaries and local temporaries when they are no longer used
441
  (tcg_temp_free). Since tcg_const_x() also creates a temporary, you
442
  should free it after it is used. Freeing temporaries does not yield
443
  a better generated code, but it reduces the memory usage of TCG and
444
  the speed of the translation.
445

    
446
- Don't hesitate to use helpers for complicated or seldom used target
447
  intructions. There is little performance advantage in using TCG to
448
  implement target instructions taking more than about twenty TCG
449
  instructions.
450

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