|
|
1.1 root 1: Info file internals, produced by texinfo-format-buffer -*-Text-*-
2: from file internals.texinfo
3:
4:
5: This file documents the internals of the GNU compiler.
6:
7: Copyright (C) 1987 Richard M. Stallman.
8:
9: Permission is granted to make and distribute verbatim copies of
10: this manual provided the copyright notice and this permission notice
11: are preserved on all copies.
12:
13: Permission is granted to copy and distribute modified versions of this
14: manual under the conditions for verbatim copying, provided also that the
15: section entitled "GNU CC General Public License" is included exactly as
16: in the original, and provided that the entire resulting derived work is
17: distributed under the terms of a permission notice identical to this one.
18:
19: Permission is granted to copy and distribute translations of this manual
20: into another language, under the above conditions for modified versions,
21: except that the section entitled "GNU CC General Public License" may be
22: included in a translation approved by the author instead of in the original
23: English.
24:
25:
26:
27:
28:
29: File: internals Node: Dependent Patterns, Prev: Standard Names, Up: Machine Desc
30:
31: Patterns Require Other Patterns
32: ===============================
33:
34: Every machine description must have a named pattern for each of the
35: conditional branch names `bCOND'. The recognition template
36: must always have the form
37:
38: (set (pc)
39: (if_then_else (COND (cc0) (const_int 0))
40: (label_ref (match_operand 0 "" ""))
41: (pc)))
42:
43: In addition, every machine description must have an anonymous pattern
44: for each of the possible reverse-conditional branches. These patterns
45: look like
46:
47: (set (pc)
48: (if_then_else (COND (cc0) (const_int 0))
49: (pc)
50: (label_ref (match_operand 0 "" ""))))
51:
52: They are necessary because jump optimization can turn direct-conditional
53: branches into reverse-conditional branches.
54:
55: The compiler does more with RTL than just create it from patterns
56: and recognize the patterns: it can perform arithmetic expression codes
57: when constant values for their operands can be determined. As a result,
58: sometimes having one pattern can require other patterns. For example, the
59: Vax has no `and' instruction, but it has `and not' instructions. Here
60: is the definition of one of them:
61:
62: (define_insn "andcbsi2"
63: [(set (match_operand:SI 0 "general_operand" "")
64: (and:SI (match_dup 0)
65: (not:SI (match_operand:SI
66: 1 "general_operand" ""))))]
67: ""
68: "bicl2 %1,%0")
69:
70: If operand 1 is an explicit integer constant, an instruction constructed
71: using that pattern can end up looking like
72:
73: (set (reg:SI 41)
74: (and:SI (reg:SI 41)
75: (const_int 0xffff7fff)))
76:
77: (where the integer constant is the one's complement of what
78: appeared in the original instruction).
79:
80: To avoid a fatal error, the compiler must have a pattern that recognizes
81: such an instruction. Here is what is used:
82:
83: (define_insn ""
84: [(set (match_operand:SI 0 "general_operand" "")
85: (and:SI (match_dup 0)
86: (match_operand:SI 1 "general_operand" "")))]
87: "GET_CODE (operands[1]) == CONST_INT"
88: "*
89: { operands[1]
90: = gen_rtx (CONST_INT, VOIDmode, ~INTVAL (operands[1]));
91: return \"bicl2 %1,%0\";
92: }")
93:
94: Whereas a pattern to match a general `and' instruction is impossible to
95: support on the Vax, this pattern is possible because it matches only a
96: constant second argument: a special case that can be output as an `and not'
97: instruction.
98:
99:
100: File: internals Node: Machine Macros, Prev: Machine Desc, Up: Top
101:
102: Machine Description Macros
103: **************************
104:
105: The other half of the machine description is a C header file conventionally
106: given the name `tm-MACHINE.h'. The file `tm.h' should be a
107: link to it. The header file `config.h' includes `tm.h' and most
108: compiler source files include `config.h'.
109:
110: * Menu:
111:
112: * Run-time Target:: Defining -m switches like -m68000 and -m68020.
113: * Storage Layout:: Defining sizes and alignments of data types.
114: * Registers:: Naming and describing the hardware registers.
115: * Register Classes:: Defining the classes of hardware registers.
116: * Stack Layout:: Defining which way the stack grows and by how much.
117: * Addressing Modes:: Defining addressing modes valid for memory operands.
118: * Condition Code:: Defining how insns update the condition code.
119: * Assembler Format:: Defining how to write insns and pseudo-ops to output.
120: * Misc:: Everything else.
121:
122:
123: File: internals Node: Run-time Target, Prev: Machine Macros, Up: Machine Macros, Next: Storage Layout
124:
125: Run-time Target Specification
126: =============================
127:
128: `CPP_PREDEFINES'
129: Define this to be a string constant containing `-D' switches
130: to define the predefined macros that identify this machine and system.
131:
132: For example, on the Sun, one can use the value
133:
134: "-Dmc68000 -Dsun"
135:
136: `extern int target_flags;'
137: This declaration should be present.
138:
139: `TARGET_...'
140: This series of macros is to allow compiler command arguments to
141: enable or disable the use of optional features of the target machine.
142: For example, one machine description serves both the 68000 and
143: the 68020; a command argument tells the compiler whether it should
144: use 68020-only instructions or not. This command argument works
145: by means of a macro `TARGET_68020' that tests a bit in
146: `target_flags'.
147:
148: Define a macro `TARGET_FEATURENAME' for each such option.
149: Its definition should test a bit in `target_flags'; for example:
150:
151: #define TARGET_68020 (target_flags & 1)
152:
153: One place where these macros are used is in the condition-expressions
154: of instruction patterns. Note how `TARGET_68020' appears
155: frequently in the 68000 machine description file, `m68000.md'.
156: Another place they are used is in the definitions of the other
157: macros in the `tm-MACHINE.h' file.
158:
159: `TARGET_SWITCHES'
160: This macro defines names of command switches to set and clear
161: bits in `target_flags'. Its definition is an initializer
162: with a subgrouping for each command switches.
163:
164: Each subgrouping contains a string constant, that defines the switch
165: name, and a number, which contains the bits to set in
166: `target_flags'. A negative number says to clear bits instead;
167: the negative of the number is which bits to clear. The actual switch
168: name is made by appending `-m' to the specified name.
169:
170: One of the subgroupings should have a null string. The number in
171: this grouping is the default value for `target_flags'. Any
172: target switches act starting with that value.
173:
174: Here is an example which defines `-m68000' and `-m68020'
175: with opposite meanings, and picks the latter as the default:
176:
177: #define TARGET_SWITCHES \
178: { { "68020", 1}, \
179: { "68000", -1}, \
180: { "", 1}}
181:
182:
183: File: internals Node: Storage Layout, Prev: Run-time Target, Up: Machine Macros, Next: Registers
184:
185: Storage Layout
186: ==============
187:
188: `BITS_BIG_ENDIAN'
189: Define this macro if the most significant bit in a byte has the lowest
190: number. This means that bit-field instructions count from the most
191: significant bit. If the machine has no bit-field instructions, this
192: macro is irrelevant.
193:
194: `BYTES_BIG_ENDIAN'
195: Define this macro if the most significant byte in a word has the
196: lowest number.
197:
198: `WORDS_BIG_ENDIAN'
199: Define this macro if, in a multiword object, the most signficant
200: word has the lowest number.
201:
202: `BITS_PER_UNIT'
203: Number of bits in an addressable storage unit (byte); normally 8.
204:
205: `BITS_PER_WORD'
206: Number of bits in a word; normally 32.
207:
208: `UNITS_PER_WORD'
209: Number of storage units in a word; normally 4.
210:
211: `POINTER_SIZE'
212: Width of a pointer, in bits.
213:
214: `PARM_BOUNDARY'
215: Alignment required for pointers, in bits.
216:
217: `FUNCTION_BOUNDARY'
218: Alignment required for a function entry point, in bits.
219:
220: `BIGGEST_ALIGNMENT'
221: Biggest alignment that anything can require on this machine, in bits.
222:
223: `STRICT_ALIGNMENT'
224: Define this if instructions will fail to work if given data not
225: on the nominal alignment. If instructions will merely go slower
226: in that case, do not define this macro.
227:
228:
229: File: internals Node: Registers, Prev: Storage Layout, Up: Machine Macros, Next: Register Classes
230:
231: Register Usage
232: ==============
233:
234: `FIRST_PSEUDO_REGISTER'
235: Number of hardware registers known to the compiler. They receive
236: numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
237: pseudo register's number really is assigned the number7
238: `FIRST_PSEUDO_REGISTER'.
239:
240: `FIXED_REGISTERS'
241: An initializer that says which registers are used for fixed purposes
242: all throughout the compiled code and are therefore not available for
243: general allocation. These would inclue the stack pointer, the frame
244: pointer, the program counter on machines where that is considered one
245: of the addressable registers, and any other numbered register with a
246: standard use.
247:
248: This information is expressed as a sequence of numbers, separated by
249: commas and surrounded by braces. The Nth number is 1 if
250: register N is fixed, 0 otherwise
251:
252: `CALL_USED_REGISTERS'
253: Like `FIXED_REGISTERS' but has 1 for each register that is
254: clobbered (in general) by function calls as well as for fixed
255: registers. This macro therefore identifies the registers that are not
256: available for general allocation of values that must live across
257: function calls.
258:
259: If a registers has 0 in `CALL_USED_REGISTERS', the compiler
260: automatically saves it on function entry and restores it on function
261: exit, if the register is used within the function.
262:
263: `HARD_REGNO_REGS (REGNO, MODE)'
264: A C expression for the number of consecutive hard registers, starting
265: at register number REGNO, required to hold a value of mode
266: MODE.
267:
268: On a machine where all registers are exactly one word, a suitable
269: definition of this macro is
270:
271: #define HARD_REGNO_NREGS(REGNO, MODE) \
272: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
273: / UNITS_PER_WORD))
274:
275: `HARD_REGNO_MODE_OK (REGNO, MODE)'
276: A C expression that is nonzero if it is permissible to store a value
277: of mode MODE in hard register number REGNO (or in several
278: registers starting with that one). For a machine where all registers
279: are equivalent, a suitable definition is
280:
281: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
282:
283: It is not necessary for this macro to check for fixed register numbers
284: because the allocation mechanism considers them to be always occupied.
285:
286: `MODES_TIEABLE_P (MODE1, MODE2)'
287: A C expression that is nonzero if it is desirable to choose register
288: allocation so as to avoid move instructions between a value of mode
289: MODE1 and a value of mode MODE2.
290:
291: If `HARD_REGNO_MODE_OK (R, MODE1)' and
292: `HARD_REGNO_MODE_OK (R, MODE2)' are ever different
293: for any R, then `MODES_TIEABLE_P (MODE1,
294: MODE2)' must be zero.
295:
296: `PC_REGNUM'
297: If the program counter has a register number, define this as that
298: register number. Otherwise, do not define it.
299:
300: `STACK_POINTER_REGNUM'
301: The register number of the stack pointer register, which must also be
302: a fixed register according to `FIXED_REGISTERS'. On many
303: machines, the hardware determines which register this is.
304:
305: `FRAME_POINTER_REGNUM'
306: The register number of the frame pointer register, which is used to
307: access automatic variables in the stack frame. It must also described
308: in `FIXED_REGISTERS' as a fixed register. On some machines, the
309: hardware determines which register this is. On other machines, you
310: can choose any register you wish for this purpose.
311:
312: `ARG_POINTER_REGNUM'
313: The register number of the arg pointer register, which is used to
314: access the function's argument list. On some machines, this is the
315: same as the frame pointer register. On some machines, the hardware
316: determines which register this is. On other machines, you can choose
317: any register you wish for this purpose. It must in any case be a
318: fixed register according to `FIXED_REGISTERS'.
319:
320: `STATIC_CHAIN_REGNUM'
321: The register number used for passing a function's static chain
322: pointer. This is needed for languages such as Pascal and Algol where
323: functions defined within other functions can access the local
324: variables of the outer functions; it is not currently used because C
325: does not provide this feature.
326:
327: The static chain register need not be a fixed register.
328:
329: `FUNCTION_VALUE_REGNUM'
330: The register number used for returning values from a function. This
331: must be one of the call-used registers (since function calls alter
332: it!) but should not be a fixed register. When the value being
333: returned has a multi-word machine mode, multiple consecutive registers
334: starting with the specified one are used.
335:
336: `STRUCT_VALUE_REGNUM'
337: When a function's value's mode is `BLKmode', the value is not returned
338: in the register `FUNCTION_VALUE_REGNUM'. Instead, the caller passes
339: the address of a block of memory in which the value should be stored.
340: `STRUCT_VALUE_REGNUM' is the register in which this address is passed.
341:
342:
343: File: internals Node: Register Classes, Prev: Registers, Up: Machine Macros, Next: Stack Layout
344:
345: Register Classes
346: ================
347:
348: On many machines, the numbered registers are not all equivalent.
349: For example, certain registers may not be allowed for indexed addressing;
350: certain registers may not be allowed in some instructions. These machine
351: restrictions are described to the compiler using "register classes".
352:
353: You define a number of register classes, giving each one a name and saying
354: which of the registers belong to it. Then you can specify register classes
355: that are allowed as operands to particular instruction patterns.
356:
357: In general, each register will belong to several classes. In fact, one
358: class must be named `ALL_REGS' and contain all the registers. Another
359: class must be named `NO_REGS' and contain no registers. Often the
360: union of two classes will be another class; however, this is not required.
361:
362: One of the classes must be named `GENERAL_REGS'. There is nothing
363: terribly special about the name, but the operand constraint letters
364: `r' and `g' specify this class. If `GENERAL_REGS' is
365: the same as `ALL_REGS', just define it as a macro which expands
366: to `ALL_REGS'.
367:
368: The way classes other than `GENERAL_REGS' are specified in operand
369: constraints is through machine-dependent operand constraint letters.
370: You can define such letters to correspond to various classes, then use
371: them in operand constraints.
372:
373: You must also specify certain redundant information about the register
374: classes: for each class, which classes contain it and which ones are
375: contained in it; for each pair of classes, the largest class contained
376: in their union.
377:
378: `enum reg_class'
379: An enumeral type that must be defined with all the register class names
380: as enumeral values. `NO_REGS' must be first. `ALL_REGS'
381: must be the last register class, followed by one more enumeral value,
382: `LIM_REG_CLASSES', which is not a register class but rather
383: tells how many classes there are.
384:
385: Each register class has a number, which is the value of casting
386: the class name to type `int'. The number serves as an index
387: in many of the tables described below.
388:
389: `REG_CLASS_NAMES'
390: An initializer containing the names of the register classes as C string
391: constants. These names are used in writing some of the debugging dumps.
392:
393: `REG_CLASS_CONTENTS'
394: An initializer containing the contents of the register classes, as integers
395: which are bit masks. The Nth integer specifies the contents of class
396: N. The way the integer MASK is interpreted is that
397: register R is in the class if `MASK & (1 << R)' is 1.
398:
399: When the machine has more than 32 registers, an integer does not suffice.
400: Then the integers are replaced by sub-initializers, braced groupings containing
401: several integers. Each sub-initializer must be suitable as an initializer
402: for the type `HARD_REG_SET' which is defined in `hard-reg-set.h'.
403:
404: `REGNO_REG_CLASS (REGNO)'
405: A C expression whose value is a register class containing hard register
406: REGNO. In general there is more that one such class; choose a class
407: which is "minimal", meaning that no smaller class also contains the
408: register.
409:
410: `REG_CLASS_SUPERCLASSES'
411: A two-level initializer that says, for each class, which classes contain
412: it. The Nth element of the initializer is a sub-initializer for
413: class N; it contains the names of the othe classes that contain class
414: N (but not the name of class N itself), followed by
415: `LIM_REG_CLASSES' to mark the end of the element.
416:
417: `REG_CLASS_SUBCLASSES'
418: Similar to `REG_CLASS_SUPERCLASSES', except that element N lists
419: the classes *contained in* class N, followed once again by
420: `LIM_REG_CLASSES' to mark the end of the element.
421:
422: `REG_CLASS_SUBUNION'
423: An two-level initializer for a two-dimensional array. The element
424: (M, N) of this array must be a class that is "close to"
425: being the union of classes M and N. If there is a class
426: that is exactly that union, use it; otherwise, choose some smaller
427: class, preferably as large as possible but certainly not containing
428: any register that is neither in class M nor in class N.
429:
430: `INDEX_REG_CLASS'
431: A macro whose definition is the name of the class to which a valid index
432: register must belong.
433:
434: `REG_CLASS_FROM_LETTER (CHAR)'
435: A C expression which defines the machine-dependent operand constraint
436: letters for register classes. If CHAR is such a letter, the value
437: should be the register class corresponding to it. Otherwise, the value
438: should be `NO_REGS'.
439:
440: `REGNO_OK_FOR_CLASS_P (REGNO, CLASS)'
441: A C expression which is nonzero if register number REGNO is a hard
442: register belonging to class CLASS. The expression is always zero if
443: REGNO is a pseudo register.
444:
445: `REG_OK_FOR_CLASS_P (REG, CLASS)'
446: A C expression which is nonzero if REG (an rtx assumed to have
447: code `reg') belongs to class CLASS.
448:
449: What about pseudo registers? There are two alternatives, and the machine
450: description header file must be able to do either one on command. If the
451: macro `REG_OK_STRICT' is defined, this macro should be defined to
452: reject all pseudo registers (return 0 for them). Otherwise, this macro
453: should be defined to accept all pseudo registers (return 1 for them).
454:
455: Some source files of the compiler define `REG_OK_STRICT' before
456: including the machine description header file, while others do not,
457: according to the needs of that part of the compiler.
458:
459: `PREFERRED_RELOAD_CLASS (X, CLASS)'
460: A C expression that places additional restrictions on the register class
461: to use when it is necessary to copy value X into a register in class
462: CLASS. The value is a register class; perhaps CLASS, or perhaps
463: another, smaller class. CLASS is always safe as a value. In fact,
464: the definition
465:
466: #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
467:
468: is always safe. However, sometimes returning a more restrictive class
469: makes better code. For example, on the 68000, when X is an
470: integer constant that is in range for a `moveq' instruction,
471: the value of this macro is always `DATA_REGS' as long as
472: CLASS includes the data registers. Requiring a data register
473: guarantees that a `moveq' will be used.
474:
475: Two other special macros
476:
477: `CONST_OK_FOR_LETTER_P (VALUE, C)'
478: A C expression that defines the machine-dependent operand constraint letters
479: that specify particular ranges of integer values. If C is one
480: of those letters, the expression should check that VALUE, an integer,
481: is in the appropriate range and return 1 if so, 0 otherwise. If C is
482: not one of those letters, the value should be 0 regardless of VALUE.
483:
484: `CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)'
485: A C expression that defines the machine-dependent operand constraint
486: letters that specify particular ranges of floating values. If C is
487: one of those letters, the expression should check that VALUE, an rtx
488: of code `const_double', is in the appropriate range and return 1 if
489: so, 0 otherwise. If C is not one of those letters, the value should
490: be 0 regardless of VALUE.
491:
492:
493: File: internals Node: Stack Layout, Prev: Register Classes, Up: Machine Macros, Next: Addressing Modes
494:
495: Describing Stack Layout
496: =======================
497:
498: `STACK_GROWS_DOWNWARD'
499: Define this macro if pushing a word onto the stack moves the stack
500: pointer to a smaller address. The definition is irrelevant because the
501: compiler checks this macro with `#ifdef'.
502:
503: `FRAME_GROWS_DOWNWARD'
504: Define this macro if the addresses of local variable slots are at negative
505: offsets from the frame pointer.
506:
507: `STARTING_FRAME_OFFSET'
508: Offset from the frame pointer to the first local variable slot to be allocated.
509:
510: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
511: subtracting the length of the first slot from `STARTING_FRAME_OFFSET'.
512: Otherwise, it is found by adding the length of the first slot to
513: the value `STARTING_FRAME_OFFSET'.
514:
515: `PUSH_ROUNDING (NPUSHED)'
516: A C expression that is the number of bytes actually pushed onto the
517: stack when an instruction attempts to push NPUSHED bytes.
518:
519: On some machines, the definition
520:
521: #define PUSH_ROUNDING(BYTES) (BYTES)
522:
523: will suffice. But on other machines, instructions that appear
524: to push one byte actually push two bytes in an attempt to maintain
525: alignment. Then the definition should be
526:
527: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
528:
529: `FIRST_PARM_OFFSET'
530: Offset from the argument pointer register to the first argument's address.
531:
532: `RETURN_POPS_ARGS'
533: Define this macro if returning from a function automatically pops the
534: function's arguments. Do not define it if the caller must pop them.
535:
536: `FUNCTION_PROLOGUE (FILE, SIZE)'
537: A C compound statement that outputs the assembler code for entry to a
538: function. The prologue is responsible for setting up the stack frame,
539: initializing the frame pointer register, saving registers that must be
540: saved, and allocating SIZE additional bytes of storage for the local
541: variables. SIZE is an integer. FILE is a stdio stream to
542: which the assembler code should be output.
543:
544: The label for the beginning of the function need not be output by this
545: macro. That has already been done when the macro is run.
546:
547: To determine which registers to save, the macro can refer to the array
548: `regs_ever_live': element R is nonzero if hard register R
549: is used anywhere within the function. This implies the function prologue
550: should save register R, but not if it is one of the call-used
551: registers.
552:
553: `FUNCTION_EPILOGUE (FILE, SIZE)'
554: A C compound statement that outputs the assembler code for exit from a
555: function. The epilogue is responsible for restoring the saved
556: registers and stack pointer to their values when the function was
557: called, and returning control to the caller. This macro takes the
558: same arguments as the macro `FUNCTION_PROLOGUE', and the
559: registers to restore are determined from `regs_ever_live' and
560: `CALL_USED_REGISTERS' in the same way.
561:
562: On some machines, there is a single instruction that does all the work of
563: returning from the function. On these machines, give that instruction the
564: name `return' and do not define the macro `FUNCTION_EPILOGUE' at
565: all.
566:
567:
568: File: internals Node: Addressing Modes, Prev: Stack Layout, Up: Machine Macros, Next: Misc
569:
570: Addressing Modes
571: ================
572:
573: `HAVE_POST_INCREMENT'
574: Define this macro if the machine supports post-increment addressing.
575:
576: `HAVE_PRE_INCREMENT'
577: `HAVE_POST_DECREMENT'
578: `HAVE_PRE_DECREMENT'
579: Similar for other kinds of addressing.
580:
581: `CONSTANT_ADDRESS_P (X)'
582: A C expression that is 1 if the rtx X is a constant whose value
583: is an integer. This includes integers whose values are not explicitly
584: known, such as `symbol_ref' and `label_ref' expressions
585: and `const' arithmetic expressions.
586:
587: `MAX_REGS_PER_ADDRESS'
588: A number, the maximum number of registers that can appear in a valid
589: memory address.
590:
591: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
592: A C compound statement with a conditional `goto LABEL;'
593: executed if X (an rtx) is a legitimate memory address on
594: the target machine for a memory operand of mode MODE.
595:
596: It usually pays to define several simpler macros to serve as
597: subroutines for this one. Otherwise it may be too complicated
598: to understand.
599:
600: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
601: A C compound statement that attempts to replace X with a valid
602: memory address for an operand of mode MODE. WIN will be
603: a C statement label elsewhere in the code; the macro definition
604: may use
605:
606: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
607:
608: to avoid further processing if the address has become legitimate.
609:
610: X will always be the result of a call to `break_out_memory_refs',
611: and OLDX will be the operand that was given to that function to produce
612: X.
613:
614: The code generated by this macro should not alter the substructure of X.
615: If it transforms X into a more legitimate form, it should assign X
616: (which will always be a C variable) a new value.
617:
618: It is not necessary for this macro to come up with a legitimate address.
619: The compiler has standard ways of doing so in all cases. In fact, it is
620: safe for this macro to do nothing. But often a machine-dependent strategy
621: can generate better code.
622:
623:
624: File: internals Node: Misc, Prev: Addressing Modes, Up: Machine Macros, Next: Condition Code
625:
626: Miscellaneous Parameters
627: ========================
628:
629: `CASE_VECTOR_MODE'
630: An alias for a machine mode name. This is the machine mode that elements
631: of a jump-table should have.
632:
633: `CASE_VECTOR_PC_RELATIVE'
634: Define this macro if jump-tables should contain relative addresses.
635:
636: `IMPLICIT_FIX_EXPR'
637: An alias for a tree code that should be used by default for conversion
638: of floating point values to fixed point. Normally, `FIX_ROUND_EXPR'
639: is used.
640:
641: `EASY_DIV_EXPR'
642: An alias for a tree code that is the easiest kind of division to compile
643: code for in the general case. It may be `TRUNC_DIV_EXPR',
644: `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or `ROUND_DIV_EXPR'.
645: These differ in how they round the result to an integer.
646: `EASY_DIV_EXPR' is used when it is permissible to use any of those
647: kinds of division and the choice should be made on the basis of efficiency.
648:
649: `MOVE_MAX'
650: The maximum number of bytes that a single instruction can move quickly
651: from memory to memory.
652:
653: `SLOW_ZERO_EXTEND'
654: Define this macro if zero-extension (of chars or shorts to integers)
655: can be done faster if the destination is a register that is known to be zero.
656:
657: `SHIFT_COUNT_TRUNCATED'
658: Define this macro if shift instructions ignore all but the lowest few
659: bits of the shift count. It implies that a sign-extend or zero-extend
660: instruction for the shift count can be omitted.
661:
662: `TRULY_NOOP_TRUNCATON (OUTPREC, INPREC)'
663: A C expression which is nonzero if on this machine it is safe to
664: "convert" an integer of INPREC bits to one of OUTPREC bits
665: (where OUTPREC is smaller than INPREC) by merely operating
666: on it as if it had only INPREC bits.
667:
668: On many machines, this expression can be 1.
669:
670: `Pmode'
671: An alias for the machine mode for pointers. Normally the definition can be
672:
673: #define Pmode SImode
674:
675: `FUNCTION_MODE'
676: An alias for the machine mode used for memory references to functions being
677: called, in `call' RTL expressions. On most machines this should be
678: `QImode'.
679:
680: `CONST_COST (X, CODE)'
681: A part of a C `switch' statement that describes the relative costs of
682: constant RTL expressions. It must contain `case' labels for
683: expression codes `const_int', `const', `symbol_ref',
684: `label_ref' and `const_double'. Each case must ultimately reach
685: a `return' statement to return the relative cost of the use of that
686: kind of constant value in an expression. The cost may depend on the
687: precise value of the constant, which is available for examination in
688: X.
689:
690: CODE is the expression code---redundant, since it can be obtained with
691: `GET_CODE (X)'.
692:
693:
694: File: internals Node: Condition Code, Prev: Misc, Up: Machine Macros, Next: Assembler Format
695:
696: Condition Code Information
697: ==========================
698:
699: The file `conditions.h' defines a variable `cc_status' to
700: describe how the condition code was computed (in case the interpretation of
701: the condition code depends on the instruction that it was set by). This
702: variable contains the RTL expressions on which the condition code is
703: currently based, and several standard flags.
704:
705: Sometimes additional machine-specific flags must be defined in the machine
706: description header file. It can also add additional machine-specific
707: information by defining `CC_STATUS_MDEP'.
708:
709: `CC_STATUS_MDEP'
710: A type, with which the `mdep' component of `cc_status' should
711: be declared. It defaults to `int'.
712:
713: `CC_STATUS_MDEP_INIT'
714: A C expression for the initial value of the `mdep' field.
715: It defaults to 0.
716:
717: `NOTICE_UPDATE_CC (EXP)'
718: A C compound statement to set the components of `cc_status'
719: appropriately for an insn whose body is EXP. It is this
720: macro's responsibility to recognize insns that set the condition code
721: as a byproduct of other activity as well as those that explicitly
722: set `(cc0)'.
723:
724: If there are insn that do not set the condition code but do alter other
725: machine registers, this macro must check to see whether they invalidate the
726: expressions that the condition code is recorded as reflecting. For
727: example, on the 68000, insns that store in address registers do not set the
728: condition code, which means that usually `NOTICE_UPDATE_CC' can leave
729: `cc_status' unaltered for such insns. But suppose that the previous
730: insn set the condition code based on location `a4@(102)' and the
731: current insn stores a new value in `a4'. Although the condition code
732: is not changed by this, it will no longer be true that it reflects the
733: contents of `a4@(102)'. Therefore, `NOTICE_UPDATE_CC' must alter
734: `cc_status' in this case to say that nothing is known about the
735: condition code value.
736:
737:
738: File: internals Node: Assembler Format, Prev: Condition Code, Up: Machine Macros
739:
740: Output of Assembler Code
741: ========================
742:
743: `TEXT_SECTION_ASM_OP'
744: A C string constant for the assembler operation that should precede
745: instructions and read-only data. Normally `".text"' is right.
746:
747: `DATA_SECTION_ASM_OP'
748: A C string constant for the assembler operation to identify the following
749: data as writable initialized data. Normally `".data"' is right.
750:
751: `REGISTER_NAMES'
752: A C initializer containing the assembler's names for the machine registers,
753: each one as a C string constant. This is what translates register numbers
754: in the compiler into assembler language.
755:
756: `DBX_REGISTER_NUMBER (REGNO)'
757: A C expression that returns the DBX register number for the compiler register
758: number REGNO. In simple cases, the value of this expression may be
759: REGNO itself. But sometimes there are some registers that the compiler
760: knows about and DBX does not, or vice versa. In such cases, some register
761: may need to have one number in the compiler and another for DBX.
762:
763: `ASM_OUTPUT_DOUBLE (FILE, VALUE)'
764: A C statement to output to the stdio stream FILE an assembler
765: instruction to assemble a `double' constant whose value is
766: VALUE. VALUE will be a C expression of type `double'.
767:
768: `ASM_OUTPUT_FLOAT (FILE, VALUE)'
769: A C statement to output to the stdio stream FILE an assembler
770: instruction to assemble a `float' constant whose value is VALUE.
771: VALUE will be a C expression of type `float'.
772:
773: `ASM_OUTPUT_SKIP (FILE, NBYTES)'
774: A C statement to output to the stdio stream FILE an assembler
775: instruction to advance the location counter by NBYTES bytes.
776: NBYTES will be a C expression of type `int'.
777:
778: `ASM_OUTPUT_ALIGN (FILE, POWER)'
779: A C statement to output to the stdio stream FILE an assembler
780: instruction to advance the location counter to a multiple of 2 to the
781: POWER bytes. POWER will be a C expression of type `int'.
782:
783: `ASM_INT_OP'
784: A C string constant for the assembler operation that assembles constants of
785: C type `int'. A space must follow the operation name. Normally
786: `".long "'.
787:
788: `ASM_SHORT_OP'
789: `ASM_CHAR_OP'
790: Likewise, for C types `short' and `char'. Normally `".word "'
791: and `".byte "'.
792:
793: `TARGET_BELL'
794: A C constant expression for the integer value for escape sequence `\a'.
795:
796: `TARGET_BS'
797: `TARGET_TAB'
798: `TARGET_NEWLINE'
799: C constant expressions for the integer values for escape sequences
800: `\b', `\t' and `\n'.
801:
802: `TARGET_VT'
803: `TARGET_FF'
804: `TARGET_CR'
805: C constant expressions for the integer values for escape sequences
806: `\v', `\f' and `\r'.
807:
808: `PRINT_OPERAND (FILE, X)'
809: A C compound statement to output to stdio stream FILE
810: the assembler syntax for an instruction operand X.
811: X is an RTL expression.
812:
813: If X is a register, this macro should print the register's name. The
814: names can be found in an array `reg_names' whose type is `char
815: *[]'. `reg_names' is initialized from `REGISTER_NAMES'.
816:
817: `PRINT_OPERAND_ADDRESS (FILE, X)'
818: A C compound statement to output to stdio stream FILE the assembler
819: syntax for an instruction operand that is a memory reference whose address
820: is X. X is an RTL expression.
821:
822:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.