1 | This is Info file gcc.info, produced by Makeinfo version 1.67 from the |
---|
2 | input file gcc.texi. |
---|
3 | |
---|
4 | This file documents the use and the internals of the GNU compiler. |
---|
5 | |
---|
6 | Published by the Free Software Foundation 59 Temple Place - Suite 330 |
---|
7 | Boston, MA 02111-1307 USA |
---|
8 | |
---|
9 | Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998 |
---|
10 | Free Software Foundation, Inc. |
---|
11 | |
---|
12 | Permission is granted to make and distribute verbatim copies of this |
---|
13 | manual provided the copyright notice and this permission notice are |
---|
14 | preserved on all copies. |
---|
15 | |
---|
16 | Permission is granted to copy and distribute modified versions of |
---|
17 | this manual under the conditions for verbatim copying, provided also |
---|
18 | that the sections entitled "GNU General Public License," "Funding for |
---|
19 | Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are |
---|
20 | included exactly as in the original, and provided that the entire |
---|
21 | resulting derived work is distributed under the terms of a permission |
---|
22 | notice identical to this one. |
---|
23 | |
---|
24 | Permission is granted to copy and distribute translations of this |
---|
25 | manual into another language, under the above conditions for modified |
---|
26 | versions, except that the sections entitled "GNU General Public |
---|
27 | License," "Funding for Free Software," and "Protect Your Freedom--Fight |
---|
28 | `Look And Feel'", and this permission notice, may be included in |
---|
29 | translations approved by the Free Software Foundation instead of in the |
---|
30 | original English. |
---|
31 | |
---|
32 | |
---|
33 | File: gcc.info, Node: Output Template, Next: Output Statement, Prev: RTL Template, Up: Machine Desc |
---|
34 | |
---|
35 | Output Templates and Operand Substitution |
---|
36 | ========================================= |
---|
37 | |
---|
38 | The "output template" is a string which specifies how to output the |
---|
39 | assembler code for an instruction pattern. Most of the template is a |
---|
40 | fixed string which is output literally. The character `%' is used to |
---|
41 | specify where to substitute an operand; it can also be used to identify |
---|
42 | places where different variants of the assembler require different |
---|
43 | syntax. |
---|
44 | |
---|
45 | In the simplest case, a `%' followed by a digit N says to output |
---|
46 | operand N at that point in the string. |
---|
47 | |
---|
48 | `%' followed by a letter and a digit says to output an operand in an |
---|
49 | alternate fashion. Four letters have standard, built-in meanings |
---|
50 | described below. The machine description macro `PRINT_OPERAND' can |
---|
51 | define additional letters with nonstandard meanings. |
---|
52 | |
---|
53 | `%cDIGIT' can be used to substitute an operand that is a constant |
---|
54 | value without the syntax that normally indicates an immediate operand. |
---|
55 | |
---|
56 | `%nDIGIT' is like `%cDIGIT' except that the value of the constant is |
---|
57 | negated before printing. |
---|
58 | |
---|
59 | `%aDIGIT' can be used to substitute an operand as if it were a |
---|
60 | memory reference, with the actual operand treated as the address. This |
---|
61 | may be useful when outputting a "load address" instruction, because |
---|
62 | often the assembler syntax for such an instruction requires you to |
---|
63 | write the operand as if it were a memory reference. |
---|
64 | |
---|
65 | `%lDIGIT' is used to substitute a `label_ref' into a jump |
---|
66 | instruction. |
---|
67 | |
---|
68 | `%=' outputs a number which is unique to each instruction in the |
---|
69 | entire compilation. This is useful for making local labels to be |
---|
70 | referred to more than once in a single template that generates multiple |
---|
71 | assembler instructions. |
---|
72 | |
---|
73 | `%' followed by a punctuation character specifies a substitution that |
---|
74 | does not use an operand. Only one case is standard: `%%' outputs a `%' |
---|
75 | into the assembler code. Other nonstandard cases can be defined in the |
---|
76 | `PRINT_OPERAND' macro. You must also define which punctuation |
---|
77 | characters are valid with the `PRINT_OPERAND_PUNCT_VALID_P' macro. |
---|
78 | |
---|
79 | The template may generate multiple assembler instructions. Write |
---|
80 | the text for the instructions, with `\;' between them. |
---|
81 | |
---|
82 | When the RTL contains two operands which are required by constraint |
---|
83 | to match each other, the output template must refer only to the |
---|
84 | lower-numbered operand. Matching operands are not always identical, |
---|
85 | and the rest of the compiler arranges to put the proper RTL expression |
---|
86 | for printing into the lower-numbered operand. |
---|
87 | |
---|
88 | One use of nonstandard letters or punctuation following `%' is to |
---|
89 | distinguish between different assembler languages for the same machine; |
---|
90 | for example, Motorola syntax versus MIT syntax for the 68000. Motorola |
---|
91 | syntax requires periods in most opcode names, while MIT syntax does |
---|
92 | not. For example, the opcode `movel' in MIT syntax is `move.l' in |
---|
93 | Motorola syntax. The same file of patterns is used for both kinds of |
---|
94 | output syntax, but the character sequence `%.' is used in each place |
---|
95 | where Motorola syntax wants a period. The `PRINT_OPERAND' macro for |
---|
96 | Motorola syntax defines the sequence to output a period; the macro for |
---|
97 | MIT syntax defines it to do nothing. |
---|
98 | |
---|
99 | As a special case, a template consisting of the single character `#' |
---|
100 | instructs the compiler to first split the insn, and then output the |
---|
101 | resulting instructions separately. This helps eliminate redundancy in |
---|
102 | the output templates. If you have a `define_insn' that needs to emit |
---|
103 | multiple assembler instructions, and there is an matching `define_split' |
---|
104 | already defined, then you can simply use `#' as the output template |
---|
105 | instead of writing an output template that emits the multiple assembler |
---|
106 | instructions. |
---|
107 | |
---|
108 | If the macro `ASSEMBLER_DIALECT' is defined, you can use construct |
---|
109 | of the form `{option0|option1|option2}' in the templates. These |
---|
110 | describe multiple variants of assembler language syntax. *Note |
---|
111 | Instruction Output::. |
---|
112 | |
---|
113 | |
---|
114 | File: gcc.info, Node: Output Statement, Next: Constraints, Prev: Output Template, Up: Machine Desc |
---|
115 | |
---|
116 | C Statements for Assembler Output |
---|
117 | ================================= |
---|
118 | |
---|
119 | Often a single fixed template string cannot produce correct and |
---|
120 | efficient assembler code for all the cases that are recognized by a |
---|
121 | single instruction pattern. For example, the opcodes may depend on the |
---|
122 | kinds of operands; or some unfortunate combinations of operands may |
---|
123 | require extra machine instructions. |
---|
124 | |
---|
125 | If the output control string starts with a `@', then it is actually |
---|
126 | a series of templates, each on a separate line. (Blank lines and |
---|
127 | leading spaces and tabs are ignored.) The templates correspond to the |
---|
128 | pattern's constraint alternatives (*note Multi-Alternative::.). For |
---|
129 | example, if a target machine has a two-address add instruction `addr' |
---|
130 | to add into a register and another `addm' to add a register to memory, |
---|
131 | you might write this pattern: |
---|
132 | |
---|
133 | (define_insn "addsi3" |
---|
134 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
---|
135 | (plus:SI (match_operand:SI 1 "general_operand" "0,0") |
---|
136 | (match_operand:SI 2 "general_operand" "g,r")))] |
---|
137 | "" |
---|
138 | "@ |
---|
139 | addr %2,%0 |
---|
140 | addm %2,%0") |
---|
141 | |
---|
142 | If the output control string starts with a `*', then it is not an |
---|
143 | output template but rather a piece of C program that should compute a |
---|
144 | template. It should execute a `return' statement to return the |
---|
145 | template-string you want. Most such templates use C string literals, |
---|
146 | which require doublequote characters to delimit them. To include these |
---|
147 | doublequote characters in the string, prefix each one with `\'. |
---|
148 | |
---|
149 | The operands may be found in the array `operands', whose C data type |
---|
150 | is `rtx []'. |
---|
151 | |
---|
152 | It is very common to select different ways of generating assembler |
---|
153 | code based on whether an immediate operand is within a certain range. |
---|
154 | Be careful when doing this, because the result of `INTVAL' is an |
---|
155 | integer on the host machine. If the host machine has more bits in an |
---|
156 | `int' than the target machine has in the mode in which the constant |
---|
157 | will be used, then some of the bits you get from `INTVAL' will be |
---|
158 | superfluous. For proper results, you must carefully disregard the |
---|
159 | values of those bits. |
---|
160 | |
---|
161 | It is possible to output an assembler instruction and then go on to |
---|
162 | output or compute more of them, using the subroutine `output_asm_insn'. |
---|
163 | This receives two arguments: a template-string and a vector of |
---|
164 | operands. The vector may be `operands', or it may be another array of |
---|
165 | `rtx' that you declare locally and initialize yourself. |
---|
166 | |
---|
167 | When an insn pattern has multiple alternatives in its constraints, |
---|
168 | often the appearance of the assembler code is determined mostly by |
---|
169 | which alternative was matched. When this is so, the C code can test |
---|
170 | the variable `which_alternative', which is the ordinal number of the |
---|
171 | alternative that was actually satisfied (0 for the first, 1 for the |
---|
172 | second alternative, etc.). |
---|
173 | |
---|
174 | For example, suppose there are two opcodes for storing zero, `clrreg' |
---|
175 | for registers and `clrmem' for memory locations. Here is how a pattern |
---|
176 | could use `which_alternative' to choose between them: |
---|
177 | |
---|
178 | (define_insn "" |
---|
179 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
---|
180 | (const_int 0))] |
---|
181 | "" |
---|
182 | "* |
---|
183 | return (which_alternative == 0 |
---|
184 | ? \"clrreg %0\" : \"clrmem %0\"); |
---|
185 | ") |
---|
186 | |
---|
187 | The example above, where the assembler code to generate was *solely* |
---|
188 | determined by the alternative, could also have been specified as |
---|
189 | follows, having the output control string start with a `@': |
---|
190 | |
---|
191 | (define_insn "" |
---|
192 | [(set (match_operand:SI 0 "general_operand" "=r,m") |
---|
193 | (const_int 0))] |
---|
194 | "" |
---|
195 | "@ |
---|
196 | clrreg %0 |
---|
197 | clrmem %0") |
---|
198 | |
---|
199 | |
---|
200 | File: gcc.info, Node: Constraints, Next: Standard Names, Prev: Output Statement, Up: Machine Desc |
---|
201 | |
---|
202 | Operand Constraints |
---|
203 | =================== |
---|
204 | |
---|
205 | Each `match_operand' in an instruction pattern can specify a |
---|
206 | constraint for the type of operands allowed. Constraints can say |
---|
207 | whether an operand may be in a register, and which kinds of register; |
---|
208 | whether the operand can be a memory reference, and which kinds of |
---|
209 | address; whether the operand may be an immediate constant, and which |
---|
210 | possible values it may have. Constraints can also require two operands |
---|
211 | to match. |
---|
212 | |
---|
213 | * Menu: |
---|
214 | |
---|
215 | * Simple Constraints:: Basic use of constraints. |
---|
216 | * Multi-Alternative:: When an insn has two alternative constraint-patterns. |
---|
217 | * Class Preferences:: Constraints guide which hard register to put things in. |
---|
218 | * Modifiers:: More precise control over effects of constraints. |
---|
219 | * Machine Constraints:: Existing constraints for some particular machines. |
---|
220 | * No Constraints:: Describing a clean machine without constraints. |
---|
221 | |
---|
222 | |
---|
223 | File: gcc.info, Node: Simple Constraints, Next: Multi-Alternative, Up: Constraints |
---|
224 | |
---|
225 | Simple Constraints |
---|
226 | ------------------ |
---|
227 | |
---|
228 | The simplest kind of constraint is a string full of letters, each of |
---|
229 | which describes one kind of operand that is permitted. Here are the |
---|
230 | letters that are allowed: |
---|
231 | |
---|
232 | `m' |
---|
233 | A memory operand is allowed, with any kind of address that the |
---|
234 | machine supports in general. |
---|
235 | |
---|
236 | `o' |
---|
237 | A memory operand is allowed, but only if the address is |
---|
238 | "offsettable". This means that adding a small integer (actually, |
---|
239 | the width in bytes of the operand, as determined by its machine |
---|
240 | mode) may be added to the address and the result is also a valid |
---|
241 | memory address. |
---|
242 | |
---|
243 | For example, an address which is constant is offsettable; so is an |
---|
244 | address that is the sum of a register and a constant (as long as a |
---|
245 | slightly larger constant is also within the range of |
---|
246 | address-offsets supported by the machine); but an autoincrement or |
---|
247 | autodecrement address is not offsettable. More complicated |
---|
248 | indirect/indexed addresses may or may not be offsettable depending |
---|
249 | on the other addressing modes that the machine supports. |
---|
250 | |
---|
251 | Note that in an output operand which can be matched by another |
---|
252 | operand, the constraint letter `o' is valid only when accompanied |
---|
253 | by both `<' (if the target machine has predecrement addressing) |
---|
254 | and `>' (if the target machine has preincrement addressing). |
---|
255 | |
---|
256 | `V' |
---|
257 | A memory operand that is not offsettable. In other words, |
---|
258 | anything that would fit the `m' constraint but not the `o' |
---|
259 | constraint. |
---|
260 | |
---|
261 | `<' |
---|
262 | A memory operand with autodecrement addressing (either |
---|
263 | predecrement or postdecrement) is allowed. |
---|
264 | |
---|
265 | `>' |
---|
266 | A memory operand with autoincrement addressing (either |
---|
267 | preincrement or postincrement) is allowed. |
---|
268 | |
---|
269 | `r' |
---|
270 | A register operand is allowed provided that it is in a general |
---|
271 | register. |
---|
272 | |
---|
273 | `d', `a', `f', ... |
---|
274 | Other letters can be defined in machine-dependent fashion to stand |
---|
275 | for particular classes of registers. `d', `a' and `f' are defined |
---|
276 | on the 68000/68020 to stand for data, address and floating point |
---|
277 | registers. |
---|
278 | |
---|
279 | `i' |
---|
280 | An immediate integer operand (one with constant value) is allowed. |
---|
281 | This includes symbolic constants whose values will be known only at |
---|
282 | assembly time. |
---|
283 | |
---|
284 | `n' |
---|
285 | An immediate integer operand with a known numeric value is allowed. |
---|
286 | Many systems cannot support assembly-time constants for operands |
---|
287 | less than a word wide. Constraints for these operands should use |
---|
288 | `n' rather than `i'. |
---|
289 | |
---|
290 | `I', `J', `K', ... `P' |
---|
291 | Other letters in the range `I' through `P' may be defined in a |
---|
292 | machine-dependent fashion to permit immediate integer operands with |
---|
293 | explicit integer values in specified ranges. For example, on the |
---|
294 | 68000, `I' is defined to stand for the range of values 1 to 8. |
---|
295 | This is the range permitted as a shift count in the shift |
---|
296 | instructions. |
---|
297 | |
---|
298 | `E' |
---|
299 | An immediate floating operand (expression code `const_double') is |
---|
300 | allowed, but only if the target floating point format is the same |
---|
301 | as that of the host machine (on which the compiler is running). |
---|
302 | |
---|
303 | `F' |
---|
304 | An immediate floating operand (expression code `const_double') is |
---|
305 | allowed. |
---|
306 | |
---|
307 | `G', `H' |
---|
308 | `G' and `H' may be defined in a machine-dependent fashion to |
---|
309 | permit immediate floating operands in particular ranges of values. |
---|
310 | |
---|
311 | `s' |
---|
312 | An immediate integer operand whose value is not an explicit |
---|
313 | integer is allowed. |
---|
314 | |
---|
315 | This might appear strange; if an insn allows a constant operand |
---|
316 | with a value not known at compile time, it certainly must allow |
---|
317 | any known value. So why use `s' instead of `i'? Sometimes it |
---|
318 | allows better code to be generated. |
---|
319 | |
---|
320 | For example, on the 68000 in a fullword instruction it is possible |
---|
321 | to use an immediate operand; but if the immediate value is between |
---|
322 | -128 and 127, better code results from loading the value into a |
---|
323 | register and using the register. This is because the load into |
---|
324 | the register can be done with a `moveq' instruction. We arrange |
---|
325 | for this to happen by defining the letter `K' to mean "any integer |
---|
326 | outside the range -128 to 127", and then specifying `Ks' in the |
---|
327 | operand constraints. |
---|
328 | |
---|
329 | `g' |
---|
330 | Any register, memory or immediate integer operand is allowed, |
---|
331 | except for registers that are not general registers. |
---|
332 | |
---|
333 | `X' |
---|
334 | Any operand whatsoever is allowed, even if it does not satisfy |
---|
335 | `general_operand'. This is normally used in the constraint of a |
---|
336 | `match_scratch' when certain alternatives will not actually |
---|
337 | require a scratch register. |
---|
338 | |
---|
339 | `0', `1', `2', ... `9' |
---|
340 | An operand that matches the specified operand number is allowed. |
---|
341 | If a digit is used together with letters within the same |
---|
342 | alternative, the digit should come last. |
---|
343 | |
---|
344 | This is called a "matching constraint" and what it really means is |
---|
345 | that the assembler has only a single operand that fills two roles |
---|
346 | considered separate in the RTL insn. For example, an add insn has |
---|
347 | two input operands and one output operand in the RTL, but on most |
---|
348 | CISC machines an add instruction really has only two operands, one |
---|
349 | of them an input-output operand: |
---|
350 | |
---|
351 | addl #35,r12 |
---|
352 | |
---|
353 | Matching constraints are used in these circumstances. More |
---|
354 | precisely, the two operands that match must include one input-only |
---|
355 | operand and one output-only operand. Moreover, the digit must be a |
---|
356 | smaller number than the number of the operand that uses it in the |
---|
357 | constraint. |
---|
358 | |
---|
359 | For operands to match in a particular case usually means that they |
---|
360 | are identical-looking RTL expressions. But in a few special cases |
---|
361 | specific kinds of dissimilarity are allowed. For example, `*x' as |
---|
362 | an input operand will match `*x++' as an output operand. For |
---|
363 | proper results in such cases, the output template should always |
---|
364 | use the output-operand's number when printing the operand. |
---|
365 | |
---|
366 | `p' |
---|
367 | An operand that is a valid memory address is allowed. This is for |
---|
368 | "load address" and "push address" instructions. |
---|
369 | |
---|
370 | `p' in the constraint must be accompanied by `address_operand' as |
---|
371 | the predicate in the `match_operand'. This predicate interprets |
---|
372 | the mode specified in the `match_operand' as the mode of the memory |
---|
373 | reference for which the address would be valid. |
---|
374 | |
---|
375 | `Q', `R', `S', ... `U' |
---|
376 | Letters in the range `Q' through `U' may be defined in a |
---|
377 | machine-dependent fashion to stand for arbitrary operand types. |
---|
378 | The machine description macro `EXTRA_CONSTRAINT' is passed the |
---|
379 | operand as its first argument and the constraint letter as its |
---|
380 | second operand. |
---|
381 | |
---|
382 | A typical use for this would be to distinguish certain types of |
---|
383 | memory references that affect other insn operands. |
---|
384 | |
---|
385 | Do not define these constraint letters to accept register |
---|
386 | references (`reg'); the reload pass does not expect this and would |
---|
387 | not handle it properly. |
---|
388 | |
---|
389 | In order to have valid assembler code, each operand must satisfy its |
---|
390 | constraint. But a failure to do so does not prevent the pattern from |
---|
391 | applying to an insn. Instead, it directs the compiler to modify the |
---|
392 | code so that the constraint will be satisfied. Usually this is done by |
---|
393 | copying an operand into a register. |
---|
394 | |
---|
395 | Contrast, therefore, the two instruction patterns that follow: |
---|
396 | |
---|
397 | (define_insn "" |
---|
398 | [(set (match_operand:SI 0 "general_operand" "=r") |
---|
399 | (plus:SI (match_dup 0) |
---|
400 | (match_operand:SI 1 "general_operand" "r")))] |
---|
401 | "" |
---|
402 | "...") |
---|
403 | |
---|
404 | which has two operands, one of which must appear in two places, and |
---|
405 | |
---|
406 | (define_insn "" |
---|
407 | [(set (match_operand:SI 0 "general_operand" "=r") |
---|
408 | (plus:SI (match_operand:SI 1 "general_operand" "0") |
---|
409 | (match_operand:SI 2 "general_operand" "r")))] |
---|
410 | "" |
---|
411 | "...") |
---|
412 | |
---|
413 | which has three operands, two of which are required by a constraint to |
---|
414 | be identical. If we are considering an insn of the form |
---|
415 | |
---|
416 | (insn N PREV NEXT |
---|
417 | (set (reg:SI 3) |
---|
418 | (plus:SI (reg:SI 6) (reg:SI 109))) |
---|
419 | ...) |
---|
420 | |
---|
421 | the first pattern would not apply at all, because this insn does not |
---|
422 | contain two identical subexpressions in the right place. The pattern |
---|
423 | would say, "That does not look like an add instruction; try other |
---|
424 | patterns." The second pattern would say, "Yes, that's an add |
---|
425 | instruction, but there is something wrong with it." It would direct |
---|
426 | the reload pass of the compiler to generate additional insns to make |
---|
427 | the constraint true. The results might look like this: |
---|
428 | |
---|
429 | (insn N2 PREV N |
---|
430 | (set (reg:SI 3) (reg:SI 6)) |
---|
431 | ...) |
---|
432 | |
---|
433 | (insn N N2 NEXT |
---|
434 | (set (reg:SI 3) |
---|
435 | (plus:SI (reg:SI 3) (reg:SI 109))) |
---|
436 | ...) |
---|
437 | |
---|
438 | It is up to you to make sure that each operand, in each pattern, has |
---|
439 | constraints that can handle any RTL expression that could be present for |
---|
440 | that operand. (When multiple alternatives are in use, each pattern |
---|
441 | must, for each possible combination of operand expressions, have at |
---|
442 | least one alternative which can handle that combination of operands.) |
---|
443 | The constraints don't need to *allow* any possible operand--when this is |
---|
444 | the case, they do not constrain--but they must at least point the way to |
---|
445 | reloading any possible operand so that it will fit. |
---|
446 | |
---|
447 | * If the constraint accepts whatever operands the predicate permits, |
---|
448 | there is no problem: reloading is never necessary for this operand. |
---|
449 | |
---|
450 | For example, an operand whose constraints permit everything except |
---|
451 | registers is safe provided its predicate rejects registers. |
---|
452 | |
---|
453 | An operand whose predicate accepts only constant values is safe |
---|
454 | provided its constraints include the letter `i'. If any possible |
---|
455 | constant value is accepted, then nothing less than `i' will do; if |
---|
456 | the predicate is more selective, then the constraints may also be |
---|
457 | more selective. |
---|
458 | |
---|
459 | * Any operand expression can be reloaded by copying it into a |
---|
460 | register. So if an operand's constraints allow some kind of |
---|
461 | register, it is certain to be safe. It need not permit all |
---|
462 | classes of registers; the compiler knows how to copy a register |
---|
463 | into another register of the proper class in order to make an |
---|
464 | instruction valid. |
---|
465 | |
---|
466 | * A nonoffsettable memory reference can be reloaded by copying the |
---|
467 | address into a register. So if the constraint uses the letter |
---|
468 | `o', all memory references are taken care of. |
---|
469 | |
---|
470 | * A constant operand can be reloaded by allocating space in memory to |
---|
471 | hold it as preinitialized data. Then the memory reference can be |
---|
472 | used in place of the constant. So if the constraint uses the |
---|
473 | letters `o' or `m', constant operands are not a problem. |
---|
474 | |
---|
475 | * If the constraint permits a constant and a pseudo register used in |
---|
476 | an insn was not allocated to a hard register and is equivalent to |
---|
477 | a constant, the register will be replaced with the constant. If |
---|
478 | the predicate does not permit a constant and the insn is |
---|
479 | re-recognized for some reason, the compiler will crash. Thus the |
---|
480 | predicate must always recognize any objects allowed by the |
---|
481 | constraint. |
---|
482 | |
---|
483 | If the operand's predicate can recognize registers, but the |
---|
484 | constraint does not permit them, it can make the compiler crash. When |
---|
485 | this operand happens to be a register, the reload pass will be stymied, |
---|
486 | because it does not know how to copy a register temporarily into memory. |
---|
487 | |
---|
488 | If the predicate accepts a unary operator, the constraint applies to |
---|
489 | the operand. For example, the MIPS processor at ISA level 3 supports an |
---|
490 | instruction which adds two registers in `SImode' to produce a `DImode' |
---|
491 | result, but only if the registers are correctly sign extended. This |
---|
492 | predicate for the input operands accepts a `sign_extend' of an `SImode' |
---|
493 | register. Write the constraint to indicate the type of register that |
---|
494 | is required for the operand of the `sign_extend'. |
---|
495 | |
---|
496 | |
---|
497 | File: gcc.info, Node: Multi-Alternative, Next: Class Preferences, Prev: Simple Constraints, Up: Constraints |
---|
498 | |
---|
499 | Multiple Alternative Constraints |
---|
500 | -------------------------------- |
---|
501 | |
---|
502 | Sometimes a single instruction has multiple alternative sets of |
---|
503 | possible operands. For example, on the 68000, a logical-or instruction |
---|
504 | can combine register or an immediate value into memory, or it can |
---|
505 | combine any kind of operand into a register; but it cannot combine one |
---|
506 | memory location into another. |
---|
507 | |
---|
508 | These constraints are represented as multiple alternatives. An |
---|
509 | alternative can be described by a series of letters for each operand. |
---|
510 | The overall constraint for an operand is made from the letters for this |
---|
511 | operand from the first alternative, a comma, the letters for this |
---|
512 | operand from the second alternative, a comma, and so on until the last |
---|
513 | alternative. Here is how it is done for fullword logical-or on the |
---|
514 | 68000: |
---|
515 | |
---|
516 | (define_insn "iorsi3" |
---|
517 | [(set (match_operand:SI 0 "general_operand" "=m,d") |
---|
518 | (ior:SI (match_operand:SI 1 "general_operand" "%0,0") |
---|
519 | (match_operand:SI 2 "general_operand" "dKs,dmKs")))] |
---|
520 | ...) |
---|
521 | |
---|
522 | The first alternative has `m' (memory) for operand 0, `0' for |
---|
523 | operand 1 (meaning it must match operand 0), and `dKs' for operand 2. |
---|
524 | The second alternative has `d' (data register) for operand 0, `0' for |
---|
525 | operand 1, and `dmKs' for operand 2. The `=' and `%' in the |
---|
526 | constraints apply to all the alternatives; their meaning is explained |
---|
527 | in the next section (*note Class Preferences::.). |
---|
528 | |
---|
529 | If all the operands fit any one alternative, the instruction is |
---|
530 | valid. Otherwise, for each alternative, the compiler counts how many |
---|
531 | instructions must be added to copy the operands so that that |
---|
532 | alternative applies. The alternative requiring the least copying is |
---|
533 | chosen. If two alternatives need the same amount of copying, the one |
---|
534 | that comes first is chosen. These choices can be altered with the `?' |
---|
535 | and `!' characters: |
---|
536 | |
---|
537 | `?' |
---|
538 | Disparage slightly the alternative that the `?' appears in, as a |
---|
539 | choice when no alternative applies exactly. The compiler regards |
---|
540 | this alternative as one unit more costly for each `?' that appears |
---|
541 | in it. |
---|
542 | |
---|
543 | `!' |
---|
544 | Disparage severely the alternative that the `!' appears in. This |
---|
545 | alternative can still be used if it fits without reloading, but if |
---|
546 | reloading is needed, some other alternative will be used. |
---|
547 | |
---|
548 | When an insn pattern has multiple alternatives in its constraints, |
---|
549 | often the appearance of the assembler code is determined mostly by which |
---|
550 | alternative was matched. When this is so, the C code for writing the |
---|
551 | assembler code can use the variable `which_alternative', which is the |
---|
552 | ordinal number of the alternative that was actually satisfied (0 for |
---|
553 | the first, 1 for the second alternative, etc.). *Note Output |
---|
554 | Statement::. |
---|
555 | |
---|
556 | |
---|
557 | File: gcc.info, Node: Class Preferences, Next: Modifiers, Prev: Multi-Alternative, Up: Constraints |
---|
558 | |
---|
559 | Register Class Preferences |
---|
560 | -------------------------- |
---|
561 | |
---|
562 | The operand constraints have another function: they enable the |
---|
563 | compiler to decide which kind of hardware register a pseudo register is |
---|
564 | best allocated to. The compiler examines the constraints that apply to |
---|
565 | the insns that use the pseudo register, looking for the |
---|
566 | machine-dependent letters such as `d' and `a' that specify classes of |
---|
567 | registers. The pseudo register is put in whichever class gets the most |
---|
568 | "votes". The constraint letters `g' and `r' also vote: they vote in |
---|
569 | favor of a general register. The machine description says which |
---|
570 | registers are considered general. |
---|
571 | |
---|
572 | Of course, on some machines all registers are equivalent, and no |
---|
573 | register classes are defined. Then none of this complexity is relevant. |
---|
574 | |
---|
575 | |
---|
576 | File: gcc.info, Node: Modifiers, Next: Machine Constraints, Prev: Class Preferences, Up: Constraints |
---|
577 | |
---|
578 | Constraint Modifier Characters |
---|
579 | ------------------------------ |
---|
580 | |
---|
581 | Here are constraint modifier characters. |
---|
582 | |
---|
583 | `=' |
---|
584 | Means that this operand is write-only for this instruction: the |
---|
585 | previous value is discarded and replaced by output data. |
---|
586 | |
---|
587 | `+' |
---|
588 | Means that this operand is both read and written by the |
---|
589 | instruction. |
---|
590 | |
---|
591 | When the compiler fixes up the operands to satisfy the constraints, |
---|
592 | it needs to know which operands are inputs to the instruction and |
---|
593 | which are outputs from it. `=' identifies an output; `+' |
---|
594 | identifies an operand that is both input and output; all other |
---|
595 | operands are assumed to be input only. |
---|
596 | |
---|
597 | `&' |
---|
598 | Means (in a particular alternative) that this operand is an |
---|
599 | "earlyclobber" operand, which is modified before the instruction is |
---|
600 | finished using the input operands. Therefore, this operand may |
---|
601 | not lie in a register that is used as an input operand or as part |
---|
602 | of any memory address. |
---|
603 | |
---|
604 | `&' applies only to the alternative in which it is written. In |
---|
605 | constraints with multiple alternatives, sometimes one alternative |
---|
606 | requires `&' while others do not. See, for example, the `movdf' |
---|
607 | insn of the 68000. |
---|
608 | |
---|
609 | An input operand can be tied to an earlyclobber operand if its only |
---|
610 | use as an input occurs before the early result is written. Adding |
---|
611 | alternatives of this form often allows GCC to produce better code |
---|
612 | when only some of the inputs can be affected by the earlyclobber. |
---|
613 | See, for example, the `mulsi3' insn of the ARM. |
---|
614 | |
---|
615 | `&' does not obviate the need to write `='. |
---|
616 | |
---|
617 | `%' |
---|
618 | Declares the instruction to be commutative for this operand and the |
---|
619 | following operand. This means that the compiler may interchange |
---|
620 | the two operands if that is the cheapest way to make all operands |
---|
621 | fit the constraints. This is often used in patterns for addition |
---|
622 | instructions that really have only two operands: the result must |
---|
623 | go in one of the arguments. Here for example, is how the 68000 |
---|
624 | halfword-add instruction is defined: |
---|
625 | |
---|
626 | (define_insn "addhi3" |
---|
627 | [(set (match_operand:HI 0 "general_operand" "=m,r") |
---|
628 | (plus:HI (match_operand:HI 1 "general_operand" "%0,0") |
---|
629 | (match_operand:HI 2 "general_operand" "di,g")))] |
---|
630 | ...) |
---|
631 | |
---|
632 | `#' |
---|
633 | Says that all following characters, up to the next comma, are to be |
---|
634 | ignored as a constraint. They are significant only for choosing |
---|
635 | register preferences. |
---|
636 | |
---|
637 | `*' |
---|
638 | Says that the following character should be ignored when choosing |
---|
639 | register preferences. `*' has no effect on the meaning of the |
---|
640 | constraint as a constraint, and no effect on reloading. |
---|
641 | |
---|
642 | Here is an example: the 68000 has an instruction to sign-extend a |
---|
643 | halfword in a data register, and can also sign-extend a value by |
---|
644 | copying it into an address register. While either kind of |
---|
645 | register is acceptable, the constraints on an address-register |
---|
646 | destination are less strict, so it is best if register allocation |
---|
647 | makes an address register its goal. Therefore, `*' is used so |
---|
648 | that the `d' constraint letter (for data register) is ignored when |
---|
649 | computing register preferences. |
---|
650 | |
---|
651 | (define_insn "extendhisi2" |
---|
652 | [(set (match_operand:SI 0 "general_operand" "=*d,a") |
---|
653 | (sign_extend:SI |
---|
654 | (match_operand:HI 1 "general_operand" "0,g")))] |
---|
655 | ...) |
---|
656 | |
---|
657 | |
---|
658 | File: gcc.info, Node: Machine Constraints, Next: No Constraints, Prev: Modifiers, Up: Constraints |
---|
659 | |
---|
660 | Constraints for Particular Machines |
---|
661 | ----------------------------------- |
---|
662 | |
---|
663 | Whenever possible, you should use the general-purpose constraint |
---|
664 | letters in `asm' arguments, since they will convey meaning more readily |
---|
665 | to people reading your code. Failing that, use the constraint letters |
---|
666 | that usually have very similar meanings across architectures. The most |
---|
667 | commonly used constraints are `m' and `r' (for memory and |
---|
668 | general-purpose registers respectively; *note Simple Constraints::.), |
---|
669 | and `I', usually the letter indicating the most common |
---|
670 | immediate-constant format. |
---|
671 | |
---|
672 | For each machine architecture, the `config/MACHINE.h' file defines |
---|
673 | additional constraints. These constraints are used by the compiler |
---|
674 | itself for instruction generation, as well as for `asm' statements; |
---|
675 | therefore, some of the constraints are not particularly interesting for |
---|
676 | `asm'. The constraints are defined through these macros: |
---|
677 | |
---|
678 | `REG_CLASS_FROM_LETTER' |
---|
679 | Register class constraints (usually lower case). |
---|
680 | |
---|
681 | `CONST_OK_FOR_LETTER_P' |
---|
682 | Immediate constant constraints, for non-floating point constants of |
---|
683 | word size or smaller precision (usually upper case). |
---|
684 | |
---|
685 | `CONST_DOUBLE_OK_FOR_LETTER_P' |
---|
686 | Immediate constant constraints, for all floating point constants |
---|
687 | and for constants of greater than word size precision (usually |
---|
688 | upper case). |
---|
689 | |
---|
690 | `EXTRA_CONSTRAINT' |
---|
691 | Special cases of registers or memory. This macro is not required, |
---|
692 | and is only defined for some machines. |
---|
693 | |
---|
694 | Inspecting these macro definitions in the compiler source for your |
---|
695 | machine is the best way to be certain you have the right constraints. |
---|
696 | However, here is a summary of the machine-dependent constraints |
---|
697 | available on some particular machines. |
---|
698 | |
---|
699 | *ARM family--`arm.h'* |
---|
700 | `f' |
---|
701 | Floating-point register |
---|
702 | |
---|
703 | `F' |
---|
704 | One of the floating-point constants 0.0, 0.5, 1.0, 2.0, 3.0, |
---|
705 | 4.0, 5.0 or 10.0 |
---|
706 | |
---|
707 | `G' |
---|
708 | Floating-point constant that would satisfy the constraint `F' |
---|
709 | if it were negated |
---|
710 | |
---|
711 | `I' |
---|
712 | Integer that is valid as an immediate operand in a data |
---|
713 | processing instruction. That is, an integer in the range 0 |
---|
714 | to 255 rotated by a multiple of 2 |
---|
715 | |
---|
716 | `J' |
---|
717 | Integer in the range -4095 to 4095 |
---|
718 | |
---|
719 | `K' |
---|
720 | Integer that satisfies constraint `I' when inverted (ones |
---|
721 | complement) |
---|
722 | |
---|
723 | `L' |
---|
724 | Integer that satisfies constraint `I' when negated (twos |
---|
725 | complement) |
---|
726 | |
---|
727 | `M' |
---|
728 | Integer in the range 0 to 32 |
---|
729 | |
---|
730 | `Q' |
---|
731 | A memory reference where the exact address is in a single |
---|
732 | register (``m'' is preferable for `asm' statements) |
---|
733 | |
---|
734 | `R' |
---|
735 | An item in the constant pool |
---|
736 | |
---|
737 | `S' |
---|
738 | A symbol in the text segment of the current file |
---|
739 | |
---|
740 | *AMD 29000 family--`a29k.h'* |
---|
741 | `l' |
---|
742 | Local register 0 |
---|
743 | |
---|
744 | `b' |
---|
745 | Byte Pointer (`BP') register |
---|
746 | |
---|
747 | `q' |
---|
748 | `Q' register |
---|
749 | |
---|
750 | `h' |
---|
751 | Special purpose register |
---|
752 | |
---|
753 | `A' |
---|
754 | First accumulator register |
---|
755 | |
---|
756 | `a' |
---|
757 | Other accumulator register |
---|
758 | |
---|
759 | `f' |
---|
760 | Floating point register |
---|
761 | |
---|
762 | `I' |
---|
763 | Constant greater than 0, less than 0x100 |
---|
764 | |
---|
765 | `J' |
---|
766 | Constant greater than 0, less than 0x10000 |
---|
767 | |
---|
768 | `K' |
---|
769 | Constant whose high 24 bits are on (1) |
---|
770 | |
---|
771 | `L' |
---|
772 | 16 bit constant whose high 8 bits are on (1) |
---|
773 | |
---|
774 | `M' |
---|
775 | 32 bit constant whose high 16 bits are on (1) |
---|
776 | |
---|
777 | `N' |
---|
778 | 32 bit negative constant that fits in 8 bits |
---|
779 | |
---|
780 | `O' |
---|
781 | The constant 0x80000000 or, on the 29050, any 32 bit constant |
---|
782 | whose low 16 bits are 0. |
---|
783 | |
---|
784 | `P' |
---|
785 | 16 bit negative constant that fits in 8 bits |
---|
786 | |
---|
787 | `G' |
---|
788 | `H' |
---|
789 | A floating point constant (in `asm' statements, use the |
---|
790 | machine independent `E' or `F' instead) |
---|
791 | |
---|
792 | *IBM RS6000--`rs6000.h'* |
---|
793 | `b' |
---|
794 | Address base register |
---|
795 | |
---|
796 | `f' |
---|
797 | Floating point register |
---|
798 | |
---|
799 | `h' |
---|
800 | `MQ', `CTR', or `LINK' register |
---|
801 | |
---|
802 | `q' |
---|
803 | `MQ' register |
---|
804 | |
---|
805 | `c' |
---|
806 | `CTR' register |
---|
807 | |
---|
808 | `l' |
---|
809 | `LINK' register |
---|
810 | |
---|
811 | `x' |
---|
812 | `CR' register (condition register) number 0 |
---|
813 | |
---|
814 | `y' |
---|
815 | `CR' register (condition register) |
---|
816 | |
---|
817 | `I' |
---|
818 | Signed 16 bit constant |
---|
819 | |
---|
820 | `J' |
---|
821 | Constant whose low 16 bits are 0 |
---|
822 | |
---|
823 | `K' |
---|
824 | Constant whose high 16 bits are 0 |
---|
825 | |
---|
826 | `L' |
---|
827 | Constant suitable as a mask operand |
---|
828 | |
---|
829 | `M' |
---|
830 | Constant larger than 31 |
---|
831 | |
---|
832 | `N' |
---|
833 | Exact power of 2 |
---|
834 | |
---|
835 | `O' |
---|
836 | Zero |
---|
837 | |
---|
838 | `P' |
---|
839 | Constant whose negation is a signed 16 bit constant |
---|
840 | |
---|
841 | `G' |
---|
842 | Floating point constant that can be loaded into a register |
---|
843 | with one instruction per word |
---|
844 | |
---|
845 | `Q' |
---|
846 | Memory operand that is an offset from a register (`m' is |
---|
847 | preferable for `asm' statements) |
---|
848 | |
---|
849 | `R' |
---|
850 | AIX TOC entry |
---|
851 | |
---|
852 | `S' |
---|
853 | Windows NT SYMBOL_REF |
---|
854 | |
---|
855 | `T' |
---|
856 | Windows NT LABEL_REF |
---|
857 | |
---|
858 | `U' |
---|
859 | System V Release 4 small data area reference |
---|
860 | |
---|
861 | *Intel 386--`i386.h'* |
---|
862 | `q' |
---|
863 | `a', `b', `c', or `d' register |
---|
864 | |
---|
865 | `A' |
---|
866 | `a', or `d' register (for 64-bit ints) |
---|
867 | |
---|
868 | `f' |
---|
869 | Floating point register |
---|
870 | |
---|
871 | `t' |
---|
872 | First (top of stack) floating point register |
---|
873 | |
---|
874 | `u' |
---|
875 | Second floating point register |
---|
876 | |
---|
877 | `a' |
---|
878 | `a' register |
---|
879 | |
---|
880 | `b' |
---|
881 | `b' register |
---|
882 | |
---|
883 | `c' |
---|
884 | `c' register |
---|
885 | |
---|
886 | `d' |
---|
887 | `d' register |
---|
888 | |
---|
889 | `D' |
---|
890 | `di' register |
---|
891 | |
---|
892 | `S' |
---|
893 | `si' register |
---|
894 | |
---|
895 | `I' |
---|
896 | Constant in range 0 to 31 (for 32 bit shifts) |
---|
897 | |
---|
898 | `J' |
---|
899 | Constant in range 0 to 63 (for 64 bit shifts) |
---|
900 | |
---|
901 | `K' |
---|
902 | `0xff' |
---|
903 | |
---|
904 | `L' |
---|
905 | `0xffff' |
---|
906 | |
---|
907 | `M' |
---|
908 | 0, 1, 2, or 3 (shifts for `lea' instruction) |
---|
909 | |
---|
910 | `N' |
---|
911 | Constant in range 0 to 255 (for `out' instruction) |
---|
912 | |
---|
913 | `G' |
---|
914 | Standard 80387 floating point constant |
---|
915 | |
---|
916 | *Intel 960--`i960.h'* |
---|
917 | `f' |
---|
918 | Floating point register (`fp0' to `fp3') |
---|
919 | |
---|
920 | `l' |
---|
921 | Local register (`r0' to `r15') |
---|
922 | |
---|
923 | `b' |
---|
924 | Global register (`g0' to `g15') |
---|
925 | |
---|
926 | `d' |
---|
927 | Any local or global register |
---|
928 | |
---|
929 | `I' |
---|
930 | Integers from 0 to 31 |
---|
931 | |
---|
932 | `J' |
---|
933 | 0 |
---|
934 | |
---|
935 | `K' |
---|
936 | Integers from -31 to 0 |
---|
937 | |
---|
938 | `G' |
---|
939 | Floating point 0 |
---|
940 | |
---|
941 | `H' |
---|
942 | Floating point 1 |
---|
943 | |
---|
944 | *MIPS--`mips.h'* |
---|
945 | `d' |
---|
946 | General-purpose integer register |
---|
947 | |
---|
948 | `f' |
---|
949 | Floating-point register (if available) |
---|
950 | |
---|
951 | `h' |
---|
952 | `Hi' register |
---|
953 | |
---|
954 | `l' |
---|
955 | `Lo' register |
---|
956 | |
---|
957 | `x' |
---|
958 | `Hi' or `Lo' register |
---|
959 | |
---|
960 | `y' |
---|
961 | General-purpose integer register |
---|
962 | |
---|
963 | `z' |
---|
964 | Floating-point status register |
---|
965 | |
---|
966 | `I' |
---|
967 | Signed 16 bit constant (for arithmetic instructions) |
---|
968 | |
---|
969 | `J' |
---|
970 | Zero |
---|
971 | |
---|
972 | `K' |
---|
973 | Zero-extended 16-bit constant (for logic instructions) |
---|
974 | |
---|
975 | `L' |
---|
976 | Constant with low 16 bits zero (can be loaded with `lui') |
---|
977 | |
---|
978 | `M' |
---|
979 | 32 bit constant which requires two instructions to load (a |
---|
980 | constant which is not `I', `K', or `L') |
---|
981 | |
---|
982 | `N' |
---|
983 | Negative 16 bit constant |
---|
984 | |
---|
985 | `O' |
---|
986 | Exact power of two |
---|
987 | |
---|
988 | `P' |
---|
989 | Positive 16 bit constant |
---|
990 | |
---|
991 | `G' |
---|
992 | Floating point zero |
---|
993 | |
---|
994 | `Q' |
---|
995 | Memory reference that can be loaded with more than one |
---|
996 | instruction (`m' is preferable for `asm' statements) |
---|
997 | |
---|
998 | `R' |
---|
999 | Memory reference that can be loaded with one instruction (`m' |
---|
1000 | is preferable for `asm' statements) |
---|
1001 | |
---|
1002 | `S' |
---|
1003 | Memory reference in external OSF/rose PIC format (`m' is |
---|
1004 | preferable for `asm' statements) |
---|
1005 | |
---|
1006 | *Motorola 680x0--`m68k.h'* |
---|
1007 | `a' |
---|
1008 | Address register |
---|
1009 | |
---|
1010 | `d' |
---|
1011 | Data register |
---|
1012 | |
---|
1013 | `f' |
---|
1014 | 68881 floating-point register, if available |
---|
1015 | |
---|
1016 | `x' |
---|
1017 | Sun FPA (floating-point) register, if available |
---|
1018 | |
---|
1019 | `y' |
---|
1020 | First 16 Sun FPA registers, if available |
---|
1021 | |
---|
1022 | `I' |
---|
1023 | Integer in the range 1 to 8 |
---|
1024 | |
---|
1025 | `J' |
---|
1026 | 16 bit signed number |
---|
1027 | |
---|
1028 | `K' |
---|
1029 | Signed number whose magnitude is greater than 0x80 |
---|
1030 | |
---|
1031 | `L' |
---|
1032 | Integer in the range -8 to -1 |
---|
1033 | |
---|
1034 | `M' |
---|
1035 | Signed number whose magnitude is greater than 0x100 |
---|
1036 | |
---|
1037 | `G' |
---|
1038 | Floating point constant that is not a 68881 constant |
---|
1039 | |
---|
1040 | `H' |
---|
1041 | Floating point constant that can be used by Sun FPA |
---|
1042 | |
---|
1043 | *SPARC--`sparc.h'* |
---|
1044 | `f' |
---|
1045 | Floating-point register that can hold 32 or 64 bit values. |
---|
1046 | |
---|
1047 | `e' |
---|
1048 | Floating-point register that can hold 64 or 128 bit values. |
---|
1049 | |
---|
1050 | `I' |
---|
1051 | Signed 13 bit constant |
---|
1052 | |
---|
1053 | `J' |
---|
1054 | Zero |
---|
1055 | |
---|
1056 | `K' |
---|
1057 | 32 bit constant with the low 12 bits clear (a constant that |
---|
1058 | can be loaded with the `sethi' instruction) |
---|
1059 | |
---|
1060 | `G' |
---|
1061 | Floating-point zero |
---|
1062 | |
---|
1063 | `H' |
---|
1064 | Signed 13 bit constant, sign-extended to 32 or 64 bits |
---|
1065 | |
---|
1066 | `Q' |
---|
1067 | Memory reference that can be loaded with one instruction |
---|
1068 | (`m' is more appropriate for `asm' statements) |
---|
1069 | |
---|
1070 | `S' |
---|
1071 | Constant, or memory address |
---|
1072 | |
---|
1073 | `T' |
---|
1074 | Memory address aligned to an 8-byte boundary |
---|
1075 | |
---|
1076 | `U' |
---|
1077 | Even register |
---|
1078 | |
---|
1079 | |
---|
1080 | File: gcc.info, Node: No Constraints, Prev: Machine Constraints, Up: Constraints |
---|
1081 | |
---|
1082 | Not Using Constraints |
---|
1083 | --------------------- |
---|
1084 | |
---|
1085 | Some machines are so clean that operand constraints are not |
---|
1086 | required. For example, on the Vax, an operand valid in one context is |
---|
1087 | valid in any other context. On such a machine, every operand |
---|
1088 | constraint would be `g', excepting only operands of "load address" |
---|
1089 | instructions which are written as if they referred to a memory |
---|
1090 | location's contents but actual refer to its address. They would have |
---|
1091 | constraint `p'. |
---|
1092 | |
---|
1093 | For such machines, instead of writing `g' and `p' for all the |
---|
1094 | constraints, you can choose to write a description with empty |
---|
1095 | constraints. Then you write `""' for the constraint in every |
---|
1096 | `match_operand'. Address operands are identified by writing an |
---|
1097 | `address' expression around the `match_operand', not by their |
---|
1098 | constraints. |
---|
1099 | |
---|
1100 | When the machine description has just empty constraints, certain |
---|
1101 | parts of compilation are skipped, making the compiler faster. However, |
---|
1102 | few machines actually do not need constraints; all machine descriptions |
---|
1103 | now in existence use constraints. |
---|
1104 | |
---|