Statistics
| Branch: | Revision:

root / tcg / README @ 0a6b7b78

History | View | Annotate | Download (12.1 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
********* Load/Store
269

    
270
* ld_i32/i64 t0, t1, offset
271
ld8s_i32/i64 t0, t1, offset
272
ld8u_i32/i64 t0, t1, offset
273
ld16s_i32/i64 t0, t1, offset
274
ld16u_i32/i64 t0, t1, offset
275
ld32s_i64 t0, t1, offset
276
ld32u_i64 t0, t1, offset
277

    
278
t0 = read(t1 + offset)
279
Load 8, 16, 32 or 64 bits with or without sign extension from host memory. 
280
offset must be a constant.
281

    
282
* st_i32/i64 t0, t1, offset
283
st8_i32/i64 t0, t1, offset
284
st16_i32/i64 t0, t1, offset
285
st32_i64 t0, t1, offset
286

    
287
write(t0, t1 + offset)
288
Write 8, 16, 32 or 64 bits to host memory.
289

    
290
********* QEMU specific operations
291

    
292
* tb_exit t0
293

    
294
Exit the current TB and return the value t0 (word type).
295

    
296
* goto_tb index
297

    
298
Exit the current TB and jump to the TB index 'index' (constant) if the
299
current TB was linked to this TB. Otherwise execute the next
300
instructions.
301

    
302
* qemu_ld_i32/i64 t0, t1, flags
303
qemu_ld8u_i32/i64 t0, t1, flags
304
qemu_ld8s_i32/i64 t0, t1, flags
305
qemu_ld16u_i32/i64 t0, t1, flags
306
qemu_ld16s_i32/i64 t0, t1, flags
307
qemu_ld32u_i64 t0, t1, flags
308
qemu_ld32s_i64 t0, t1, flags
309

    
310
Load data at the QEMU CPU address t1 into t0. t1 has the QEMU CPU
311
address type. 'flags' contains the QEMU memory index (selects user or
312
kernel access) for example.
313

    
314
* qemu_st_i32/i64 t0, t1, flags
315
qemu_st8_i32/i64 t0, t1, flags
316
qemu_st16_i32/i64 t0, t1, flags
317
qemu_st32_i64 t0, t1, flags
318

    
319
Store the data t0 at the QEMU CPU Address t1. t1 has the QEMU CPU
320
address type. 'flags' contains the QEMU memory index (selects user or
321
kernel access) for example.
322

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

    
326
Note 2: When using TCG, the opcodes must never be generated directly
327
as some of them may not be available as "real" opcodes. Always use the
328
function tcg_gen_xxx(args).
329

    
330
4) Backend
331

    
332
tcg-target.h contains the target specific definitions. tcg-target.c
333
contains the target specific code.
334

    
335
4.1) Assumptions
336

    
337
The target word size (TCG_TARGET_REG_BITS) is expected to be 32 bit or
338
64 bit. It is expected that the pointer has the same size as the word.
339

    
340
On a 32 bit target, all 64 bit operations are converted to 32 bits. A
341
few specific operations must be implemented to allow it (see add2_i32,
342
sub2_i32, brcond2_i32).
343

    
344
Floating point operations are not supported in this version. A
345
previous incarnation of the code generator had full support of them,
346
but it is better to concentrate on integer operations first.
347

    
348
On a 64 bit target, no assumption is made in TCG about the storage of
349
the 32 bit values in 64 bit registers.
350

    
351
4.2) Constraints
352

    
353
GCC like constraints are used to define the constraints of every
354
instruction. Memory constraints are not supported in this
355
version. Aliases are specified in the input operands as for GCC.
356

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

    
361
The movi_i32 and movi_i64 operations must accept any constants.
362

    
363
The mov_i32 and mov_i64 operations must accept any registers of the
364
same type.
365

    
366
The ld/st instructions must accept signed 32 bit constant offsets. It
367
can be implemented by reserving a specific register to compute the
368
address if the offset is too big.
369

    
370
The ld/st instructions must accept any destination (ld) or source (st)
371
register.
372

    
373
4.3) Function call assumptions
374

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

    
385
5) Migration from dyngen to TCG
386

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

    
394
The exception model is the same as the dyngen one.
395

    
396
6) Recommended coding rules for best performance
397

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

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

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

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

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

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