]>
Commit | Line | Data |
---|---|---|
c896fe29 FB |
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 | ||
bf28a69e PB |
11 | TCG receives RISC-like "TCG ops" and performs some optimizations on them, |
12 | including liveness analysis and trivial constant expression | |
13 | evaluation. TCG ops are then implemented in the host CPU back end, | |
14 | also known as the TCG "target". | |
15 | ||
c896fe29 FB |
16 | The TCG "target" is the architecture for which we generate the |
17 | code. It is of course not the same as the "target" of QEMU which is | |
18 | the emulated architecture. As TCG started as a generic C backend used | |
19 | for cross compiling, it is assumed that the TCG target is different | |
20 | from the host, although it is never the case for QEMU. | |
21 | ||
294e4669 CWR |
22 | In this document, we use "guest" to specify what architecture we are |
23 | emulating; "target" always means the TCG target, the machine on which | |
24 | we are running QEMU. | |
25 | ||
c896fe29 FB |
26 | A TCG "function" corresponds to a QEMU Translated Block (TB). |
27 | ||
0a6b7b78 FB |
28 | A TCG "temporary" is a variable only live in a basic |
29 | block. Temporaries are allocated explicitly in each function. | |
c896fe29 | 30 | |
0a6b7b78 FB |
31 | A TCG "local temporary" is a variable only live in a function. Local |
32 | temporaries are allocated explicitly in each function. | |
33 | ||
34 | A TCG "global" is a variable which is live in all the functions | |
35 | (equivalent of a C global variable). They are defined before the | |
36 | functions defined. A TCG global can be a memory location (e.g. a QEMU | |
37 | CPU register), a fixed host register (e.g. the QEMU CPU state pointer) | |
38 | or a memory location which is stored in a register outside QEMU TBs | |
39 | (not implemented yet). | |
c896fe29 FB |
40 | |
41 | A TCG "basic block" corresponds to a list of instructions terminated | |
42 | by a branch instruction. | |
43 | ||
20022fa1 RH |
44 | An operation with "undefined behavior" may result in a crash. |
45 | ||
46 | An operation with "unspecified behavior" shall not crash. However, | |
47 | the result may be one of several possibilities so may be considered | |
48 | an "undefined result". | |
49 | ||
c896fe29 FB |
50 | 3) Intermediate representation |
51 | ||
52 | 3.1) Introduction | |
53 | ||
0a6b7b78 FB |
54 | TCG instructions operate on variables which are temporaries, local |
55 | temporaries or globals. TCG instructions and variables are strongly | |
56 | typed. Two types are supported: 32 bit integers and 64 bit | |
57 | integers. Pointers are defined as an alias to 32 bit or 64 bit | |
58 | integers depending on the TCG target word size. | |
c896fe29 FB |
59 | |
60 | Each instruction has a fixed number of output variable operands, input | |
61 | variable operands and always constant operands. | |
62 | ||
63 | The notable exception is the call instruction which has a variable | |
64 | number of outputs and inputs. | |
65 | ||
0a6b7b78 FB |
66 | In the textual form, output operands usually come first, followed by |
67 | input operands, followed by constant operands. The output type is | |
68 | included in the instruction name. Constants are prefixed with a '$'. | |
c896fe29 FB |
69 | |
70 | add_i32 t0, t1, t2 (t0 <- t1 + t2) | |
71 | ||
c896fe29 FB |
72 | 3.2) Assumptions |
73 | ||
74 | * Basic blocks | |
75 | ||
76 | - Basic blocks end after branches (e.g. brcond_i32 instruction), | |
77 | goto_tb and exit_tb instructions. | |
86e840ee AJ |
78 | - Basic blocks start after the end of a previous basic block, or at a |
79 | set_label instruction. | |
c896fe29 | 80 | |
0a6b7b78 FB |
81 | After the end of a basic block, the content of temporaries is |
82 | destroyed, but local temporaries and globals are preserved. | |
c896fe29 FB |
83 | |
84 | * Floating point types are not supported yet | |
85 | ||
86 | * Pointers: depending on the TCG target, pointer size is 32 bit or 64 | |
87 | bit. The type TCG_TYPE_PTR is an alias to TCG_TYPE_I32 or | |
88 | TCG_TYPE_I64. | |
89 | ||
90 | * Helpers: | |
91 | ||
92 | Using the tcg_gen_helper_x_y it is possible to call any function | |
aa95e3a5 | 93 | taking i32, i64 or pointer types. By default, before calling a helper, |
a3f5054b | 94 | all globals are stored at their canonical location and it is assumed |
78505279 AJ |
95 | that the function can modify them. By default, the helper is allowed to |
96 | modify the CPU state or raise an exception. | |
97 | ||
98 | This can be overridden using the following function modifiers: | |
99 | - TCG_CALL_NO_READ_GLOBALS means that the helper does not read globals, | |
100 | either directly or via an exception. They will not be saved to their | |
101 | canonical locations before calling the helper. | |
102 | - TCG_CALL_NO_WRITE_GLOBALS means that the helper does not modify any globals. | |
103 | They will only be saved to their canonical location before calling helpers, | |
2bc89637 | 104 | but they won't be reloaded afterwards. |
78505279 AJ |
105 | - TCG_CALL_NO_SIDE_EFFECTS means that the call to the function is removed if |
106 | the return value is not used. | |
107 | ||
108 | Note that TCG_CALL_NO_READ_GLOBALS implies TCG_CALL_NO_WRITE_GLOBALS. | |
c896fe29 FB |
109 | |
110 | On some TCG targets (e.g. x86), several calling conventions are | |
111 | supported. | |
112 | ||
113 | * Branches: | |
114 | ||
626cd050 | 115 | Use the instruction 'br' to jump to a label. |
c896fe29 FB |
116 | |
117 | 3.3) Code Optimizations | |
118 | ||
119 | When generating instructions, you can count on at least the following | |
120 | optimizations: | |
121 | ||
122 | - Single instructions are simplified, e.g. | |
123 | ||
124 | and_i32 t0, t0, $0xffffffff | |
125 | ||
126 | is suppressed. | |
127 | ||
128 | - A liveness analysis is done at the basic block level. The | |
0a6b7b78 | 129 | information is used to suppress moves from a dead variable to |
c896fe29 FB |
130 | another one. It is also used to remove instructions which compute |
131 | dead results. The later is especially useful for condition code | |
9804c8e2 | 132 | optimization in QEMU. |
c896fe29 FB |
133 | |
134 | In the following example: | |
135 | ||
136 | add_i32 t0, t1, t2 | |
137 | add_i32 t0, t0, $1 | |
138 | mov_i32 t0, $1 | |
139 | ||
140 | only the last instruction is kept. | |
141 | ||
c896fe29 FB |
142 | 3.4) Instruction Reference |
143 | ||
144 | ********* Function call | |
145 | ||
146 | * call <ret> <params> ptr | |
147 | ||
148 | call function 'ptr' (pointer type) | |
149 | ||
150 | <ret> optional 32 bit or 64 bit return value | |
151 | <params> optional 32 bit or 64 bit parameters | |
152 | ||
153 | ********* Jumps/Labels | |
154 | ||
c896fe29 FB |
155 | * set_label $label |
156 | ||
157 | Define label 'label' at the current program point. | |
158 | ||
159 | * br $label | |
160 | ||
161 | Jump to label. | |
162 | ||
5a696f6a | 163 | * brcond_i32/i64 t0, t1, cond, label |
c896fe29 FB |
164 | |
165 | Conditional jump if t0 cond t1 is true. cond can be: | |
166 | TCG_COND_EQ | |
167 | TCG_COND_NE | |
168 | TCG_COND_LT /* signed */ | |
169 | TCG_COND_GE /* signed */ | |
170 | TCG_COND_LE /* signed */ | |
171 | TCG_COND_GT /* signed */ | |
172 | TCG_COND_LTU /* unsigned */ | |
173 | TCG_COND_GEU /* unsigned */ | |
174 | TCG_COND_LEU /* unsigned */ | |
175 | TCG_COND_GTU /* unsigned */ | |
176 | ||
177 | ********* Arithmetic | |
178 | ||
179 | * add_i32/i64 t0, t1, t2 | |
180 | ||
181 | t0=t1+t2 | |
182 | ||
183 | * sub_i32/i64 t0, t1, t2 | |
184 | ||
185 | t0=t1-t2 | |
186 | ||
390efc54 PB |
187 | * neg_i32/i64 t0, t1 |
188 | ||
189 | t0=-t1 (two's complement) | |
190 | ||
c896fe29 FB |
191 | * mul_i32/i64 t0, t1, t2 |
192 | ||
193 | t0=t1*t2 | |
194 | ||
195 | * div_i32/i64 t0, t1, t2 | |
196 | ||
197 | t0=t1/t2 (signed). Undefined behavior if division by zero or overflow. | |
198 | ||
199 | * divu_i32/i64 t0, t1, t2 | |
200 | ||
201 | t0=t1/t2 (unsigned). Undefined behavior if division by zero. | |
202 | ||
203 | * rem_i32/i64 t0, t1, t2 | |
204 | ||
205 | t0=t1%t2 (signed). Undefined behavior if division by zero or overflow. | |
206 | ||
207 | * remu_i32/i64 t0, t1, t2 | |
208 | ||
209 | t0=t1%t2 (unsigned). Undefined behavior if division by zero. | |
210 | ||
c896fe29 FB |
211 | ********* Logical |
212 | ||
5e85404a AJ |
213 | * and_i32/i64 t0, t1, t2 |
214 | ||
c896fe29 FB |
215 | t0=t1&t2 |
216 | ||
217 | * or_i32/i64 t0, t1, t2 | |
218 | ||
219 | t0=t1|t2 | |
220 | ||
221 | * xor_i32/i64 t0, t1, t2 | |
222 | ||
223 | t0=t1^t2 | |
224 | ||
0a6b7b78 FB |
225 | * not_i32/i64 t0, t1 |
226 | ||
227 | t0=~t1 | |
228 | ||
f24cb33e AJ |
229 | * andc_i32/i64 t0, t1, t2 |
230 | ||
231 | t0=t1&~t2 | |
232 | ||
233 | * eqv_i32/i64 t0, t1, t2 | |
234 | ||
8d625cf1 | 235 | t0=~(t1^t2), or equivalently, t0=t1^~t2 |
f24cb33e AJ |
236 | |
237 | * nand_i32/i64 t0, t1, t2 | |
238 | ||
239 | t0=~(t1&t2) | |
240 | ||
241 | * nor_i32/i64 t0, t1, t2 | |
242 | ||
243 | t0=~(t1|t2) | |
244 | ||
245 | * orc_i32/i64 t0, t1, t2 | |
246 | ||
247 | t0=t1|~t2 | |
248 | ||
0e28d006 RH |
249 | * clz_i32/i64 t0, t1, t2 |
250 | ||
251 | t0 = t1 ? clz(t1) : t2 | |
252 | ||
253 | * ctz_i32/i64 t0, t1, t2 | |
254 | ||
255 | t0 = t1 ? ctz(t1) : t2 | |
256 | ||
15824571 | 257 | ********* Shifts/Rotates |
c896fe29 FB |
258 | |
259 | * shl_i32/i64 t0, t1, t2 | |
260 | ||
20022fa1 | 261 | t0=t1 << t2. Unspecified behavior if t2 < 0 or t2 >= 32 (resp 64) |
c896fe29 FB |
262 | |
263 | * shr_i32/i64 t0, t1, t2 | |
264 | ||
20022fa1 | 265 | t0=t1 >> t2 (unsigned). Unspecified behavior if t2 < 0 or t2 >= 32 (resp 64) |
c896fe29 FB |
266 | |
267 | * sar_i32/i64 t0, t1, t2 | |
268 | ||
20022fa1 | 269 | t0=t1 >> t2 (signed). Unspecified behavior if t2 < 0 or t2 >= 32 (resp 64) |
c896fe29 | 270 | |
15824571 AJ |
271 | * rotl_i32/i64 t0, t1, t2 |
272 | ||
20022fa1 RH |
273 | Rotation of t2 bits to the left. |
274 | Unspecified behavior if t2 < 0 or t2 >= 32 (resp 64) | |
15824571 AJ |
275 | |
276 | * rotr_i32/i64 t0, t1, t2 | |
277 | ||
20022fa1 RH |
278 | Rotation of t2 bits to the right. |
279 | Unspecified behavior if t2 < 0 or t2 >= 32 (resp 64) | |
15824571 | 280 | |
c896fe29 FB |
281 | ********* Misc |
282 | ||
283 | * mov_i32/i64 t0, t1 | |
284 | ||
285 | t0 = t1 | |
286 | ||
287 | Move t1 to t0 (both operands must have the same type). | |
288 | ||
289 | * ext8s_i32/i64 t0, t1 | |
86831435 | 290 | ext8u_i32/i64 t0, t1 |
c896fe29 | 291 | ext16s_i32/i64 t0, t1 |
86831435 | 292 | ext16u_i32/i64 t0, t1 |
c896fe29 | 293 | ext32s_i64 t0, t1 |
86831435 | 294 | ext32u_i64 t0, t1 |
c896fe29 | 295 | |
86831435 | 296 | 8, 16 or 32 bit sign/zero extension (both operands must have the same type) |
c896fe29 | 297 | |
4ad4ce16 | 298 | * bswap16_i32/i64 t0, t1 |
c896fe29 | 299 | |
837d987b AJ |
300 | 16 bit byte swap on a 32/64 bit value. It assumes that the two/six high order |
301 | bytes are set to zero. | |
c896fe29 | 302 | |
4ad4ce16 | 303 | * bswap32_i32/i64 t0, t1 |
c896fe29 | 304 | |
837d987b AJ |
305 | 32 bit byte swap on a 32/64 bit value. With a 64 bit value, it assumes that |
306 | the four high order bytes are set to zero. | |
c896fe29 | 307 | |
4ad4ce16 | 308 | * bswap64_i64 t0, t1 |
c896fe29 FB |
309 | |
310 | 64 bit byte swap | |
311 | ||
5ff9d6a4 FB |
312 | * discard_i32/i64 t0 |
313 | ||
314 | Indicate that the value of t0 won't be used later. It is useful to | |
315 | force dead code elimination. | |
316 | ||
3a34dfd7 | 317 | * deposit_i32/i64 dest, t1, t2, pos, len |
b7767f0f RH |
318 | |
319 | Deposit T2 as a bitfield into T1, placing the result in DEST. | |
3a34dfd7 | 320 | The bitfield is described by POS/LEN, which are immediate values: |
b7767f0f RH |
321 | |
322 | LEN - the length of the bitfield | |
323 | POS - the position of the first bit, counting from the LSB | |
324 | ||
7ec8bab3 RH |
325 | For example, "deposit_i32 dest, t1, t2, 8, 4" indicates a 4-bit field |
326 | at bit 8. This operation would be equivalent to | |
b7767f0f RH |
327 | |
328 | dest = (t1 & ~0x0f00) | ((t2 << 8) & 0x0f00) | |
329 | ||
7ec8bab3 RH |
330 | * extract_i32/i64 dest, t1, pos, len |
331 | * sextract_i32/i64 dest, t1, pos, len | |
332 | ||
333 | Extract a bitfield from T1, placing the result in DEST. | |
334 | The bitfield is described by POS/LEN, which are immediate values, | |
335 | as above for deposit. For extract_*, the result will be extended | |
336 | to the left with zeros; for sextract_*, the result will be extended | |
337 | to the left with copies of the bitfield sign bit at pos + len - 1. | |
338 | ||
339 | For example, "sextract_i32 dest, t1, 8, 4" indicates a 4-bit field | |
340 | at bit 8. This operation would be equivalent to | |
341 | ||
342 | dest = (t1 << 20) >> 28 | |
343 | ||
344 | (using an arithmetic right shift). | |
345 | ||
fce1296f RH |
346 | * extract2_i32/i64 dest, t1, t2, pos |
347 | ||
348 | For N = {32,64}, extract an N-bit quantity from the concatenation | |
349 | of t2:t1, beginning at pos. The tcg_gen_extract2_{i32,i64} expander | |
350 | accepts 0 <= pos <= N as inputs. The backend code generator will | |
351 | not see either 0 or N as inputs for these opcodes. | |
352 | ||
609ad705 | 353 | * extrl_i64_i32 t0, t1 |
4bb7a41e | 354 | |
609ad705 RH |
355 | For 64-bit hosts only, extract the low 32-bits of input T1 and place it |
356 | into 32-bit output T0. Depending on the host, this may be a simple move, | |
357 | or may require additional canonicalization. | |
358 | ||
359 | * extrh_i64_i32 t0, t1 | |
360 | ||
361 | For 64-bit hosts only, extract the high 32-bits of input T1 and place it | |
362 | into 32-bit output T0. Depending on the host, this may be a simple shift, | |
363 | or may require additional canonicalization. | |
b7767f0f | 364 | |
be210acb RH |
365 | ********* Conditional moves |
366 | ||
5a696f6a | 367 | * setcond_i32/i64 dest, t1, t2, cond |
be210acb RH |
368 | |
369 | dest = (t1 cond t2) | |
370 | ||
371 | Set DEST to 1 if (T1 cond T2) is true, otherwise set to 0. | |
372 | ||
5a696f6a | 373 | * movcond_i32/i64 dest, c1, c2, v1, v2, cond |
ffc5ea09 RH |
374 | |
375 | dest = (c1 cond c2 ? v1 : v2) | |
376 | ||
377 | Set DEST to V1 if (C1 cond C2) is true, otherwise set to V2. | |
378 | ||
c896fe29 FB |
379 | ********* Type conversions |
380 | ||
381 | * ext_i32_i64 t0, t1 | |
382 | Convert t1 (32 bit) to t0 (64 bit) and does sign extension | |
383 | ||
384 | * extu_i32_i64 t0, t1 | |
385 | Convert t1 (32 bit) to t0 (64 bit) and does zero extension | |
386 | ||
387 | * trunc_i64_i32 t0, t1 | |
388 | Truncate t1 (64 bit) to t0 (32 bit) | |
389 | ||
36aa55dc PB |
390 | * concat_i32_i64 t0, t1, t2 |
391 | Construct t0 (64-bit) taking the low half from t1 (32 bit) and the high half | |
392 | from t2 (32 bit). | |
393 | ||
945ca823 BS |
394 | * concat32_i64 t0, t1, t2 |
395 | Construct t0 (64-bit) taking the low half from t1 (64 bit) and the high half | |
396 | from t2 (64 bit). | |
397 | ||
c896fe29 FB |
398 | ********* Load/Store |
399 | ||
400 | * ld_i32/i64 t0, t1, offset | |
401 | ld8s_i32/i64 t0, t1, offset | |
402 | ld8u_i32/i64 t0, t1, offset | |
403 | ld16s_i32/i64 t0, t1, offset | |
404 | ld16u_i32/i64 t0, t1, offset | |
405 | ld32s_i64 t0, t1, offset | |
406 | ld32u_i64 t0, t1, offset | |
407 | ||
408 | t0 = read(t1 + offset) | |
409 | Load 8, 16, 32 or 64 bits with or without sign extension from host memory. | |
410 | offset must be a constant. | |
411 | ||
412 | * st_i32/i64 t0, t1, offset | |
413 | st8_i32/i64 t0, t1, offset | |
414 | st16_i32/i64 t0, t1, offset | |
415 | st32_i64 t0, t1, offset | |
416 | ||
417 | write(t0, t1 + offset) | |
418 | Write 8, 16, 32 or 64 bits to host memory. | |
419 | ||
b202d41e AJ |
420 | All this opcodes assume that the pointed host memory doesn't correspond |
421 | to a global. In the latter case the behaviour is unpredictable. | |
422 | ||
d7156f7c RH |
423 | ********* Multiword arithmetic support |
424 | ||
425 | * add2_i32/i64 t0_low, t0_high, t1_low, t1_high, t2_low, t2_high | |
426 | * sub2_i32/i64 t0_low, t0_high, t1_low, t1_high, t2_low, t2_high | |
427 | ||
428 | Similar to add/sub, except that the double-word inputs T1 and T2 are | |
429 | formed from two single-word arguments, and the double-word output T0 | |
430 | is returned in two single-word outputs. | |
431 | ||
432 | * mulu2_i32/i64 t0_low, t0_high, t1, t2 | |
433 | ||
434 | Similar to mul, except two unsigned inputs T1 and T2 yielding the full | |
435 | double-word product T0. The later is returned in two single-word outputs. | |
436 | ||
4d3203fd RH |
437 | * muls2_i32/i64 t0_low, t0_high, t1, t2 |
438 | ||
439 | Similar to mulu2, except the two inputs T1 and T2 are signed. | |
440 | ||
d1030212 RH |
441 | * mulsh_i32/i64 t0, t1, t2 |
442 | * muluh_i32/i64 t0, t1, t2 | |
443 | ||
444 | Provide the high part of a signed or unsigned multiply, respectively. | |
445 | If mulu2/muls2 are not provided by the backend, the tcg-op generator | |
446 | can obtain the same results can be obtained by emitting a pair of | |
447 | opcodes, mul+muluh/mulsh. | |
448 | ||
f65e19bc PK |
449 | ********* Memory Barrier support |
450 | ||
451 | * mb <$arg> | |
452 | ||
453 | Generate a target memory barrier instruction to ensure memory ordering as being | |
454 | enforced by a corresponding guest memory barrier instruction. The ordering | |
455 | enforced by the backend may be stricter than the ordering required by the guest. | |
456 | It cannot be weaker. This opcode takes a constant argument which is required to | |
457 | generate the appropriate barrier instruction. The backend should take care to | |
458 | emit the target barrier instruction only when necessary i.e., for SMP guests and | |
459 | when MTTCG is enabled. | |
460 | ||
461 | The guest translators should generate this opcode for all guest instructions | |
462 | which have ordering side effects. | |
463 | ||
b208ac07 | 464 | Please see docs/devel/atomics.txt for more information on memory barriers. |
f65e19bc | 465 | |
294e4669 | 466 | ********* 64-bit guest on 32-bit host support |
a38e609c RH |
467 | |
468 | The following opcodes are internal to TCG. Thus they are to be implemented by | |
469 | 32-bit host code generators, but are not to be emitted by guest translators. | |
470 | They are emitted as needed by inline functions within "tcg-op.h". | |
471 | ||
5a696f6a | 472 | * brcond2_i32 t0_low, t0_high, t1_low, t1_high, cond, label |
a38e609c RH |
473 | |
474 | Similar to brcond, except that the 64-bit values T0 and T1 | |
475 | are formed from two 32-bit arguments. | |
476 | ||
5a696f6a | 477 | * setcond2_i32 dest, t1_low, t1_high, t2_low, t2_high, cond |
be210acb RH |
478 | |
479 | Similar to setcond, except that the 64-bit values T1 and T2 are | |
480 | formed from two 32-bit arguments. The result is a 32-bit value. | |
481 | ||
c896fe29 FB |
482 | ********* QEMU specific operations |
483 | ||
759c90ba | 484 | * exit_tb t0 |
c896fe29 FB |
485 | |
486 | Exit the current TB and return the value t0 (word type). | |
487 | ||
488 | * goto_tb index | |
489 | ||
490 | Exit the current TB and jump to the TB index 'index' (constant) if the | |
491 | current TB was linked to this TB. Otherwise execute the next | |
9bacf414 MF |
492 | instructions. Only indices 0 and 1 are valid and tcg_gen_goto_tb may be issued |
493 | at most once with each slot index per TB. | |
c896fe29 | 494 | |
cedbcb01 EC |
495 | * lookup_and_goto_ptr tb_addr |
496 | ||
497 | Look up a TB address ('tb_addr') and jump to it if valid. If not valid, | |
498 | jump to the TCG epilogue to go back to the exec loop. | |
499 | ||
500 | This operation is optional. If the TCG backend does not implement the | |
501 | goto_ptr opcode, emitting this op is equivalent to emitting exit_tb(0). | |
502 | ||
f713d6ad RH |
503 | * qemu_ld_i32/i64 t0, t1, flags, memidx |
504 | * qemu_st_i32/i64 t0, t1, flags, memidx | |
505 | ||
506 | Load data at the guest address t1 into t0, or store data in t0 at guest | |
507 | address t1. The _i32/_i64 size applies to the size of the input/output | |
508 | register t0 only. The address t1 is always sized according to the guest, | |
509 | and the width of the memory operation is controlled by flags. | |
510 | ||
511 | Both t0 and t1 may be split into little-endian ordered pairs of registers | |
512 | if dealing with 64-bit quantities on a 32-bit host. | |
513 | ||
514 | The memidx selects the qemu tlb index to use (e.g. user or kernel access). | |
14776ab5 | 515 | The flags are the MemOp bits, selecting the sign, width, and endianness |
f713d6ad RH |
516 | of the memory access. |
517 | ||
518 | For a 32-bit host, qemu_ld/st_i64 is guaranteed to only be used with a | |
519 | 64-bit memory access specified in flags. | |
520 | ||
d2fd745f RH |
521 | ********* Host vector operations |
522 | ||
523 | All of the vector ops have two parameters, TCGOP_VECL & TCGOP_VECE. | |
524 | The former specifies the length of the vector in log2 64-bit units; the | |
525 | later specifies the length of the element (if applicable) in log2 8-bit units. | |
526 | E.g. VECL=1 -> 64 << 1 -> v128, and VECE=2 -> 1 << 2 -> i32. | |
527 | ||
528 | * mov_vec v0, v1 | |
529 | * ld_vec v0, t1 | |
530 | * st_vec v0, t1 | |
531 | ||
532 | Move, load and store. | |
533 | ||
534 | * dup_vec v0, r1 | |
535 | ||
536 | Duplicate the low N bits of R1 into VECL/VECE copies across V0. | |
537 | ||
538 | * dupi_vec v0, c | |
539 | ||
540 | Similarly, for a constant. | |
541 | Smaller values will be replicated to host register size by the expanders. | |
542 | ||
543 | * dup2_vec v0, r1, r2 | |
544 | ||
545 | Duplicate r2:r1 into VECL/64 copies across V0. This opcode is | |
546 | only present for 32-bit hosts. | |
547 | ||
548 | * add_vec v0, v1, v2 | |
549 | ||
550 | v0 = v1 + v2, in elements across the vector. | |
551 | ||
552 | * sub_vec v0, v1, v2 | |
553 | ||
554 | Similarly, v0 = v1 - v2. | |
555 | ||
3774030a RH |
556 | * mul_vec v0, v1, v2 |
557 | ||
558 | Similarly, v0 = v1 * v2. | |
559 | ||
d2fd745f RH |
560 | * neg_vec v0, v1 |
561 | ||
562 | Similarly, v0 = -v1. | |
563 | ||
bcefc902 RH |
564 | * abs_vec v0, v1 |
565 | ||
566 | Similarly, v0 = v1 < 0 ? -v1 : v1, in elements across the vector. | |
567 | ||
dd0a0fcd RH |
568 | * smin_vec: |
569 | * umin_vec: | |
570 | ||
571 | Similarly, v0 = MIN(v1, v2), for signed and unsigned element types. | |
572 | ||
573 | * smax_vec: | |
574 | * umax_vec: | |
575 | ||
576 | Similarly, v0 = MAX(v1, v2), for signed and unsigned element types. | |
577 | ||
8afaf050 RH |
578 | * ssadd_vec: |
579 | * sssub_vec: | |
580 | * usadd_vec: | |
581 | * ussub_vec: | |
582 | ||
583 | Signed and unsigned saturating addition and subtraction. If the true | |
584 | result is not representable within the element type, the element is | |
585 | set to the minimum or maximum value for the type. | |
586 | ||
d2fd745f RH |
587 | * and_vec v0, v1, v2 |
588 | * or_vec v0, v1, v2 | |
589 | * xor_vec v0, v1, v2 | |
590 | * andc_vec v0, v1, v2 | |
591 | * orc_vec v0, v1, v2 | |
592 | * not_vec v0, v1 | |
593 | ||
1d349821 | 594 | Similarly, logical operations with and without complement. |
d2fd745f RH |
595 | Note that VECE is unused. |
596 | ||
d0ec9796 RH |
597 | * shli_vec v0, v1, i2 |
598 | * shls_vec v0, v1, s2 | |
599 | ||
600 | Shift all elements from v1 by a scalar i2/s2. I.e. | |
601 | ||
602 | for (i = 0; i < VECL/VECE; ++i) { | |
603 | v0[i] = v1[i] << s2; | |
604 | } | |
605 | ||
606 | * shri_vec v0, v1, i2 | |
607 | * sari_vec v0, v1, i2 | |
608 | * shrs_vec v0, v1, s2 | |
609 | * sars_vec v0, v1, s2 | |
610 | ||
611 | Similarly for logical and arithmetic right shift. | |
612 | ||
613 | * shlv_vec v0, v1, v2 | |
614 | ||
615 | Shift elements from v1 by elements from v2. I.e. | |
616 | ||
617 | for (i = 0; i < VECL/VECE; ++i) { | |
618 | v0[i] = v1[i] << v2[i]; | |
619 | } | |
620 | ||
621 | * shrv_vec v0, v1, v2 | |
622 | * sarv_vec v0, v1, v2 | |
623 | ||
624 | Similarly for logical and arithmetic right shift. | |
625 | ||
212be173 RH |
626 | * cmp_vec v0, v1, v2, cond |
627 | ||
628 | Compare vectors by element, storing -1 for true and 0 for false. | |
629 | ||
38dc1294 RH |
630 | * bitsel_vec v0, v1, v2, v3 |
631 | ||
632 | Bitwise select, v0 = (v2 & v1) | (v3 & ~v1), across the entire vector. | |
633 | ||
f75da298 RH |
634 | * cmpsel_vec v0, c1, c2, v3, v4, cond |
635 | ||
636 | Select elements based on comparison results: | |
637 | for (i = 0; i < n; ++i) { | |
638 | v0[i] = (c1[i] cond c2[i]) ? v3[i] : v4[i]. | |
639 | } | |
640 | ||
f713d6ad | 641 | ********* |
c896fe29 FB |
642 | |
643 | Note 1: Some shortcuts are defined when the last operand is known to be | |
644 | a constant (e.g. addi for add, movi for mov). | |
645 | ||
646 | Note 2: When using TCG, the opcodes must never be generated directly | |
647 | as some of them may not be available as "real" opcodes. Always use the | |
648 | function tcg_gen_xxx(args). | |
649 | ||
650 | 4) Backend | |
651 | ||
ce151109 PM |
652 | tcg-target.h contains the target specific definitions. tcg-target.inc.c |
653 | contains the target specific code; it is #included by tcg/tcg.c, rather | |
654 | than being a standalone C file. | |
c896fe29 FB |
655 | |
656 | 4.1) Assumptions | |
657 | ||
658 | The target word size (TCG_TARGET_REG_BITS) is expected to be 32 bit or | |
659 | 64 bit. It is expected that the pointer has the same size as the word. | |
660 | ||
661 | On a 32 bit target, all 64 bit operations are converted to 32 bits. A | |
662 | few specific operations must be implemented to allow it (see add2_i32, | |
663 | sub2_i32, brcond2_i32). | |
664 | ||
cb8d4c8f | 665 | On a 64 bit target, the values are transferred between 32 and 64-bit |
870ad154 AJ |
666 | registers using the following ops: |
667 | - trunc_shr_i64_i32 | |
668 | - ext_i32_i64 | |
669 | - extu_i32_i64 | |
670 | ||
671 | They ensure that the values are correctly truncated or extended when | |
672 | moved from a 32-bit to a 64-bit register or vice-versa. Note that the | |
673 | trunc_shr_i64_i32 is an optional op. It is not necessary to implement | |
674 | it if all the following conditions are met: | |
675 | - 64-bit registers can hold 32-bit values | |
676 | - 32-bit values in a 64-bit register do not need to stay zero or | |
677 | sign extended | |
678 | - all 32-bit TCG ops ignore the high part of 64-bit registers | |
679 | ||
c896fe29 FB |
680 | Floating point operations are not supported in this version. A |
681 | previous incarnation of the code generator had full support of them, | |
682 | but it is better to concentrate on integer operations first. | |
683 | ||
c896fe29 FB |
684 | 4.2) Constraints |
685 | ||
686 | GCC like constraints are used to define the constraints of every | |
687 | instruction. Memory constraints are not supported in this | |
688 | version. Aliases are specified in the input operands as for GCC. | |
689 | ||
0c5f3c8d PB |
690 | The same register may be used for both an input and an output, even when |
691 | they are not explicitly aliased. If an op expands to multiple target | |
692 | instructions then care must be taken to avoid clobbering input values. | |
17280ff4 | 693 | GCC style "early clobber" outputs are supported, with '&'. |
0c5f3c8d | 694 | |
c896fe29 FB |
695 | A target can define specific register or constant constraints. If an |
696 | operation uses a constant input constraint which does not allow all | |
697 | constants, it must also accept registers in order to have a fallback. | |
17280ff4 RH |
698 | The constraint 'i' is defined generically to accept any constant. |
699 | The constraint 'r' is not defined generically, but is consistently | |
700 | used by each backend to indicate all registers. | |
c896fe29 FB |
701 | |
702 | The movi_i32 and movi_i64 operations must accept any constants. | |
703 | ||
704 | The mov_i32 and mov_i64 operations must accept any registers of the | |
705 | same type. | |
706 | ||
17280ff4 RH |
707 | The ld/st/sti instructions must accept signed 32 bit constant offsets. |
708 | This can be implemented by reserving a specific register in which to | |
709 | compute the address if the offset is too big. | |
c896fe29 FB |
710 | |
711 | The ld/st instructions must accept any destination (ld) or source (st) | |
712 | register. | |
713 | ||
17280ff4 RH |
714 | The sti instruction may fail if it cannot store the given constant. |
715 | ||
c896fe29 FB |
716 | 4.3) Function call assumptions |
717 | ||
718 | - The only supported types for parameters and return value are: 32 and | |
719 | 64 bit integers and pointer. | |
720 | - The stack grows downwards. | |
721 | - The first N parameters are passed in registers. | |
722 | - The next parameters are passed on the stack by storing them as words. | |
723 | - Some registers are clobbered during the call. | |
724 | - The function can return 0 or 1 value in registers. On a 32 bit | |
725 | target, functions must be able to return 2 values in registers for | |
726 | 64 bit return type. | |
727 | ||
86e840ee | 728 | 5) Recommended coding rules for best performance |
0a6b7b78 FB |
729 | |
730 | - Use globals to represent the parts of the QEMU CPU state which are | |
731 | often modified, e.g. the integer registers and the condition | |
732 | codes. TCG will be able to use host registers to store them. | |
733 | ||
734 | - Avoid globals stored in fixed registers. They must be used only to | |
735 | store the pointer to the CPU state and possibly to store a pointer | |
86e840ee | 736 | to a register window. |
0a6b7b78 FB |
737 | |
738 | - Use temporaries. Use local temporaries only when really needed, | |
739 | e.g. when you need to use a value after a jump. Local temporaries | |
740 | introduce a performance hit in the current TCG implementation: their | |
741 | content is saved to memory at end of each basic block. | |
742 | ||
743 | - Free temporaries and local temporaries when they are no longer used | |
744 | (tcg_temp_free). Since tcg_const_x() also creates a temporary, you | |
745 | should free it after it is used. Freeing temporaries does not yield | |
746 | a better generated code, but it reduces the memory usage of TCG and | |
747 | the speed of the translation. | |
748 | ||
294e4669 | 749 | - Don't hesitate to use helpers for complicated or seldom used guest |
aa95e3a5 | 750 | instructions. There is little performance advantage in using TCG to |
294e4669 | 751 | implement guest instructions taking more than about twenty TCG |
107a47cc PM |
752 | instructions. Note that this rule of thumb is more applicable to |
753 | helpers doing complex logic or arithmetic, where the C compiler has | |
754 | scope to do a good job of optimisation; it is less relevant where | |
755 | the instruction is mostly doing loads and stores, and in those cases | |
756 | inline TCG may still be faster for longer sequences. | |
757 | ||
758 | - The hard limit on the number of TCG instructions you can generate | |
294e4669 | 759 | per guest instruction is set by MAX_OP_PER_INSTR in exec-all.h -- |
107a47cc | 760 | you cannot exceed this without risking a buffer overrun. |
0a6b7b78 FB |
761 | |
762 | - Use the 'discard' instruction if you know that TCG won't be able to | |
763 | prove that a given global is "dead" at a given program point. The | |
294e4669 | 764 | x86 guest uses it to improve the condition codes optimisation. |