![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-14 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-14 CVS log | Up to [GCC 2.x] / gcc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.43 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988, 1989, 1992 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of
9: this manual provided the copyright notice and this permission notice
10: are preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled "GNU General Public License" is included
15: exactly as in the original, and provided that the entire resulting
16: derived work is distributed under the terms of a permission notice
17: identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled "GNU General Public
22: License" and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27: File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Machine Macros
28:
29: Trampolines for Nested Functions
30: ================================
31:
32: A "trampoline" is a small piece of code that is created at run time
33: when the address of a nested function is taken. It normally resides on
34: the stack, in the stack frame of the containing function. These macros
35: tell GNU CC how to generate code to allocate and initialize a
36: trampoline.
37:
38: The instructions in the trampoline must do two things: load a
39: constant address into the static chain register, and jump to the real
40: address of the nested function. On CISC machines such as the m68k,
41: this requires two instructions, a move immediate and a jump. Then the
42: two addresses exist in the trampoline as word-long immediate operands.
43: On RISC machines, it is often necessary to load each address into a
44: register in two parts. Then pieces of each address form separate
45: immediate operands.
46:
47: The code generated to initialize the trampoline must store the
48: variable parts--the static chain value and the function address--into
49: the immediate operands of the instructions. On a CISC machine, this is
50: simply a matter of copying each address to a memory reference at the
51: proper offset from the start of the trampoline. On a RISC machine, it
52: may be necessary to take out pieces of the address and store them
53: separately.
54:
55: `TRAMPOLINE_TEMPLATE (FILE)'
56: A C statement to output, on the stream FILE, assembler code for a
57: block of data that contains the constant parts of a trampoline.
58: This code should not include a label--the label is taken care of
59: automatically.
60:
61: `TRAMPOLINE_SIZE'
62: A C expression for the size in bytes of the trampoline, as an
63: integer.
64:
65: `TRAMPOLINE_ALIGNMENT'
66: Alignment required for trampolines, in bits.
67:
68: If you don't define this macro, the value of `BIGGEST_ALIGNMENT'
69: is used for aligning trampolines.
70:
71: `INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)'
72: A C statement to initialize the variable parts of a trampoline.
73: ADDR is an RTX for the address of the trampoline; FNADDR is an
74: RTX for the address of the nested function; STATIC_CHAIN is an
75: RTX for the static chain value that should be passed to the
76: function when it is called.
77:
78: `ALLOCATE_TRAMPOLINE (FP)'
79: A C expression to allocate run-time space for a trampoline. The
80: expression value should be an RTX representing a memory reference
81: to the space for the trampoline.
82:
83: If this macro is not defined, by default the trampoline is
84: allocated as a stack slot. This default is right for most
85: machines. The exceptions are machines where it is impossible to
86: execute instructions in the stack area. On such machines, you
87: may have to implement a separate stack, using this macro in
88: conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'.
89:
90: FP points to a data structure, a `struct function', which
91: describes the compilation status of the immediate containing
92: function of the function which the trampoline is for. Normally
93: (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for
94: the trampoline is in the stack frame of this containing function.
95: Other allocation strategies probably must do something analogous
96: with this information.
97:
98: Implementing trampolines is difficult on many machines because they
99: have separate instruction and data caches. Writing into a stack
100: location fails to clear the memory in the instruction cache, so when
101: the program jumps to that location, it executes the old contents.
102:
103: Here are two possible solutions. One is to clear the relevant
104: parts of the instruction cache whenever a trampoline is set up. The
105: other is to make all trampolines identical, by having them jump to a
106: standard subroutine. The former technique makes trampoline execution
107: faster; the latter makes initialization faster.
108:
109: To clear the instruction cache when a trampoline is initialized,
110: define the following macros which describe the shape of the cache.
111:
112: `INSN_CACHE_SIZE'
113: The total size in bytes of the cache.
114:
115: `INSN_CACHE_LINE_WIDTH'
116: The length in bytes of each cache line. The cache is divided
117: into cache lines which are disjoint slots, each holding a
118: contiguous chunk of data fetched from memory. Each time data is
119: brought into the cache, an entire line is read at once. The data
120: loaded into a cache line is always aligned on a boundary equal to
121: the line size.
122:
123: `INSN_CACHE_DEPTH'
124: The number of alternative cache lines that can hold any
125: particular memory location.
126:
127: To use a standard subroutine, define the following macro. In
128: addition, you must make sure that the instructions in a trampoline
129: fill an entire cache line with identical instructions, or else ensure
130: that the beginning of the trampoline code is always aligned at the
131: same point in its cache line. Look in `m68k.h' as a guide.
132:
133: `TRANSFER_FROM_TRAMPOLINE'
134: Define this macro if trampolines need a special subroutine to do
135: their work. The macro should expand to a series of `asm'
136: statements which will be compiled with GNU CC. They go in a
137: library function named `__transfer_from_trampoline'.
138:
139: If you need to avoid executing the ordinary prologue code of a
140: compiled C function when you jump to the subroutine, you can do
141: so by placing a special label of your own in the assembler code.
142: Use one `asm' statement to generate an assembler label, and
143: another to make the label global. Then trampolines can use that
144: label to jump directly to your special assembler code.
145:
146:
147: File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Machine Macros
148:
149: Implicit Calls to Library Routines
150: ==================================
151:
152: `MULSI3_LIBCALL'
153: A C string constant giving the name of the function to call for
154: multiplication of one signed full-word by another. If you do not
155: define this macro, the default name is used, which is `__mulsi3',
156: a function defined in `libgcc.a'.
157:
158: `DIVSI3_LIBCALL'
159: A C string constant giving the name of the function to call for
160: division of one signed full-word by another. If you do not define
161: this macro, the default name is used, which is `__divsi3', a
162: function defined in `libgcc.a'.
163:
164: `UDIVSI3_LIBCALL'
165: A C string constant giving the name of the function to call for
166: division of one unsigned full-word by another. If you do not
167: define this macro, the default name is used, which is
168: `__udivsi3', a function defined in `libgcc.a'.
169:
170: `MODSI3_LIBCALL'
171: A C string constant giving the name of the function to call for
172: the remainder in division of one signed full-word by another. If
173: you do not define this macro, the default name is used, which is
174: `__modsi3', a function defined in `libgcc.a'.
175:
176: `UMODSI3_LIBCALL'
177: A C string constant giving the name of the function to call for
178: the remainder in division of one unsigned full-word by another.
179: If you do not define this macro, the default name is used, which
180: is `__umodsi3', a function defined in `libgcc.a'.
181:
182: `MULDI3_LIBCALL'
183: A C string constant giving the name of the function to call for
184: multiplication of one signed double-word by another. If you do
185: not define this macro, the default name is used, which is
186: `__muldi3', a function defined in `libgcc.a'.
187:
188: `DIVDI3_LIBCALL'
189: A C string constant giving the name of the function to call for
190: division of one signed double-word by another. If you do not
191: define this macro, the default name is used, which is `__divdi3',
192: a function defined in `libgcc.a'.
193:
194: `UDIVDI3_LIBCALL'
195: A C string constant giving the name of the function to call for
196: division of one unsigned full-word by another. If you do not
197: define this macro, the default name is used, which is
198: `__udivdi3', a function defined in `libgcc.a'.
199:
200: `MODDI3_LIBCALL'
201: A C string constant giving the name of the function to call for
202: the remainder in division of one signed double-word by another.
203: If you do not define this macro, the default name is used, which
204: is `__moddi3', a function defined in `libgcc.a'.
205:
206: `UMODDI3_LIBCALL'
207: A C string constant giving the name of the function to call for
208: the remainder in division of one unsigned full-word by another.
209: If you do not define this macro, the default name is used, which
210: is `__umoddi3', a function defined in `libgcc.a'.
211:
212: `TARGET_MEM_FUNCTIONS'
213: Define this macro if GNU CC should generate calls to the System V
214: (and ANSI C) library functions `memcpy' and `memset' rather than
215: the BSD functions `bcopy' and `bzero'.
216:
217: `LIBGCC_NEEDS_DOUBLE'
218: Define this macro if only `float' arguments cannot be passed to
219: library routines (so they must be converted to `double'). This
220: macro affects both how library calls are generated and how the
221: library routines in `libgcc1.c' accept their arguments. It is
222: useful on machines where floating and fixed point arguments are
223: passed differently, such as the i860.
224:
225: `FLOAT_ARG_TYPE'
226: Define this macro to override the type used by the library
227: routines to pick up arguments of type `float'. (By default, they
228: use a union of `float' and `int'.)
229:
230: The obvious choice would be `float'--but that won't work with
231: traditional C compilers that expect all arguments declared as
232: `float' to arrive as `double'. To avoid this conversion, the
233: library routines ask for the value as some other type and then
234: treat it as a `float'.
235:
236: On some systems, no other type will work for this. For these
237: systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force
238: conversion of the values `double' before they are passed.
239:
240: `FLOATIFY (PASSED-VALUE)'
241: Define this macro to override the way library routines
242: redesignate a `float' argument as a `float' instead of the type
243: it was passed as. The default is an expression which takes the
244: `float' field of the union.
245:
246: `FLOAT_VALUE_TYPE'
247: Define this macro to override the type used by the library
248: routines to return values that ought to have type `float'. (By
249: default, they use `int'.)
250:
251: The obvious choice would be `float'--but that won't work with
252: traditional C compilers gratuitously convert values declared as
253: `float' into `double'.
254:
255: `INTIFY (FLOAT-VALUE)'
256: Define this macro to override the way the value of a
257: `float'-returning library routine should be packaged in order to
258: return it. These functions are actually declared to return type
259: `FLOAT_VALUE_TYPE' (normally `int').
260:
261: These values can't be returned as type `float' because traditional
262: C compilers would gratuitously convert the value to a `double'.
263:
264: A local variable named `intify' is always available when the macro
265: `INTIFY' is used. It is a union of a `float' field named `f' and
266: a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'.
267:
268: If you don't define this macro, the default definition works by
269: copying the value through that union.
270:
271: `SItype'
272: Define this macro as the name of the data type corresponding to
273: `SImode' in the system's own C compiler.
274:
275: You need not define this macro if that type is `int', as it
276: usually is.
277:
278: `perform_...'
279: Define these macros to supply explicit C statements to carry out
280: various arithmetic operations on types `float' and `double' in the
281: library routines in `libgcc1.c'. See that file for a full list
282: of these macros and their arguments.
283:
284: On most machines, you don't need to define any of these macros,
285: because the C compiler that comes with the system takes care of
286: doing them.
287:
288: `NEXT_OBJC_RUNTIME'
289: Define this macro to generate code for Objective C message
290: sending using the calling convention of the NeXT system. This
291: calling convention involves passing the object, the selector and
292: the method arguments all at once to the method-lookup library
293: function.
294:
295: The default calling convention passes just the object and the
296: selector to the lookup function, which returns a pointer to the
297: method.
298:
299:
300: File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Machine Macros
301:
302: Addressing Modes
303: ================
304:
305: `HAVE_POST_INCREMENT'
306: Define this macro if the machine supports post-increment
307: addressing.
308:
309: `HAVE_PRE_INCREMENT'
310: `HAVE_POST_DECREMENT'
311: `HAVE_PRE_DECREMENT'
312: Similar for other kinds of addressing.
313:
314: `CONSTANT_ADDRESS_P (X)'
315: A C expression that is 1 if the RTX X is a constant which is a
316: valid address. On most machines, this can be defined as
317: `CONSTANT_P (X)', but a few machines are more restrictive in
318: which constant addresses are supported.
319:
320: `CONSTANT_P' accepts integer-values expressions whose values are
321: not explicitly known, such as `symbol_ref', `label_ref', and
322: `high' expressions and `const' arithmetic expressions, in
323: addition to `const_int' and `const_double' expressions.
324:
325: `MAX_REGS_PER_ADDRESS'
326: A number, the maximum number of registers that can appear in a
327: valid memory address. Note that it is up to you to specify a
328: value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS'
329: would ever accept.
330:
331: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
332: A C compound statement with a conditional `goto LABEL;' executed
333: if X (an RTX) is a legitimate memory address on the target
334: machine for a memory operand of mode MODE.
335:
336: It usually pays to define several simpler macros to serve as
337: subroutines for this one. Otherwise it may be too complicated to
338: understand.
339:
340: This macro must exist in two variants: a strict variant and a
341: non-strict one. The strict variant is used in the reload pass.
342: It must be defined so that any pseudo-register that has not been
343: allocated a hard register is considered a memory reference. In
344: contexts where some kind of register is required, a
345: pseudo-register with no hard register must be rejected.
346:
347: The non-strict variant is used in other passes. It must be
348: defined to accept all pseudo-registers in every context where
349: some kind of register is required.
350:
351: Compiler source files that want to use the strict variant of this
352: macro define the macro `REG_OK_STRICT'. You should use an
353: `#ifdef REG_OK_STRICT' conditional to define the strict variant
354: in that case and the non-strict variant otherwise.
355:
356: Typically among the subroutines used to define
357: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for
358: acceptable registers for various purposes (one for base
359: registers, one for index registers, and so on). Then only these
360: subroutine macros need have two variants; the higher levels of
361: macros may be the same whether strict or not.
362:
363: Normally, constant addresses which are the sum of a `symbol_ref'
364: and an integer are stored inside a `const' RTX to mark them as
365: constant. Therefore, there is no need to recognize such sums
366: specifically as legitimate addresses. Normally you would simply
367: recognize any `const' as legitimate.
368:
369: Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant
370: sums that are not marked with `const'. It assumes that a naked
371: `plus' indicates indexing. If so, then you *must* reject such
372: naked constant sums as illegitimate addresses, so that none of
373: them will be given to `PRINT_OPERAND_ADDRESS'.
374:
375: On some machines, whether a symbolic address is legitimate
376: depends on the section that the address refers to. On these
377: machines, define the macro `ENCODE_SECTION_INFO' to store the
378: information into the `symbol_ref', and then check for it here.
379: When you see a `const', you will have to look inside it to find
380: the `symbol_ref' in order to determine the section. *Note
381: Assembler Format::.
382:
383: The best way to modify the name string is by adding text to the
384: beginning, with suitable punctuation to prevent any ambiguity.
385: Allocate the new name in `saveable_obstack'. You will have to
386: modify `ASM_OUTPUT_LABELREF' to remove and decode the added text
387: and output the name accordingly.
388:
389: You can check the information stored here into the `symbol_ref' in
390: the definitions of `GO_IF_LEGITIMATE_ADDRESS' and
391: `PRINT_OPERAND_ADDRESS'.
392:
393: `REG_OK_FOR_BASE_P (X)'
394: A C expression that is nonzero if X (assumed to be a `reg' RTX)
395: is valid for use as a base register. For hard registers, it
396: should always accept those which the hardware permits and reject
397: the others. Whether the macro accepts or rejects pseudo
398: registers must be controlled by `REG_OK_STRICT' as described
399: above. This usually requires two variant definitions, of which
400: `REG_OK_STRICT' controls the one actually used.
401:
402: `REG_OK_FOR_INDEX_P (X)'
403: A C expression that is nonzero if X (assumed to be a `reg' RTX)
404: is valid for use as an index register.
405:
406: The difference between an index register and a base register is
407: that the index register may be scaled. If an address involves
408: the sum of two registers, neither one of them scaled, then either
409: one may be labeled the "base" and the other the "index"; but
410: whichever labeling is used must fit the machine's constraints of
411: which registers may serve in each capacity. The compiler will
412: try both labelings, looking for one that is valid, and will
413: reload one or both registers only if neither labeling works.
414:
415: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
416: A C compound statement that attempts to replace X with a valid
417: memory address for an operand of mode MODE. WIN will be a C
418: statement label elsewhere in the code; the macro definition may
419: use
420:
421: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
422:
423: to avoid further processing if the address has become legitimate.
424:
425: X will always be the result of a call to `break_out_memory_refs',
426: and OLDX will be the operand that was given to that function to
427: produce X.
428:
429: The code generated by this macro should not alter the
430: substructure of X. If it transforms X into a more legitimate
431: form, it should assign X (which will always be a C variable) a
432: new value.
433:
434: It is not necessary for this macro to come up with a legitimate
435: address. The compiler has standard ways of doing so in all
436: cases. In fact, it is safe for this macro to do nothing. But
437: often a machine-dependent strategy can generate better code.
438:
439: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
440: A C statement or compound statement with a conditional `goto
441: LABEL;' executed if memory address X (an RTX) can have different
442: meanings depending on the machine mode of the memory reference it
443: is used for.
444:
445: Autoincrement and autodecrement addresses typically have
446: mode-dependent effects because the amount of the increment or
447: decrement is the size of the operand being addressed. Some
448: machines have other mode-dependent addresses. Many RISC machines
449: have no mode-dependent addresses.
450:
451: You may assume that ADDR is a valid address for the machine.
452:
453: `LEGITIMATE_CONSTANT_P (X)'
454: A C expression that is nonzero if X is a legitimate constant for
455: an immediate operand on the target machine. You can assume that
456: X satisfies `CONSTANT_P', so you need not check this. In fact,
457: `1' is a suitable definition for this macro on machines where
458: anything `CONSTANT_P' is valid.
459:
460: `LEGITIMATE_PIC_OPERAND_P (X)'
461: A C expression that is nonzero if X is a legitimate immediate
462: operand on the target machine when generating position
463: independent code. You can assume that X satisfies `CONSTANT_P',
464: so you need not check this. You can also assume FLAG_PIC is
465: true, so you need not check it either. You need not define this
466: macro if all constants (including `SYMBOL_REF') can be immediate
467: operands when generating position independent code.
468:
469:
470: File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Machine Macros
471:
472: Condition Code Status
473: =====================
474:
475: The file `conditions.h' defines a variable `cc_status' to describe
476: how the condition code was computed (in case the interpretation of the
477: condition code depends on the instruction that it was set by). This
478: variable contains the RTL expressions on which the condition code is
479: currently based, and several standard flags.
480:
481: Sometimes additional machine-specific flags must be defined in the
482: machine description header file. It can also add additional
483: machine-specific information by defining `CC_STATUS_MDEP'.
484:
485: `CC_STATUS_MDEP'
486: C code for a data type which is used for declaring the `mdep'
487: component of `cc_status'. It defaults to `int'.
488:
489: This macro is not used on machines that do not use `cc0'.
490:
491: `CC_STATUS_MDEP_INIT'
492: A C expression to initialize the `mdep' field to "empty". The
493: default definition does nothing, since most machines don't use
494: the field anyway. If you want to use the field, you should
495: probably define this macro to initialize it.
496:
497: This macro is not used on machines that do not use `cc0'.
498:
499: `NOTICE_UPDATE_CC (EXP, INSN)'
500: A C compound statement to set the components of `cc_status'
501: appropriately for an insn INSN whose body is EXP. It is this
502: macro's responsibility to recognize insns that set the condition
503: code as a byproduct of other activity as well as those that
504: explicitly set `(cc0)'.
505:
506: This macro is not used on machines that do not use `cc0'.
507:
508: If there are insns that do not set the condition code but do alter
509: other machine registers, this macro must check to see whether they
510: invalidate the expressions that the condition code is recorded as
511: reflecting. For example, on the 68000, insns that store in
512: address registers do not set the condition code, which means that
513: usually `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for
514: such insns. But suppose that the previous insn set the condition
515: code based on location `a4@(102)' and the current insn stores a
516: new value in `a4'. Although the condition code is not changed by
517: this, it will no longer be true that it reflects the contents of
518: `a4@(102)'. Therefore, `NOTICE_UPDATE_CC' must alter `cc_status'
519: in this case to say that nothing is known about the condition
520: code value.
521:
522: The definition of `NOTICE_UPDATE_CC' must be prepared to deal
523: with the results of peephole optimization: insns whose patterns
524: are `parallel' RTXs containing various `reg', `mem' or constants
525: which are just the operands. The RTL structure of these insns is
526: not sufficient to indicate what the insns actually do. What
527: `NOTICE_UPDATE_CC' should do when it sees one is just to run
528: `CC_STATUS_INIT'.
529:
530: A possible definition of `NOTICE_UPDATE_CC' is to call a function
531: that looks at an attribute (*note Insn Attributes::.) named, for
532: example, `cc'. This avoids having detailed information about
533: patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'.
534:
535: `EXTRA_CC_MODES'
536: A list of names to be used for additional modes for condition code
537: values in registers (*note Jump Patterns::.). These names are
538: added to `enum machine_mode' and all have class `MODE_CC'. By
539: convention, they should start with `CC' and end with `mode'.
540:
541: You should only define this macro if your machine does not use
542: `cc0' and only if additional modes are required.
543:
544: `EXTRA_CC_NAMES'
545: A list of C strings giving the names for the modes listed in
546: `EXTRA_CC_MODES'. For example, the Sparc defines this macro and
547: `EXTRA_CC_MODES' as
548:
549: #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode
550: #define EXTRA_CC_NAMES "CC_NOOV", "CCFP"
551:
552: This macro is not required if `EXTRA_CC_MODES' is not defined.
553:
554: `SELECT_CC_MODE (OP, X)'
555: Returns a mode from class `MODE_CC' to be used when comparison
556: operation code OP is applied to rtx X. For example, on the Sparc,
557: `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. for a
558: description of the reason for this definition)
559:
560: #define SELECT_CC_MODE(OP,X) \
561: (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \
562: : (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
563: || GET_CODE (X) == NEG) \
564: ? CC_NOOVmode : CCmode)
565:
566: This macro is not required if `EXTRA_CC_MODES' is not defined.
567:
568:
569: File: gcc.info, Node: Costs, Next: Sections, Prev: Condition Code, Up: Machine Macros
570:
571: Describing Relative Costs of Operations
572: =======================================
573:
574: These macros let you describe the relative speed of various
575: operations on the target machine.
576:
577: `CONST_COSTS (X, CODE)'
578: A part of a C `switch' statement that describes the relative costs
579: of constant RTL expressions. It must contain `case' labels for
580: expression codes `const_int', `const', `symbol_ref', `label_ref'
581: and `const_double'. Each case must ultimately reach a `return'
582: statement to return the relative cost of the use of that kind of
583: constant value in an expression. The cost may depend on the
584: precise value of the constant, which is available for examination
585: in X.
586:
587: CODE is the expression code--redundant, since it can be obtained
588: with `GET_CODE (X)'.
589:
590: `RTX_COSTS (X, CODE)'
591: Like `CONST_COSTS' but applies to nonconstant RTL expressions.
592: This can be used, for example, to indicate how costly a multiply
593: instruction is. In writing this macro, you can use the construct
594: `COSTS_N_INSNS (N)' to specify a cost equal to N fast
595: instructions.
596:
597: This macro is optional; do not define it if the default cost
598: assumptions are adequate for the target machine.
599:
600: `ADDRESS_COST (ADDRESS)'
601: An expression giving the cost of an addressing mode that contains
602: ADDRESS. If not defined, the cost is computed from the ADDRESS
603: expression and the `CONST_COSTS' values.
604:
605: For most CISC machines, the default cost is a good approximation
606: of the true cost of the addressing mode. However, on RISC
607: machines, all instructions normally have the same length and
608: execution time. Hence all addresses will have equal costs.
609:
610: In cases where more than one form of an address is known, the
611: form with the lowest cost will be used. If multiple forms have
612: the same, lowest, cost, the one that is the most complex will be
613: used.
614:
615: For example, suppose an address that is equal to the sum of a
616: register and a constant is used twice in the same basic block.
617: When this macro is not defined, the address will be computed in a
618: register and memory references will be indirect through that
619: register. On machines where the cost of the addressing mode
620: containing the sum is no higher than that of a simple indirect
621: reference, this will produce an additional instruction and
622: possibly require an additional register. Proper specification of
623: this macro eliminates this overhead for such machines.
624:
625: Similar use of this macro is made in strength reduction of loops.
626:
627: ADDRESS need not be valid as an address. In such a case, the cost
628: is not relevant and can be any value; invalid addresses need not
629: be assigned a different cost.
630:
631: On machines where an address involving more than one register is
632: as cheap as an address computation involving only one register,
633: defining `ADDRESS_COST' to reflect this can cause two registers
634: to be live over a region of code where only one would have been if
635: `ADDRESS_COST' were not defined in that manner. This effect
636: should be considered in the definition of this macro. Equivalent
637: costs should probably only be given to addresses with different
638: numbers of registers on machines with lots of registers.
639:
640: This macro will normally either not be defined or be defined as a
641: constant.
642:
643: `REGISTER_MOVE_COST (FROM, TO)'
644: A C expression for the cost of moving data from a register in
645: class FROM to one in class TO. The classes are expressed using
646: the enumeration values such as `GENERAL_REGS'. A value of 2 is
647: the default; other values are interpreted relative to that.
648:
649: It is not required that the cost always equal 2 when FROM is the
650: same as TO; on some machines it is expensive to move between
651: registers if they are not general registers.
652:
653: If reload sees an insn consisting of a single `set' between two
654: hard registers, and if `REGISTER_MOVE_COST' applied to their
655: classes returns a value of 2, reload does not check to ensure
656: that the constraints of the insn are met. Setting a cost of
657: other than 2 will allow reload to verify that the constraints are
658: met. You should do this if the `movM' pattern's constraints do
659: not allow such copying.
660:
661: `MEMORY_MOVE_COST (M)'
662: A C expression for the cost of moving data of mode M between a
663: register and memory. A value of 2 is the default; this cost is
664: relative to those in `REGISTER_MOVE_COST'.
665:
666: If moving between registers and memory is more expensive than
667: between two registers, you should define this macro to express
668: the relative cost.
669:
670: `BRANCH_COST'
671: A C expression for the cost of a branch instruction. A value of
672: 1 is the default; other values are interpreted relative to that.
673:
674: Here are additional macros which do not specify precise relative
675: costs, but only that certain actions are more expensive than GNU CC
676: would ordinarily expect.
677:
678: `SLOW_BYTE_ACCESS'
679: Define this macro as a C expression which is nonzero if accessing
680: less than a word of memory (i.e. a `char' or a `short') is no
681: faster than accessing a word of memory, i.e., if such access
682: require more than one instruction or if there is no difference in
683: cost between byte and (aligned) word loads.
684:
685: When this macro is not defined, the compiler will access a field
686: by finding the smallest containing object; when it is defined, a
687: fullword load will be used if alignment permits. Unless bytes
688: accesses are faster than word accesses, using word accesses is
689: preferable since it may eliminate subsequent memory access if
690: subsequent accesses occur to other fields in the same word of the
691: structure, but to different bytes.
692:
693: `SLOW_ZERO_EXTEND'
694: Define this macro if zero-extension (of a `char' or `short' to an
695: `int') can be done faster if the destination is a register that
696: is known to be zero.
697:
698: If you define this macro, you must have instruction patterns that
699: recognize RTL structures like this:
700:
701: (set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...)
702:
703: and likewise for `HImode'.
704:
705: `SLOW_UNALIGNED_ACCESS'
706: Define this macro if unaligned accesses have a cost many times
707: greater than aligned accesses, for example if they are emulated
708: in a trap handler.
709:
710: When this macro is defined, the compiler will act as if
711: `STRICT_ALIGNMENT' were defined when generating code for block
712: moves. This can cause significantly more instructions to be
713: produced. Therefore, do not define this macro if unaligned
714: accesses only add a cycle or two to the time for a memory access.
715:
716: `DONT_REDUCE_ADDR'
717: Define this macro to inhibit strength reduction of memory
718: addresses. (On some machines, such strength reduction seems to
719: do harm rather than good.)
720:
721: `MOVE_RATIO'
722: The number of scalar move insns which should be generated instead
723: of a string move insn or a library call. Increasing the value
724: will always make code faster, but eventually incurs high cost in
725: increased code size.
726:
727: If you don't define this, a reasonable default is used.
728:
729: `NO_FUNCTION_CSE'
730: Define this macro if it is as good or better to call a constant
731: function address than to call an address kept in a register.
732:
733: `NO_RECURSIVE_FUNCTION_CSE'
734: Define this macro if it is as good or better for a function to
735: call itself with an explicit address than to call an address kept
736: in a register.
737:
738:
739: File: gcc.info, Node: Sections, Next: PIC, Prev: Costs, Up: Machine Macros
740:
741: Dividing the Output into Sections (Texts, Data, ...)
742: ====================================================
743:
744: An object file is divided into sections containing different types
745: of data. In the most common case, there are three sections: the "text
746: section", which holds instructions and read-only data; the "data
747: section", which holds initialized writable data; and the "bss
748: section", which holds uninitialized data. Some systems have other
749: kinds of sections.
750:
751: The compiler must tell the assembler when to switch sections. These
752: macros control what commands to output to tell the assembler this. You
753: can also define additional sections.
754:
755: `TEXT_SECTION_ASM_OP'
756: A C string constant for the assembler operation that should
757: precede instructions and read-only data. Normally `".text"' is
758: right.
759:
760: `DATA_SECTION_ASM_OP'
761: A C string constant for the assembler operation to identify the
762: following data as writable initialized data. Normally `".data"'
763: is right.
764:
765: `SHARED_SECTION_ASM_OP'
766: If defined, a C string constant for the assembler operation to
767: identify the following data as shared data. If not defined,
768: `DATA_SECTION_ASM_OP' will be used.
769:
770: `INIT_SECTION_ASM_OP'
771: If defined, a C string constant for the assembler operation to
772: identify the following data as initialization code. If not
773: defined, GNU CC will assume such a section does not exist.
774:
775: `EXTRA_SECTIONS'
776: A list of names for sections other than the standard two, which
777: are `in_text' and `in_data'. You need not define this macro on a
778: system with no other sections (that GCC needs to use).
779:
780: `EXTRA_SECTION_FUNCTIONS'
781: One or more functions to be defined in `varasm.c'. These
782: functions should do jobs analogous to those of `text_section' and
783: `data_section', for your additional sections. Do not define this
784: macro if you do not define `EXTRA_SECTIONS'.
785:
786: `READONLY_DATA_SECTION'
787: On most machines, read-only variables, constants, and jump tables
788: are placed in the text section. If this is not the case on your
789: machine, this macro should be defined to be the name of a
790: function (either `data_section' or a function defined in
791: `EXTRA_SECTIONS') that switches to the section to be used for
792: read-only items.
793:
794: If these items should be placed in the text section, this macro
795: should not be defined.
796:
797: `SELECT_SECTION (EXP, RELOC)'
798: A C statement or statements to switch to the appropriate section
799: for output of EXP. You can assume that EXP is either a
800: `VAR_DECL' node or a constant of some sort. RELOC indicates
801: whether the initial value of EXP requires link-time relocations.
802: Select the section by calling `text_section' or one of the
803: alternatives for other sections.
804:
805: Do not define this macro if you put all read-only variables and
806: constants in the read-only data section (usually the text
807: section).
808:
809: `SELECT_RTX_SECTION (MODE, RTX)'
810: A C statement or statements to switch to the appropriate section
811: for output of RTX in mode MODE. You can assume that RTX is some
812: kind of constant in RTL. The argument MODE is redundant except
813: in the case of a `const_int' rtx. Select the section by calling
814: `text_section' or one of the alternatives for other sections.
815:
816: Do not define this macro if you put all constants in the read-only
817: data section.
818:
819: `JUMP_TABLES_IN_TEXT_SECTION'
820: Define this macro if jump tables (for `tablejump' insns) should be
821: output in the text section, along with the assembler instructions.
822: Otherwise, the readonly data section is used.
823:
824: This macro is irrelevant if there is no separate readonly data
825: section.
826:
827: `ENCODE_SECTION_INFO (DECL)'
828: Define this macro if references to a symbol must be treated
829: differently depending on something about the variable or function
830: named by the symbol (such as what section it is in).
831:
832: The macro definition, if any, is executed immediately after the
833: rtl for DECL has been created and stored in `DECL_RTL (DECL)'.
834: The value of the rtl will be a `mem' whose address is a
835: `symbol_ref'.
836:
837: The usual thing for this macro to do is to record a flag in the
838: `symbol_ref' (such as `SYMBOL_REF_FLAG') or to store a modified
839: name string in the `symbol_ref' (if one bit is not enough
840: information).
841:
842:
843: File: gcc.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Machine Macros
844:
845: Position Independent Code
846: =========================
847:
848: This section describes macros that help implement generation of
849: position independent code. Simply defining these macros is not enough
850: to generate valid PIC; you must also add support to the macros
851: `GO_IF_LEGITIMATE_ADDRESS' and `LEGITIMIZE_ADDRESS', and
852: `PRINT_OPERAND_ADDRESS' as well. You must modify the definition of
853: `movsi' to do something appropriate when the source operand contains a
854: symbolic address. You may also need to alter the handling of switch
855: statements so that they use relative addresses.
856:
857: `PIC_OFFSET_TABLE_REGNUM'
858: The register number of the register used to address a table of
859: static data addresses in memory. In some cases this register is
860: defined by a processor's "application binary interface" (ABI).
861: When this macro is defined, RTL is generated for this register
862: once, as with the stack pointer and frame pointer registers. If
863: this macro is not defined, it is up to the machine-dependent
864: files to allocate such a register (if necessary).
865:
866: `FINALIZE_PIC'
867: By generating position-independent code, when two different
868: programs (A and B) share a common library (libC.a), the text of
869: the library can be shared whether or not the library is linked at
870: the same address for both programs. In some of these
871: environments, position-independent code requires not only the use
872: of different addressing modes, but also special code to enable
873: the use of these addressing modes.
874:
875: The `FINALIZE_PIC' macro serves as a hook to emit these special
876: codes once the function is being compiled into assembly code, but
877: not before. (It is not done before, because in the case of
878: compiling an inline function, it would lead to multiple PIC
879: prologues being included in functions which used inline functions
880: and were compiled to assembly language.)
881:
882:
883: File: gcc.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Machine Macros
884:
885: Defining the Output Assembler Language
886: ======================================
887:
888: This section describes macros whose principal purpose is to
889: describe how to write instructions in assembler language--rather than
890: what the instructions do.
891:
892: * Menu:
893:
894: * File Framework:: Structural information for the assembler file.
895: * Data Output:: Output of constants (numbers, strings, addresses).
896: * Uninitialized Data:: Output of uninitialized variables.
897: * Label Output:: Output and generation of labels.
898: * Constructor Output:: Output of initialization and termination routines.
899: * Instruction Output:: Output of actual instructions.
900: * Dispatch Tables:: Output of jump tables.
901: * Alignment Output:: Pseudo ops for alignment and skipping data.
902:
903:
904: File: gcc.info, Node: File Framework, Next: Data Output, Prev: Assembler Format, Up: Assembler Format
905:
906: The Overall Framework of an Assembler File
907: ------------------------------------------
908:
909: `ASM_FILE_START (STREAM)'
910: A C expression which outputs to the stdio stream STREAM some
911: appropriate text to go at the start of an assembler file.
912:
913: Normally this macro is defined to output a line containing
914: `#NO_APP', which is a comment that has no effect on most
915: assemblers but tells the GNU assembler that it can save time by
916: not checking for certain assembler constructs.
917:
918: On systems that use SDB, it is necessary to output certain
919: commands; see `attasm.h'.
920:
921: `ASM_FILE_END (STREAM)'
922: A C expression which outputs to the stdio stream STREAM some
923: appropriate text to go at the end of an assembler file.
924:
925: If this macro is not defined, the default is to output nothing
926: special at the end of the file. Most systems don't require any
927: definition.
928:
929: On systems that use SDB, it is necessary to output certain
930: commands; see `attasm.h'.
931:
932: `ASM_IDENTIFY_GCC (FILE)'
933: A C statement to output assembler commands which will identify
934: the object file as having been compiled with GNU CC (or another
935: GNU compiler).
936:
937: If you don't define this macro, the string `gcc_compiled.:' is
938: output. This string is calculated to define a symbol which, on
939: BSD systems, will never be defined for any other reason. GDB
940: checks for the presence of this symbol when reading the symbol
941: table of an executable.
942:
943: On non-BSD systems, you must arrange communication with GDB in
944: some other fashion. If GDB is not used on your system, you can
945: define this macro with an empty body.
946:
947: `ASM_COMMENT_START'
948: A C string constant describing how to begin a comment in the
949: target assembler language. The compiler assumes that the comment
950: will end at the end of the line.
951:
952: `ASM_APP_ON'
953: A C string constant for text to be output before each `asm'
954: statement or group of consecutive ones. Normally this is
955: `"#APP"', which is a comment that has no effect on most
956: assemblers but tells the GNU assembler that it must check the
957: lines that follow for all valid assembler constructs.
958:
959: `ASM_APP_OFF'
960: A C string constant for text to be output after each `asm'
961: statement or group of consecutive ones. Normally this is
962: `"#NO_APP"', which tells the GNU assembler to resume making the
963: time-saving assumptions that are valid for ordinary compiler
964: output.
965:
966: `ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)'
967: A C statement to output COFF information or DWARF debugging
968: information which indicates that filename NAME is the current
969: source file to the stdio stream STREAM.
970:
971: This macro need not be defined if the standard form of output for
972: the file format in use is appropriate.
973:
974: `ASM_OUTPUT_SOURCE_LINE (STREAM, LINE)'
975: A C statement to output DBX or SDB debugging information before
976: code for line number LINE of the current source file to the stdio
977: stream STREAM.
978:
979: This macro need not be defined if the standard form of debugging
980: information for the debugger in use is appropriate.
981:
982: `ASM_OUTPUT_IDENT (STREAM, STRING)'
983: A C statement to output something to the assembler file to handle
984: a `#ident' directive containing the text STRING. If this macro
985: is not defined, nothing is output for a `#ident' directive.
986:
987: `OBJC_PROLOGUE'
988: A C statement to output any assembler statements which are
989: required to precede any Objective C object definitions or message
990: sending. The statement is executed only when compiling an
991: Objective C program.
992:
993:
994: File: gcc.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format
995:
996: Output of Data
997: --------------
998:
999: `ASM_OUTPUT_LONG_DOUBLE (STREAM, VALUE)'
1000: `ASM_OUTPUT_DOUBLE (STREAM, VALUE)'
1001: `ASM_OUTPUT_FLOAT (STREAM, VALUE)'
1002: A C statement to output to the stdio stream STREAM an assembler
1003: instruction to assemble a floating-point constant of `TFmode',
1004: `DFmode' or `SFmode', respectively, whose value is VALUE. VALUE
1005: will be a C expression of type `REAL_VALUE__TYPE', usually
1006: `double'.
1007:
1008: `ASM_OUTPUT_QUADRUPLE_INT (STREAM, EXP)'
1009: `ASM_OUTPUT_DOUBLE_INT (STREAM, EXP)'
1010: `ASM_OUTPUT_INT (STREAM, EXP)'
1011: `ASM_OUTPUT_SHORT (STREAM, EXP)'
1012: `ASM_OUTPUT_CHAR (STREAM, EXP)'
1013: A C statement to output to the stdio stream STREAM an assembler
1014: instruction to assemble an integer of 16, 8, 4, 2 or 1 bytes,
1015: respectively, whose value is VALUE. The argument EXP will be an
1016: RTL expression which represents a constant value. Use
1017: `output_addr_const (STREAM, EXP)' to output this value as an
1018: assembler expression.
1019:
1020: For sizes larger than `UNITS_PER_WORD', if the action of a macro
1021: would be identical to repeatedly calling the macro corresponding
1022: to a size of `UNITS_PER_WORD', once for each word, you need not
1023: define the macro.
1024:
1025: `ASM_OUTPUT_BYTE (STREAM, VALUE)'
1026: A C statement to output to the stdio stream STREAM an assembler
1027: instruction to assemble a single byte containing the number VALUE.
1028:
1029: `ASM_BYTE_OP'
1030: A C string constant giving the pseudo-op to use for a sequence of
1031: single-byte constants. If this macro is not defined, the default
1032: is `"byte"'.
1033:
1034: `ASM_OUTPUT_ASCII (STREAM, PTR, LEN)'
1035: A C statement to output to the stdio stream STREAM an assembler
1036: instruction to assemble a string constant containing the LEN
1037: bytes at PTR. PTR will be a C expression of type `char *' and
1038: LEN a C expression of type `int'.
1039:
1040: If the assembler has a `.ascii' pseudo-op as found in the
1041: Berkeley Unix assembler, do not define the macro
1042: `ASM_OUTPUT_ASCII'.
1043:
1044: `ASM_OUTPUT_POOL_PROLOGUE (FILE FUNNAME FUNDECL SIZE)'
1045: A C statement to output assembler commands to define the start of
1046: the constant pool for a function. FUNNAME is a string giving the
1047: name of the function. Should the return type of the function be
1048: required, it can be obtained via FUNDECL. SIZE is the size, in
1049: bytes, of the constant pool that will be written immediately
1050: after this call.
1051:
1052: If no constant-pool prefix is required, the usual case, this
1053: macro need not be defined.
1054:
1055: `ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, JUMPTO)'
1056: A C statement (with or without semicolon) to output a constant in
1057: the constant pool, if it needs special treatment. (This macro
1058: need not do anything for RTL expressions that can be output
1059: normally.)
1060:
1061: The argument FILE is the standard I/O stream to output the
1062: assembler code on. X is the RTL expression for the constant to
1063: output, and MODE is the machine mode (in case X is a
1064: `const_int'). ALIGN is the required alignment for the value X;
1065: you should output an assembler directive to force this much
1066: alignment.
1067:
1068: The argument LABELNO is a number to use in an internal label for
1069: the address of this pool entry. The definition of this macro is
1070: responsible for outputting the label definition at the proper
1071: place. Here is how to do this:
1072:
1073: ASM_OUTPUT_INTERNAL_LABEL (FILE, "LC", LABELNO);
1074:
1075: When you output a pool entry specially, you should end with a
1076: `goto' to the label JUMPTO. This will prevent the same pool
1077: entry from being output a second time in the usual manner.
1078:
1079: You need not define this macro if it would do nothing.
1080:
1081: `ASM_OPEN_PAREN'
1082: `ASM_CLOSE_PAREN'
1083: These macros are defined as C string constant, describing the
1084: syntax in the assembler for grouping arithmetic expressions. The
1085: following definitions are correct for most assemblers:
1086:
1087: #define ASM_OPEN_PAREN "("
1088: #define ASM_CLOSE_PAREN ")"
1089:
1090:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.