![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-9 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-9 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.2 ! root 6: Copyright (C) 1988, 1989, 1990 Free Software Foundation, Inc.
1.1 root 7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: 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
1.1.1.2 ! root 14: that the sections entitled "GNU General Public License" and "Protect
! 15: Your Freedom--Fight `Look And Feel'" are included exactly as in the
! 16: original, and provided that the entire resulting derived work is
! 17: distributed under the terms of a permission notice identical to this
! 18: one.
1.1 root 19:
20: Permission is granted to copy and distribute translations of this
21: manual into another language, under the above conditions for modified
1.1.1.2 ! root 22: versions, except that the sections entitled "GNU General Public
! 23: License" and "Protect Your Freedom--Fight `Look And Feel'" and this
! 24: permission notice may be included in translations approved by the
! 25: Free Software Foundation instead of in the original English.
1.1 root 26:
27:
28:
29: File: gcc.info, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros
30:
31: Describing Stack Layout
32: =======================
33:
34: `STACK_GROWS_DOWNWARD'
35: Define this macro if pushing a word onto the stack moves the
36: stack pointer to a smaller address.
37:
1.1.1.2 ! root 38: When we say, "define this macro if ...," it means that the
1.1 root 39: compiler checks this macro only with `#ifdef' so the precise
40: definition used does not matter.
41:
42: `FRAME_GROWS_DOWNWARD'
43: Define this macro if the addresses of local variable slots are
44: at negative offsets from the frame pointer.
45:
46: `STARTING_FRAME_OFFSET'
47: Offset from the frame pointer to the first local variable slot
48: to be allocated.
49:
50: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
51: subtracting the length of the first slot from
52: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
53: length of the first slot to the value `STARTING_FRAME_OFFSET'.
54:
55: `PUSH_ROUNDING (NPUSHED)'
56: A C expression that is the number of bytes actually pushed onto
57: the stack when an instruction attempts to push NPUSHED bytes.
58:
59: If the target machine does not have a push instruction, do not
60: define this macro. That directs GNU CC to use an alternate
61: strategy: to allocate the entire argument block and then store
62: the arguments into it.
63:
64: On some machines, the definition
65:
66: #define PUSH_ROUNDING(BYTES) (BYTES)
67:
68: will suffice. But on other machines, instructions that appear
69: to push one byte actually push two bytes in an attempt to
70: maintain alignment. Then the definition should be
71:
72: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
73:
74: `FIRST_PARM_OFFSET (FUNDECL)'
75: Offset from the argument pointer register to the first
76: argument's address. On some machines it may depend on the data
77: type of the function. (In the next version of GNU CC, the
78: argument will be changed to the function data type rather than
79: its declaration.)
80:
81: `FIRST_PARM_CALLER_OFFSET (FUNDECL)'
82: Define this macro on machines where register parameters have
83: shadow locations on the stack, at addresses below the nominal
84: parameter. This matters because certain arguments cannot be
85: passed on the stack. On these machines, such arguments must be
86: stored into the shadow locations.
87:
88: This macro should expand into a C expression whose value is the
89: offset of the first parameter's shadow location from the nominal
90: stack pointer value. (That value is itself computed by adding
91: the value of `STACK_POINTER_OFFSET' to the stack pointer
92: register.)
93:
94: `REG_PARM_STACK_SPACE'
95: Define this macro if functions should assume that stack space
96: has been allocated for arguments even when their values are
97: passed in registers.
98:
99: The actual allocation of such space would be done either by the
100: call instruction or by the function prologue, or by defining
1.1.1.2 ! root 101: `FIRST_PARM_CALLER_OFFSET'.
1.1 root 102:
103: `STACK_ARGS_ADJUST (SIZE)'
104: Define this macro if the machine requires padding on the stack
105: for certain function calls. This is padding on a
106: per-function-call basis, not padding for individual arguments.
107:
108: The argument SIZE will be a C variable of type `struct arg_data'
109: which contains two fields, an integer named `constant' and an
110: RTX named `var'. These together represent a size measured in
111: bytes which is the sum of the integer and the RTX. Most of the
112: time `var' is 0, which means that the size is simply the integer.
113:
114: The definition should be a C statement or compound statement
115: which alters the variable supplied in whatever way you wish.
116:
117: Note that the value you leave in the variable `size' will
118: ultimately be rounded up to a multiple of `STACK_BOUNDARY' bits.
119:
120: This macro is not fully implemented for machines which have push
121: instructions (i.e., on which `PUSH_ROUNDING' is defined).
122:
123: `RETURN_POPS_ARGS (FUNTYPE)'
124: A C expression that should be 1 if a function pops its own
125: arguments on returning, or 0 if the function pops no arguments
126: and the caller must therefore pop them all after the function
127: returns.
128:
129: FUNTYPE is a C variable whose value is a tree node that
130: describes the function in question. Normally it is a node of
131: type `FUNCTION_TYPE' that describes the data type of the function.
132: From this it is possible to obtain the data types of the value
133: and arguments (if known).
134:
135: When a call to a library function is being considered, FUNTYPE
136: will contain an identifier node for the library function. Thus,
137: if you need to distinguish among various library functions, you
1.1.1.2 ! root 138: can do so by their names. Note that "library function" in this
! 139: context means a function used to perform arithmetic, whose name
! 140: is known specially in the compiler and was not mentioned in the
! 141: C code being compiled.
1.1 root 142:
143: On the Vax, all functions always pop their arguments, so the
144: definition of this macro is 1. On the 68000, using the standard
145: calling convention, no functions pop their arguments, so the
146: value of the macro is always 0 in this case. But an alternative
147: calling convention is available in which functions that take a
148: fixed number of arguments pop them but other functions (such as
149: `printf') pop nothing (the caller pops all). When this
150: convention is in use, FUNTYPE is examined to determine whether a
151: function takes a fixed number of arguments.
152:
1.1.1.2 ! root 153: When this macro returns nonzero, the macro
! 154: `FRAME_POINTER_REQUIRED' must also return nonzero for proper
! 155: operation.
! 156:
1.1 root 157: `FUNCTION_VALUE (VALTYPE, FUNC)'
158: A C expression to create an RTX representing the place where a
159: function returns a value of data type VALTYPE. VALTYPE is a
160: tree node representing a data type. Write `TYPE_MODE (VALTYPE)'
161: to get the machine mode used to represent that type. On many
162: machines, only the mode is relevant. (Actually, on most
163: machines, scalar values are returned in the same place
164: regardless of mode).
165:
166: If the precise function being called is known, FUNC is a tree
167: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null
168: pointer. This makes it possible to use a different
169: value-returning convention for specific functions when all their
170: calls are known.
171:
172: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
1.1.1.2 ! root 173: Define this macro if the target machine has "register windows"
1.1 root 174: so that the register in which a function returns its value is
175: not the same as the one in which the caller sees the value.
176:
177: For such machines, `FUNCTION_VALUE' computes the register in
178: which the caller will see the value, and
179: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion
180: to tell the function where to put the value.
181:
182: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
183: serves both purposes.
184:
185: `RETURN_IN_MEMORY (TYPE)'
186: A C expression which can inhibit the returning of certain
187: function values in registers, based on the type of value. A
188: nonzero value says to return the function value in memory, just
189: as large structures are always returned. Here TYPE will be a C
190: expression of type `tree', representing the data type of the
191: value.
192:
193: Note that values of mode `BLKmode' are returned in memory
194: regardless of this macro. Also, the option
195: `-fpcc-struct-return' takes effect regardless of this macro. On
196: most systems, it is possible to leave the macro undefined; this
197: causes a default definition to be used, whose value is the
198: constant 0.
199:
200: `LIBCALL_VALUE (MODE)'
201: A C expression to create an RTX representing the place where a
202: library function returns a value of mode MODE. If the precise
203: function being called is known, FUNC is a tree node
204: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
205: This makes it possible to use a different value-returning
206: convention for specific functions when all their calls are known.
207:
1.1.1.2 ! root 208: Note that "library function" in this context means a compiler
1.1 root 209: support routine, used to perform arithmetic, whose name is known
210: specially by the compiler and was not mentioned in the C code
211: being compiled.
212:
213: `FUNCTION_VALUE_REGNO_P (REGNO)'
214: A C expression that is nonzero if REGNO is the number of a hard
215: register in which the values of called function may come back.
216:
217: A register whose use for returning values is limited to serving
218: as the second of a pair (for a value of type `double', say) need
219: not be recognized by this macro. So for most machines, this
220: definition suffices:
221:
222: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
223:
224: If the machine has register windows, so that the caller and the
225: called function use different registers for the return value,
226: this macro should recognize only the caller's register numbers.
227:
228: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
229: A C expression that controls whether a function argument is
230: passed in a register, and which register.
231:
232: The arguments are CUM, which summarizes all the previous
233: arguments; MODE, the machine mode of the argument; TYPE, the
234: data type of the argument as a tree node or 0 if that is not
235: known (which happens for C support library functions); and
236: NAMED, which is 1 for an ordinary argument and 0 for nameless
237: arguments that correspond to `...' in the called function's
238: prototype.
239:
240: The value of the expression should either be a `reg' RTX for the
241: hard register in which to pass the argument, or zero to pass the
242: argument on the stack.
243:
244: For the Vax and 68000, where normally all arguments are pushed,
245: zero suffices as a definition.
246:
247: The usual way to make the ANSI library `stdarg.h' work on a
248: machine where some arguments are usually passed in registers, is
249: to cause nameless arguments to be passed on the stack instead.
250: This is done by making `FUNCTION_ARG' return 0 whenever NAMED is
251: 0.
252:
253: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
1.1.1.2 ! root 254: Define this macro if the target machine has "register windows",
! 255: so that the register in which a function sees an arguments is
! 256: not necessarily the same as the one in which the caller passed
! 257: the argument.
1.1 root 258:
259: For such machines, `FUNCTION_ARG' computes the register in which
260: the caller passes the value, and `FUNCTION_INCOMING_ARG' should
261: be defined in a similar fashion to tell the function being
262: called where the arguments will arrive.
263:
264: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
265: both purposes.
266:
267: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
268: A C expression for the number of words, at the beginning of an
269: argument, must be put in registers. The value must be zero for
270: arguments that are passed entirely in registers or that are
271: entirely pushed on the stack.
272:
273: On some machines, certain arguments must be passed partially in
274: registers and partially in memory. On these machines, typically
275: the first N words of arguments are passed in registers, and the
276: rest on the stack. If a multi-word argument (a `double' or a
277: structure) crosses that boundary, its first few words must be
278: passed in registers and the rest must be pushed. This macro
279: tells the compiler when this occurs, and how many of the words
280: should go in registers.
281:
282: `FUNCTION_ARG' for these arguments should return the first
283: register to be used by the caller for this argument; likewise
284: `FUNCTION_INCOMING_ARG', for the called function.
285:
286: `CUMULATIVE_ARGS'
287: A C type for declaring a variable that is used as the first
288: argument of `FUNCTION_ARG' and other related values. For some
289: target machines, the type `int' suffices and can hold the number
290: of bytes of argument so far.
291:
292: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE)'
293: A C statement (sans semicolon) for initializing the variable CUM
294: for the state at the beginning of the argument list. The
295: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the
296: tree node for the data type of the function which will receive
297: the args, or 0 if the args are to a compiler support library
298: function.
299:
300: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
301: A C statement (sans semicolon) to update the summarizer variable
302: CUM to advance past an argument in the argument list. The
303: values MODE, TYPE and NAMED describe that argument. Once this
304: is done, the variable CUM is suitable for analyzing the
305: *following* argument with `FUNCTION_ARG', etc.
306:
307: `FUNCTION_ARG_REGNO_P (REGNO)'
308: A C expression that is nonzero if REGNO is the number of a hard
309: register in which function arguments are sometimes passed. This
310: does *not* include implicit arguments such as the static chain
311: and the structure-value address. On many machines, no registers
312: can be used for this purpose since all function arguments are
313: pushed on the stack.
314:
315: `FUNCTION_ARG_PADDING (MODE, SIZE)'
316: If defined, a C expression which determines whether, and in
317: which direction, to pad out an argument with extra space. The
318: value should be of type `enum direction': either `upward' to pad
319: above the argument, `downward' to pad below, or `none' to
320: inhibit padding.
321:
322: The argument SIZE is an RTX which describes the size of the
323: argument, in bytes. It should be used only if MODE is
324: `BLKmode'. Otherwise, SIZE is 0.
325:
326: This macro does not control the *amount* of padding; that is
327: always just enough to reach the next multiple of `PARM_BOUNDARY'.
328:
329: This macro has a default definition which is right for most
330: systems. For little-endian machines, the default is to pad
331: upward. For big-endian machines, the default is to pad downward
332: for an argument of constant size shorter than an `int', and
333: upward otherwise.
334:
335: `FUNCTION_PROLOGUE (FILE, SIZE)'
336: A C compound statement that outputs the assembler code for entry
337: to a function. The prologue is responsible for setting up the
338: stack frame, initializing the frame pointer register, saving
339: registers that must be saved, and allocating SIZE additional
340: bytes of storage for the local variables. SIZE is an integer.
341: FILE is a stdio stream to which the assembler code should be
342: output.
343:
344: The label for the beginning of the function need not be output
345: by this macro. That has already been done when the macro is run.
346:
347: To determine which registers to save, the macro can refer to the
348: array `regs_ever_live': element R is nonzero if hard register R
349: is used anywhere within the function. This implies the function
350: prologue should save register R, but not if it is one of the
351: call-used registers.
352:
353: On machines where functions may or may not have frame-pointers,
354: the function entry code must vary accordingly; it must set up
355: the frame pointer if one is wanted, and not otherwise. To
356: determine whether a frame pointer is in wanted, the macro can
357: refer to the variable `frame_pointer_needed'. The variable's
358: value will be 1 at run time in a function that needs a frame
359: pointer.
360:
1.1.1.2 ! root 361: On machines where an argument may be passed partly in registers
! 362: and partly in memory, this macro must examine the variable
1.1 root 363: `current_function_pretend_args_size', and allocate that many
364: bytes of uninitialized space on the stack just underneath the
365: first argument arriving on the stack. (This may not be at the
366: very end of the stack, if the calling sequence has pushed
367: anything else since pushing the stack arguments. But usually,
368: on such machines, nothing else has been pushed yet, because the
369: function prologue itself does all the pushing.)
370:
371: `FUNCTION_PROFILER (FILE, LABELNO)'
372: A C statement or compound statement to output to FILE some
373: assembler code to call the profiling subroutine `mcount'.
374: Before calling, the assembler code must load the address of a
375: counter variable into a register where `mcount' expects to find
376: the address. The name of this variable is `LP' followed by the
377: number LABELNO, so you would generate the name using `LP%d' in a
378: `fprintf'.
379:
380: The details of how the address should be passed to `mcount' are
381: determined by your operating system environment, not by GNU CC.
382: To figure them out, compile a small program for profiling using
383: the system's installed C compiler and look at the assembler code
384: that results.
385:
386: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)'
387: A C statement or compound statement to output to FILE some
388: assembler code to initialize basic-block profiling for the
389: current object module. This code should call the subroutine
390: `__bb_init_func' once per object module, passing it as its sole
391: argument the address of a block allocated in the object module.
392:
393: The name of the block is a local symbol made with this statement:
394:
395: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0);
396:
397: Of course, since you are writing the definition of
398: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
399: can take a short cut in the definition of this macro and use the
400: name that you know will result.
401:
402: The first word of this block is a flag which will be nonzero if
403: the object module has already been initialized. So test this
404: word first, and do not call `__bb_init_func' if the flag is
405: nonzero.
406:
407: `BLOCK_PROFILER (FILE, BLOCKNO)'
408: A C statement or compound statement to increment the count
409: associated with the basic block number BLOCKNO. Basic blocks
410: are numbered separately from zero within each compilation. The
411: count associated with block number BLOCKNO is at index BLOCKNO
412: in a vector of words; the name of this array is a local symbol
413: made with this statement:
414:
415: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2);
416:
417: Of course, since you are writing the definition of
418: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you
419: can take a short cut in the definition of this macro and use the
420: name that you know will result.
421:
1.1.1.2 ! root 422: `EXIT_IGNORE_STACK'
1.1 root 423: Define this macro as a C expression that is nonzero if the
424: return instruction or the function epilogue ignores the value of
425: the stack pointer; in other words, if it is safe to delete an
426: instruction to adjust the stack pointer before a return from the
427: function.
428:
429: Note that this macro's value is relevant only for functions for
430: which frame pointers are maintained. It is never safe to delete
431: a final stack adjustment in a function that has no frame
432: pointer, and the compiler knows this regardless of
1.1.1.2 ! root 433: `EXIT_IGNORE_STACK'.
1.1 root 434:
435: `FUNCTION_EPILOGUE (FILE, SIZE)'
436: A C compound statement that outputs the assembler code for exit
437: from a function. The epilogue is responsible for restoring the
438: saved registers and stack pointer to their values when the
439: function was called, and returning control to the caller. This
440: macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
441: and the registers to restore are determined from
442: `regs_ever_live' and `CALL_USED_REGISTERS' in the same way.
443:
444: On some machines, there is a single instruction that does all
445: the work of returning from the function. On these machines,
446: give that instruction the name `return' and do not define the
447: macro `FUNCTION_EPILOGUE' at all.
448:
449: Do not define a pattern named `return' if you want the
450: `FUNCTION_EPILOGUE' to be used. If you want the target switches
451: to control whether return instructions or epilogues are used,
452: define a `return' pattern with a validity condition that tests
453: the target switches appropriately. If the `return' pattern's
454: validity condition is false, epilogues will be used.
455:
456: On machines where functions may or may not have frame-pointers,
457: the function exit code must vary accordingly. Sometimes the
458: code for these two cases is completely different. To determine
459: whether a frame pointer is in wanted, the macro can refer to the
460: variable `frame_pointer_needed'. The variable's value will be 1
461: at run time in a function that needs a frame pointer.
462:
463: On some machines, some functions pop their arguments on exit
464: while others leave that for the caller to do. For example, the
465: 68020 when given `-mrtd' pops arguments in functions that take a
466: fixed number of arguments.
467:
468: Your definition of the macro `RETURN_POPS_ARGS' decides which
469: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
470: know what was decided. The variable
471: `current_function_pops_args' is nonzero if the function should
472: pop its own arguments. If so, use the variable
473: `current_function_args_size' as the number of bytes to pop.
474:
475: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
476: A C compound statement to alter a memory address that uses the
477: frame pointer register so that it uses the stack pointer
478: register instead. This must be done in the instructions that
479: load parameter values into registers, when the reload pass
480: determines that a frame pointer is not necessary for the
481: function. ADDR will be a C variable name, and the updated
482: address should be stored in that variable. DEPTH will be the
483: current depth of stack temporaries (number of bytes of arguments
484: currently pushed). The change in offset between a
485: frame-pointer-relative address and a stack-pointer-relative
486: address must include DEPTH.
487:
488: Even if your machine description specifies there will always be
489: a frame pointer in the frame pointer register, you must still
490: define `FIX_FRAME_POINTER_ADDRESS', but the definition will
491: never be executed at run time, so it may be empty.
492:
493: `LONGJMP_RESTORE_FROM_STACK'
494: Define this macro if the `longjmp' function restores registers
495: from the stack frames, rather than from those saved specifically
496: by `setjmp'. Certain quantities must not be kept in registers
497: across a call to `setjmp' on such machines.
498:
499:
500:
501: File: gcc.info, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
502:
503: Library Subroutine Names
504: ========================
505:
506: `MULSI3_LIBCALL'
507: A C string constant giving the name of the function to call for
508: multiplication of one signed full-word by another. If you do
509: not define this macro, the default name is used, which is
510: `__mulsi3', a function defined in `gnulib'.
511:
512: `UMULSI3_LIBCALL'
513: A C string constant giving the name of the function to call for
514: multiplication of one unsigned full-word by another. If you do
515: not define this macro, the default name is used, which is
516: `__umulsi3', a function defined in `gnulib'.
517:
518: `DIVSI3_LIBCALL'
519: A C string constant giving the name of the function to call for
520: division of one signed full-word by another. If you do not
521: define this macro, the default name is used, which is
522: `__divsi3', a function defined in `gnulib'.
523:
524: `UDIVSI3_LIBCALL'
525: A C string constant giving the name of the function to call for
526: division of one unsigned full-word by another. If you do not
527: define this macro, the default name is used, which is
528: `__udivsi3', a function defined in `gnulib'.
529:
530: `MODSI3_LIBCALL'
531: A C string constant giving the name of the function to call for
532: the remainder in division of one signed full-word by another.
533: If you do not define this macro, the default name is used, which
534: is `__modsi3', a function defined in `gnulib'.
535:
536: `UMODSI3_LIBCALL'
537: A C string constant giving the name of the function to call for
538: the remainder in division of one unsigned full-word by another.
539: If you do not define this macro, the default name is used, which
540: is `__umodsi3', a function defined in `gnulib'.
541:
542: `TARGET_MEM_FUNCTIONS'
543: Define this macro if GNU CC should generate calls to the System
544: V (and ANSI C) library functions `memcpy' and `memset' rather
545: than the BSD functions `bcopy' and `bzero'.
546:
547:
548:
549: File: gcc.info, Node: Addressing Modes, Next: Delayed Branch, Prev: Library Names, Up: Machine Macros
550:
551: Addressing Modes
552: ================
553:
554: `HAVE_POST_INCREMENT'
555: Define this macro if the machine supports post-increment
556: addressing.
557:
558: `HAVE_PRE_INCREMENT'
559: `HAVE_POST_DECREMENT'
560: `HAVE_PRE_DECREMENT'
561: Similar for other kinds of addressing.
562:
563: `CONSTANT_ADDRESS_P (X)'
564: A C expression that is 1 if the RTX X is a constant whose value
565: is an integer. This includes integers whose values are not
566: explicitly known, such as `symbol_ref' and `label_ref'
567: expressions and `const' arithmetic expressions.
568:
569: On most machines, this can be defined as `CONSTANT_P (X)', but a
570: few machines are more restrictive in which constant addresses
571: are supported.
572:
573: `MAX_REGS_PER_ADDRESS'
574: A number, the maximum number of registers that can appear in a
1.1.1.2 ! root 575: valid memory address. Note that it is up to you to specify a
! 576: value equal to the maximum number that
! 577: `go_if_legitimate_address' would ever accept.
1.1 root 578:
579: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
580: A C compound statement with a conditional `goto LABEL;' executed
581: if X (an RTX) is a legitimate memory address on the target
582: machine for a memory operand of mode MODE.
583:
584: It usually pays to define several simpler macros to serve as
585: subroutines for this one. Otherwise it may be too complicated
586: to understand.
587:
588: This macro must exist in two variants: a strict variant and a
589: non-strict one. The strict variant is used in the reload pass.
590: It must be defined so that any pseudo-register that has not been
591: allocated a hard register is considered a memory reference. In
592: contexts where some kind of register is required, a
593: pseudo-register with no hard register must be rejected.
594:
595: The non-strict variant is used in other passes. It must be
596: defined to accept all pseudo-registers in every context where
597: some kind of register is required.
598:
599: Compiler source files that want to use the strict variant of
600: this macro define the macro `REG_OK_STRICT'. You should use an
601: `#ifdef REG_OK_STRICT' conditional to define the strict variant
602: in that case and the non-strict variant otherwise.
603:
604: Typically among the subroutines used to define
605: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for
606: acceptable registers for various purposes (one for base
607: registers, one for index registers, and so on). Then only these
608: subroutine macros need have two variants; the higher levels of
609: macros may be the same whether strict or not.
610:
611: Normally, constant addresses which are the sum of a `symbol_ref'
612: and an integer are stored inside a `const' RTX to mark them as
613: constant. Therefore, there is no need to recognize such sums as
614: legitimate addresses.
615:
616: Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle
617: constant sums that are not marked with `const'. It assumes
618: that a naked `plus' indicates indexing. If so, then you *must*
619: reject such naked constant sums as illegitimate addresses, so
620: that none of them will be given to `PRINT_OPERAND_ADDRESS'.
621:
622: `REG_OK_FOR_BASE_P (X)'
623: A C expression that is nonzero if X (assumed to be a `reg' RTX)
624: is valid for use as a base register. For hard registers, it
625: should always accept those which the hardware permits and reject
626: the others. Whether the macro accepts or rejects pseudo
627: registers must be controlled by `REG_OK_STRICT' as described
628: above. This usually requires two variant definitions, of which
629: `REG_OK_STRICT' controls the one actually used.
630:
631: `REG_OK_FOR_INDEX_P (X)'
632: A C expression that is nonzero if X (assumed to be a `reg' RTX)
633: is valid for use as an index register.
634:
635: The difference between an index register and a base register is
636: that the index register may be scaled. If an address involves
637: the sum of two registers, neither one of them scaled, then
1.1.1.2 ! root 638: either one may be labeled the "base" and the other the "index";
! 639: but whichever labeling is used must fit the machine's
1.1 root 640: constraints of which registers may serve in each capacity. The
641: compiler will try both labelings, looking for one that is valid,
642: and will reload one or both registers only if neither labeling
643: works.
644:
645: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
646: A C compound statement that attempts to replace X with a valid
647: memory address for an operand of mode MODE. WIN will be a C
648: statement label elsewhere in the code; the macro definition may
649: use
650:
651: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
652:
653: to avoid further processing if the address has become legitimate.
654:
655: X will always be the result of a call to
656: `break_out_memory_refs', and OLDX will be the operand that was
657: given to that function to produce X.
658:
659: The code generated by this macro should not alter the
660: substructure of X. If it transforms X into a more legitimate
661: form, it should assign X (which will always be a C variable) a
662: new value.
663:
664: It is not necessary for this macro to come up with a legitimate
665: address. The compiler has standard ways of doing so in all
666: cases. In fact, it is safe for this macro to do nothing. But
667: often a machine-dependent strategy can generate better code.
668:
669: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
670: A C statement or compound statement with a conditional `goto
671: LABEL;' executed if memory address X (an RTX) can have different
672: meanings depending on the machine mode of the memory reference
673: it is used for.
674:
675: Autoincrement and autodecrement addresses typically have
676: mode-dependent effects because the amount of the increment or
677: decrement is the size of the operand being addressed. Some
678: machines have other mode-dependent addresses. Many RISC
679: machines have no mode-dependent addresses.
680:
681: You may assume that ADDR is a valid address for the machine.
682:
683: `LEGITIMATE_CONSTANT_P (X)'
684: A C expression that is nonzero if X is a legitimate constant for
685: an immediate operand on the target machine. You can assume that
686: either X is a `const_double' or it satisfies `CONSTANT_P', so
687: you need not check these things. In fact, `1' is a suitable
688: definition for this macro on machines where any `const_double'
689: is valid and anything `CONSTANT_P' is valid.
690:
691:
692:
693: File: gcc.info, Node: Delayed Branch, Next: Condition Code, Prev: Addressing Modes, Up: Machine Macros
694:
695: Parameters for Delayed Branch Optimization
696: ==========================================
697:
698: `HAVE_DELAYED_BRANCH'
699: Define this macro if the target machine has delayed branches,
700: that is, a branch does not take effect immediately, and the
701: actual branch instruction may be followed by one or more
702: instructions that will be issued before the PC is actually
703: changed.
704:
705: If defined, this allows a special scheduling pass to be run
706: after the second jump optimization to attempt to reorder
707: instructions to exploit this. Defining this macro also requires
708: the definition of certain other macros described below.
709:
710: `DBR_SLOTS_AFTER (INSN)'
711: This macro must be defined if `HAVE_DELAYED_BRANCH' is defined.
712: Its definition should be a C expression returning the number of
713: available delay slots following the instruction(s) output by the
1.1.1.2 ! root 714: pattern for INSN. The definition of "slot" is
1.1 root 715: machine-dependent, and may denote instructions, bytes, or
716: whatever.
717:
718: `DBR_INSN_SLOTS (INSN)'
719: This macro must be defined if `HAVE_DELAYED_BRANCH' is defined.
720: It should be a C expression returning the number of slots
721: (typically the number of machine instructions) consumed by INSN.
722:
723: You may assume that INSN is truly an insn, not a note, label,
724: barrier, dispatch table, `use', or `clobber'.
725:
726: `DBR_INSN_ELIGIBLE_P (INSN, DINSN)'
727: A C expression whose value is non-zero if it is legitimate to
728: put INSN in the delay slot following DINSN.
729:
730: You do not need to take account of data flow considerations in
731: the definition of this macro, because the delayed branch
732: optimizer always does that. This macro is needed only when
733: certain insns may not be placed in certain delay slots for
734: reasons not evident from the RTL expressions themselves. If
735: there are no such problems, you don't need to define this macro.
736:
737: You may assume that INSN is truly an insn, not a note, label,
738: barrier, dispatch table, `use', or `clobber'. You may assume
739: that DINSN is a jump insn with a delay slot.
740:
741: `DBR_OUTPUT_SEQEND(FILE)'
742: A C statement, to be executed after all slot-filler instructions
743: have been output. If necessary, call `dbr_sequence_length' to
744: determine the number of slots filled in a sequence (zero if not
745: currently outputting a sequence), to decide how many no-ops to
746: output, or whatever.
747:
748: Don't define this macro if it has nothing to do, but it is
749: helpful in reading assembly output if the extent of the delay
750: sequence is made explicit (e.g. with white space).
751:
752: Note that output routines for instructions with delay slots must
753: be prepared to deal with not being output as part of a sequence
754: (i.e. when the scheduling pass is not run, or when no slot
755: fillers could be found.) The variable `final_sequence' is null
756: when not processing a sequence, otherwise it contains the
757: `sequence' rtx being output.
758:
759:
760:
761: File: gcc.info, Node: Condition Code, Next: Cross-compilation, Prev: Delayed Branch, Up: Machine Macros
762:
763: Condition Code Information
764: ==========================
765:
766: The file `conditions.h' defines a variable `cc_status' to describe
767: how the condition code was computed (in case the interpretation of
768: the condition code depends on the instruction that it was set by).
769: This variable contains the RTL expressions on which the condition
770: code is currently based, and several standard flags.
771:
772: Sometimes additional machine-specific flags must be defined in the
773: machine description header file. It can also add additional
774: machine-specific information by defining `CC_STATUS_MDEP'.
775:
776: `CC_STATUS_MDEP'
777: C code for a data type which is used for declaring the `mdep'
778: component of `cc_status'. It defaults to `int'.
779:
780: `CC_STATUS_MDEP_INIT'
1.1.1.2 ! root 781: A C expression to initialize the `mdep' field to "empty". The
1.1 root 782: default definition does nothing, since most machines don't use
783: the field anyway. If you want to use the field, you should
784: probably define this macro to initialize it.
785:
786: `NOTICE_UPDATE_CC (EXP, INSN)'
787: A C compound statement to set the components of `cc_status'
788: appropriately for an insn INSN whose body is EXP. It is this
789: macro's responsibility to recognize insns that set the condition
790: code as a byproduct of other activity as well as those that
791: explicitly set `(cc0)'.
792:
793: If there are insn that do not set the condition code but do
794: alter other machine registers, this macro must check to see
795: whether they invalidate the expressions that the condition code
796: is recorded as reflecting. For example, on the 68000, insns
797: that store in address registers do not set the condition code,
798: which means that usually `NOTICE_UPDATE_CC' can leave
799: `cc_status' unaltered for such insns. But suppose that the
800: previous insn set the condition code based on location
801: `a4@(102)' and the current insn stores a new value in `a4'.
802: Although the condition code is not changed by this, it will no
803: longer be true that it reflects the contents of `a4@(102)'.
804: Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this
805: case to say that nothing is known about the condition code value.
806:
807: The definition of `NOTICE_UPDATE_CC' must be prepared to deal
808: with the results of peephole optimization: insns whose patterns
809: are `parallel' RTXs containing various `reg', `mem' or constants
810: which are just the operands. The RTL structure of these insns
811: is not sufficient to indicate what the insns actually do. What
812: `NOTICE_UPDATE_CC' should do when it sees one is just to run
813: `CC_STATUS_INIT'.
814:
815:
816:
817: File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Condition Code, Up: Machine Macros
818:
819: Cross Compilation and Floating-Point Format
820: ===========================================
821:
822: While all modern machines use 2's complement representation for
823: integers, there are a variety of representations for floating point
824: numbers. This means that in a cross-compiler the representation of
825: floating point numbers in the compiled program may be different from
826: that used in the machine doing the compilation.
827:
828: Because different representation systems may offer different amounts
829: of range and precision, the cross compiler cannot safely use the host
830: machine's floating point arithmetic. Therefore, floating point
831: constants must be represented in the target machine's format. This
832: means that the cross compiler cannot use `atof' to parse a floating
833: point constant; it must have its own special routine to use instead.
834: Also, constant folding must emulate the target machine's arithmetic
835: (or must not be done at all).
836:
837: The macros in the following table should be defined only if you are
838: cross compiling between different floating point formats.
839:
840: Otherwise, don't define them. Then default definitions will be set up
841: which use `double' as the data type, `==' to test for equality, etc.
842:
843: You don't need to worry about how many times you use an operand of
844: any of these macros. The compiler never uses operands which have
845: side effects.
846:
847: `REAL_VALUE_TYPE'
848: A macro for the C data type to be used to hold a floating point
849: value in the target machine's format. Typically this would be a
850: `struct' containing an array of `int'.
851:
852: `REAL_VALUES_EQUAL (X, Y)'
853: A macro for a C expression which compares for equality the two
854: values, X and Y, both of type `REAL_VALUE_TYPE'.
855:
856: `REAL_VALUES_LESS (X, Y)'
857: A macro for a C expression which tests whether X is less than Y,
858: both values being of type `REAL_VALUE_TYPE' and interpreted as
859: floating point numbers in the target machine's representation.
860:
861: `REAL_VALUE_LDEXP (X, SCALE)'
862: A macro for a C expression which performs the standard library
863: function `ldexp', but using the target machine's floating point
864: representation. Both X and the value of the expression have
865: type `REAL_VALUE_TYPE'. The second argument, SCALE, is an
866: integer.
867:
868: `REAL_VALUE_ATOF (STRING)'
869: A macro for a C expression which converts STRING, an expression
870: of type `char *', into a floating point number in the target
871: machine's representation. The value has type `REAL_VALUE_TYPE'.
872:
873: Define the following additional macros if you want to make floating
874: point constant folding work while cross compiling. If you don't
875: define them, cross compilation is still possible, but constant
876: folding will not happen for floating point values.
877:
878: `REAL_ARITHMETIC (OUTPUT, CODE, X, Y)'
879: A macro for a C statement which calculates an arithmetic
880: operation of the two floating point values X and Y, both of type
881: `REAL_VALUE_TYPE' in the target machine's representation, to
882: produce a result of the same type and representation which is
883: stored in OUTPUT (which will be a variable).
884:
885: The operation to be performed is specified by CODE, a tree code
886: which will always be one of the following: `PLUS_EXPR',
887: `MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
888:
889: The expansion of this macro is responsible for checking for
890: overflow. If overflow happens, the macro expansion should
891: execute the statement `return 0;', which indicates the inability
892: to perform the arithmetic operation requested.
893:
894: `REAL_VALUE_NEGATE (X)'
895: A macro for a C expression which returns the negative of the
896: floating point value X. Both X and the value of the expression
897: have type `REAL_VALUE_TYPE' and are in the target machine's
898: floating point representation.
899:
900: There is no way for this macro to report overflow, since
901: overflow can't happen in the negation operation.
902:
903: `REAL_VALUE_TO_INT (LOW, HIGH, X)'
904: A macro for a C expression which converts a floating point value
905: X into a double-precision integer which is then stored into LOW
906: and HIGH, two variables of type INT.
907:
908: `REAL_VALUE_FROM_INT (X, LOW, HIGH)'
909: A macro for a C expression which converts a double-precision
910: integer found in LOW and HIGH, two variables of type INT, into a
911: floating point value which is then stored into X.
912:
913:
914:
915: File: gcc.info, Node: Misc, Next: Assembler Format, Prev: Cross-compilation, Up: Machine Macros
916:
917: Miscellaneous Parameters
918: ========================
919:
920: `CASE_VECTOR_MODE'
921: An alias for a machine mode name. This is the machine mode that
922: elements of a jump-table should have.
923:
924: `CASE_VECTOR_PC_RELATIVE'
925: Define this macro if jump-tables should contain relative
926: addresses.
927:
928: `CASE_DROPS_THROUGH'
929: Define this if control falls through a `case' insn when the
930: index value is out of range. This means the specified
931: default-label is actually ignored by the `case' insn proper.
932:
933: `IMPLICIT_FIX_EXPR'
934: An alias for a tree code that should be used by default for
935: conversion of floating point values to fixed point. Normally,
936: `FIX_ROUND_EXPR' is used.
937:
938: `FIXUNS_TRUNC_LIKE_FIX_TRUNC'
939: Define this macro if the same instructions that convert a
940: floating point number to a signed fixed point number also
941: convert validly to an unsigned one.
942:
943: `EASY_DIV_EXPR'
944: An alias for a tree code that is the easiest kind of division to
945: compile code for in the general case. It may be
946: `TRUNC_DIV_EXPR', `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or
947: `ROUND_DIV_EXPR'. These four division operators differ in how
948: they round the result to an integer. `EASY_DIV_EXPR' is used
949: when it is permissible to use any of those kinds of division and
950: the choice should be made on the basis of efficiency.
951:
952: `DEFAULT_SIGNED_CHAR'
953: An expression whose value is 1 or 0, according to whether the
954: type `char' should be signed or unsigned by default. The user
955: can always override this default with the options
956: `-fsigned-char' and `-funsigned-char'.
957:
958: `SCCS_DIRECTIVE'
959: Define this if the preprocessor should ignore `#sccs' directives
960: and print no error message.
961:
962: `HAVE_VPRINTF'
963: Define this if the library function `vprintf' is available on
964: your system.
965:
966: `MOVE_MAX'
967: The maximum number of bytes that a single instruction can move
968: quickly from memory to memory.
969:
970: `INT_TYPE_SIZE'
971: A C expression for the size in bits of the type `int' on the
972: target machine. If you don't define this, the default is one
973: word.
974:
975: `SHORT_TYPE_SIZE'
976: A C expression for the size in bits of the type `short' on the
977: target machine. If you don't define this, the default is half a
978: word. (If this would be less than one storage unit, it is
979: rounded up to one unit.)
980:
981: `LONG_TYPE_SIZE'
982: A C expression for the size in bits of the type `long' on the
983: target machine. If you don't define this, the default is one
984: word.
985:
986: `LONG_LONG_TYPE_SIZE'
987: A C expression for the size in bits of the type `long long' on
988: the target machine. If you don't define this, the default is
989: two words.
990:
991: `CHAR_TYPE_SIZE'
992: A C expression for the size in bits of the type `char' on the
993: target machine. If you don't define this, the default is one
994: quarter of a word. (If this would be less than one storage
995: unit, it is rounded up to one unit.)
996:
997: `FLOAT_TYPE_SIZE'
998: A C expression for the size in bits of the type `float' on the
999: target machine. If you don't define this, the default is one
1000: word.
1001:
1002: `DOUBLE_TYPE_SIZE'
1003: A C expression for the size in bits of the type `double' on the
1004: target machine. If you don't define this, the default is two
1005: words.
1006:
1007: `LONG_DOUBLE_TYPE_SIZE'
1008: A C expression for the size in bits of the type `long double' on
1009: the target machine. If you don't define this, the default is
1010: two words.
1011:
1012: `SLOW_BYTE_ACCESS'
1013: Define this macro as a C expression which is nonzero if
1014: accessing less than a word of memory (i.e. a `char' or a
1015: `short') is slow (requires more than one instruction).
1016:
1017: `SLOW_ZERO_EXTEND'
1018: Define this macro if zero-extension (of a `char' or `short' to
1019: an `int') can be done faster if the destination is a register
1020: that is known to be zero.
1021:
1022: If you define this macro, you must have instruction patterns
1023: that recognize RTL structures like this:
1024:
1025: (set (strict-low-part (subreg:QI (reg:SI ...) 0)) ...)
1026:
1027: and likewise for `HImode'.
1028:
1029: `SHIFT_COUNT_TRUNCATED'
1030: Define this macro if shift instructions ignore all but the
1031: lowest few bits of the shift count. It implies that a
1032: sign-extend or zero-extend instruction for the shift count can
1033: be omitted.
1034:
1035: `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
1036: A C expression which is nonzero if on this machine it is safe to
1.1.1.2 ! root 1037: "convert" an integer of INPREC bits to one of OUTPREC bits
1.1 root 1038: (where OUTPREC is smaller than INPREC) by merely operating on it
1039: as if it had only OUTPREC bits.
1040:
1041: On many machines, this expression can be 1.
1042:
1043: `NO_FUNCTION_CSE'
1044: Define this macro if it is as good or better to call a constant
1045: function address than to call an address kept in a register.
1046:
1047: `PROMOTE_PROTOTYPES'
1048: Define this macro if an argument declared as `char' or `short'
1049: in a prototype should actually be passed as an `int'. In
1050: addition to avoiding errors in certain cases of mismatch, it
1051: also makes for better code on certain machines.
1052:
1053: `STORE_FLAG_VALUE'
1054: A C expression for the value stored by a store-flag instruction
1055: (`sCOND') when the condition is true. This is usually 1 or -1;
1056: it is required to be an odd number or a negative number.
1057:
1058: Do not define `STORE_FLAG_VALUE' if the machine has no
1059: store-flag instructions.
1060:
1061: `Pmode'
1062: An alias for the machine mode for pointers. Normally the
1063: definition can be
1064:
1065: #define Pmode SImode
1066:
1067: `FUNCTION_MODE'
1068: An alias for the machine mode used for memory references to
1069: functions being called, in `call' RTL expressions. On most
1070: machines this should be `QImode'.
1071:
1072: `INSN_MACHINE_INFO'
1073: This macro should expand into a C structure type to use for the
1074: machine-dependent info field specified with the optional last
1075: argument in `define_insn' and `define_peephole' patterns. For
1076: example, it might expand into `struct machine_info'; then it
1077: would be up to you to define this structure in the `tm.h' file.
1078:
1079: You do not need to define this macro if you do not write the
1080: optional last argument in any of the patterns in the machine
1081: description.
1082:
1083: `DEFAULT_MACHINE_INFO'
1084: This macro should expand into a C initializer to use to
1085: initialize the machine-dependent info for one insn pattern. It
1086: is used for patterns that do not specify the machine-dependent
1087: info.
1088:
1089: If you do not define this macro, zero is used.
1090:
1091: `CONST_COSTS (X, CODE)'
1092: A part of a C `switch' statement that describes the relative
1093: costs of constant RTL expressions. It must contain `case'
1094: labels for expression codes `const_int', `const', `symbol_ref',
1095: `label_ref' and `const_double'. Each case must ultimately reach
1096: a `return' statement to return the relative cost of the use of
1097: that kind of constant value in an expression. The cost may
1098: depend on the precise value of the constant, which is available
1099: for examination in X.
1100:
1101: CODE is the expression code--redundant, since it can be obtained
1102: with `GET_CODE (X)'.
1103:
1104: `DOLLARS_IN_IDENTIFIERS'
1105: Define this to be nonzero if the character `$' should be allowed
1106: by default in identifier names.
1107:
1108:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.