![[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.1.2 ! root 1: This is Info file gcc.info, produced by Makeinfo-1.44 from the input 1.1 root 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: 1.1.1.2 ! root 27: File: gcc.info, Node: Function Entry, Next: Profiling, Prev: Caller Saves, Up: Stack and Calling ! 28: ! 29: Function Entry and Exit ! 30: ----------------------- ! 31: ! 32: This section describes the macros that output function entry ! 33: ("prologue") and exit ("epilogue") code. ! 34: ! 35: `FUNCTION_PROLOGUE (FILE, SIZE)' ! 36: A C compound statement that outputs the assembler code for entry ! 37: to a function. The prologue is responsible for setting up the ! 38: stack frame, initializing the frame pointer register, saving ! 39: registers that must be saved, and allocating SIZE additional ! 40: bytes of storage for the local variables. SIZE is an integer. ! 41: FILE is a stdio stream to which the assembler code should be ! 42: output. ! 43: ! 44: The label for the beginning of the function need not be output by ! 45: this macro. That has already been done when the macro is run. ! 46: ! 47: To determine which registers to save, the macro can refer to the ! 48: array `regs_ever_live': element R is nonzero if hard register R ! 49: is used anywhere within the function. This implies the function ! 50: prologue should save register R, provided it is not one of the ! 51: call-used registers. (`FUNCTION_EPILOGUE' must likewise use ! 52: `regs_ever_live'.) ! 53: ! 54: On machines that have "register windows", the function entry code ! 55: does not save on the stack the registers that are in the windows, ! 56: even if they are supposed to be preserved by function calls; ! 57: instead it takes appropriate steps to "push" the register stack, ! 58: if any non-call-used registers are used in the function. ! 59: ! 60: On machines where functions may or may not have frame-pointers, ! 61: the function entry code must vary accordingly; it must set up the ! 62: frame pointer if one is wanted, and not otherwise. To determine ! 63: whether a frame pointer is in wanted, the macro can refer to the ! 64: variable `frame_pointer_needed'. The variable's value will be 1 ! 65: at run time in a function that needs a frame pointer. *Note ! 66: Elimination::. ! 67: ! 68: The function entry code is responsible for allocating any stack ! 69: space required for the function. This stack space consists of ! 70: the regions listed below. In most cases, these regions are ! 71: allocated in the order listed, with the last listed region ! 72: closest to the top of the stack (the lowest address if ! 73: `STACK_GROWS_DOWNWARD' is defined, and the highest address if it ! 74: is not defined). You can use a different order for a machine if ! 75: doing so is more convenient or required for compatibility ! 76: reasons. Except in cases where required by standard or by a ! 77: debugger, there is no reason why the stack layout used by GCC ! 78: need agree with that used by other compilers for a machine. ! 79: ! 80: * A region of `current_function_pretend_args_size' bytes of ! 81: uninitialized space just underneath the first argument ! 82: arriving on the stack. (This may not be at the very start ! 83: of the allocated stack region if the calling sequence has ! 84: pushed anything else since pushing the stack arguments. But ! 85: usually, on such machines, nothing else has been pushed yet, ! 86: because the function prologue itself does all the pushing.) ! 87: This region is used on machines where an argument may be ! 88: passed partly in registers and partly in memory, and, in ! 89: some cases to support the features in `varargs.h' and ! 90: `stdargs.h'. ! 91: ! 92: * An area of memory used to save certain registers used by the ! 93: function. The size of this area, which may also include ! 94: space for such things as the return address and pointers to ! 95: previous stack frames, is machine-specific and usually ! 96: depends on which registers have been used in the function. ! 97: Machines with register windows often do not require a save ! 98: area. ! 99: ! 100: * A region of at least SIZE bytes, possibly rounded up to an ! 101: allocation boundary, to contain the local variables of the ! 102: function. On some machines, this region and the save area ! 103: may occur in the opposite order, with the save area closer ! 104: to the top of the stack. ! 105: ! 106: * Optionally, in the case that `ACCUMULATE_OUTGOING_ARGS' is ! 107: defined, a region of `current_function_outgoing_args_size' ! 108: bytes to be used for outgoing argument lists of the ! 109: function. *Note Stack Arguments::. ! 110: ! 111: Normally, it is necessary for `FUNCTION_PROLOGUE' and ! 112: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C ! 113: variable `leaf_function' is nonzero for such a function. ! 114: ! 115: `EXIT_IGNORE_STACK' ! 116: Define this macro as a C expression that is nonzero if the return ! 117: instruction or the function epilogue ignores the value of the ! 118: stack pointer; in other words, if it is safe to delete an ! 119: instruction to adjust the stack pointer before a return from the ! 120: function. ! 121: ! 122: Note that this macro's value is relevant only for functions for ! 123: which frame pointers are maintained. It is never safe to delete ! 124: a final stack adjustment in a function that has no frame pointer, ! 125: and the compiler knows this regardless of `EXIT_IGNORE_STACK'. ! 126: ! 127: `FUNCTION_EPILOGUE (FILE, SIZE)' ! 128: A C compound statement that outputs the assembler code for exit ! 129: from a function. The epilogue is responsible for restoring the ! 130: saved registers and stack pointer to their values when the ! 131: function was called, and returning control to the caller. This ! 132: macro takes the same arguments as the macro `FUNCTION_PROLOGUE', ! 133: and the registers to restore are determined from `regs_ever_live' ! 134: and `CALL_USED_REGISTERS' in the same way. ! 135: ! 136: On some machines, there is a single instruction that does all the ! 137: work of returning from the function. On these machines, give that ! 138: instruction the name `return' and do not define the macro ! 139: `FUNCTION_EPILOGUE' at all. ! 140: ! 141: Do not define a pattern named `return' if you want the ! 142: `FUNCTION_EPILOGUE' to be used. If you want the target switches ! 143: to control whether return instructions or epilogues are used, ! 144: define a `return' pattern with a validity condition that tests ! 145: the target switches appropriately. If the `return' pattern's ! 146: validity condition is false, epilogues will be used. ! 147: ! 148: On machines where functions may or may not have frame-pointers, ! 149: the function exit code must vary accordingly. Sometimes the code ! 150: for these two cases is completely different. To determine ! 151: whether a frame pointer is in wanted, the macro can refer to the ! 152: variable `frame_pointer_needed'. The variable's value will be 1 ! 153: at run time in a function that needs a frame pointer. ! 154: ! 155: Normally, it is necessary for `FUNCTION_PROLOGUE' and ! 156: `FUNCTION_EPILOGUE' to treat leaf functions specially. The C ! 157: variable `leaf_function' is nonzero for such a function. *Note ! 158: Leaf Functions::. ! 159: ! 160: On some machines, some functions pop their arguments on exit while ! 161: others leave that for the caller to do. For example, the 68020 ! 162: when given `-mrtd' pops arguments in functions that take a fixed ! 163: number of arguments. ! 164: ! 165: Your definition of the macro `RETURN_POPS_ARGS' decides which ! 166: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to ! 167: know what was decided. The variable `current_function_pops_args' ! 168: is the number of bytes of its arguments that a function should ! 169: pop. *Note Scalar Return::. ! 170: ! 171: `DELAY_SLOTS_FOR_EPILOGUE' ! 172: Define this macro if the function epilogue contains delay slots ! 173: to which instructions from the rest of the function can be ! 174: "moved". The definition should be a C expression whose value is ! 175: an integer representing the number of delay slots there. ! 176: ! 177: `ELIGIBLE_FOR_EPILOGUE_DELAY (INSN, N)' ! 178: A C expression that returns 1 if INSN can be placed in delay slot ! 179: number N of the epilogue. ! 180: ! 181: The argument N is an integer which identifies the delay slot now ! 182: being considered (since different slots may have different rules ! 183: of eligibility). It is never negative and is always less than ! 184: the number of epilogue delay slots (what ! 185: `DELAY_SLOTS_FOR_EPILOGUE' returns). If you reject a particular ! 186: insn for a given delay slot, in principle, it may be reconsidered ! 187: for a subsequent delay slot. Also, other insns may (at least in ! 188: principle) be considered for the so far unfilled delay slot. ! 189: ! 190: The insns accepted to fill the epilogue delay slots are put in an ! 191: RTL list made with `insn_list' objects, stored in the variable ! 192: `current_function_epilogue_delay_list'. The insn for the first ! 193: delay slot comes first in the list. Your definition of the macro ! 194: `FUNCTION_EPILOGUE' should fill the delay slots by outputting the ! 195: insns in this list, usually by calling `final_scan_insn'. ! 196: ! 197: You need not define this macro if you did not define ! 198: `DELAY_SLOTS_FOR_EPILOGUE'. ! 199: ! 200: ! 201: File: gcc.info, Node: Profiling, Prev: Function Entry, Up: Stack and Calling ! 202: ! 203: Generating Code for Profiling ! 204: ----------------------------- ! 205: ! 206: `FUNCTION_PROFILER (FILE, LABELNO)' ! 207: A C statement or compound statement to output to FILE some ! 208: assembler code to call the profiling subroutine `mcount'. Before ! 209: calling, the assembler code must load the address of a counter ! 210: variable into a register where `mcount' expects to find the ! 211: address. The name of this variable is `LP' followed by the ! 212: number LABELNO, so you would generate the name using `LP%d' in a ! 213: `fprintf'. ! 214: ! 215: The details of how the address should be passed to `mcount' are ! 216: determined by your operating system environment, not by GNU CC. ! 217: To figure them out, compile a small program for profiling using ! 218: the system's installed C compiler and look at the assembler code ! 219: that results. ! 220: ! 221: `PROFILE_BEFORE_PROLOGUE' ! 222: Define this macro if the code for function profiling should come ! 223: before the function prologue. Normally, the profiling code comes ! 224: after. ! 225: ! 226: `FUNCTION_BLOCK_PROFILER (FILE, LABELNO)' ! 227: A C statement or compound statement to output to FILE some ! 228: assembler code to initialize basic-block profiling for the current ! 229: object module. This code should call the subroutine ! 230: `__bb_init_func' once per object module, passing it as its sole ! 231: argument the address of a block allocated in the object module. ! 232: ! 233: The name of the block is a local symbol made with this statement: ! 234: ! 235: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 0); ! 236: ! 237: Of course, since you are writing the definition of ! 238: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you ! 239: can take a short cut in the definition of this macro and use the ! 240: name that you know will result. ! 241: ! 242: The first word of this block is a flag which will be nonzero if ! 243: the object module has already been initialized. So test this ! 244: word first, and do not call `__bb_init_func' if the flag is ! 245: nonzero. ! 246: ! 247: `BLOCK_PROFILER (FILE, BLOCKNO)' ! 248: A C statement or compound statement to increment the count ! 249: associated with the basic block number BLOCKNO. Basic blocks are ! 250: numbered separately from zero within each compilation. The count ! 251: associated with block number BLOCKNO is at index BLOCKNO in a ! 252: vector of words; the name of this array is a local symbol made ! 253: with this statement: ! 254: ! 255: ASM_GENERATE_INTERNAL_LABEL (BUFFER, "LPBX", 2); ! 256: ! 257: Of course, since you are writing the definition of ! 258: `ASM_GENERATE_INTERNAL_LABEL' as well as that of this macro, you ! 259: can take a short cut in the definition of this macro and use the ! 260: name that you know will result. ! 261: ! 262: ! 263: File: gcc.info, Node: Varargs, Next: Trampolines, Prev: Stack and Calling, Up: Target Macros ! 264: ! 265: Implementing the Varargs Macros ! 266: =============================== ! 267: ! 268: GNU CC comes with an implementation of `varargs.h' and `stdarg.h' ! 269: that work without change on machines that pass arguments on the stack. ! 270: Other machines require their own implementations of varargs, and the ! 271: two machine independent header files must have conditionals to include ! 272: it. ! 273: ! 274: ANSI `stdarg.h' differs from traditional `varargs.h' mainly in the ! 275: calling convention for `va_start'. The traditional implementation ! 276: takes just one argument, which is the variable in which to store the ! 277: argument pointer. The ANSI implementation takes an additional first ! 278: argument, which is the last named argument of the function. However, ! 279: it should not use this argument. The way to find the end of the named ! 280: arguments is with the built-in functions described below. ! 281: ! 282: `__builtin_saveregs ()' ! 283: Use this built-in function to save the argument registers in ! 284: memory so that the varargs mechanism can access them. Both ANSI ! 285: and traditional versions of `va_start' must use ! 286: `__builtin_saveregs', unless you use `SETUP_INCOMING_VARARGS' ! 287: (see below) instead. ! 288: ! 289: On some machines, `__builtin_saveregs' is open-coded under the ! 290: control of the macro `EXPAND_BUILTIN_SAVEREGS'. On other ! 291: machines, it calls a routine written in assembler language, found ! 292: in `libgcc2.c'. ! 293: ! 294: Regardless of what code is generated for the call to ! 295: `__builtin_saveregs', it appears at the beginning of the function, ! 296: not where the call to `__builtin_saveregs' is written. This is ! 297: because the registers must be saved before the function starts to ! 298: use them for its own purposes. ! 299: ! 300: `__builtin_args_info (CATEGORY)' ! 301: Use this built-in function to find the first anonymous arguments ! 302: in registers. ! 303: ! 304: In general, a machine may have several categories of registers ! 305: used for arguments, each for a particular category of data types. ! 306: (For example, on some machines, floating-point registers are ! 307: used for floating-point arguments while other arguments are ! 308: passed in the general registers.) To make non-varargs functions ! 309: use the proper calling convention, you have defined the ! 310: `CUMULATIVE_ARGS' data type to record how many registers in each ! 311: category have been used so far ! 312: ! 313: `__builtin_args_info' accesses the same data structure of type ! 314: `CUMULATIVE_ARGS' after the ordinary argument layout is finished ! 315: with it, with CATEGORY specifying which word to access. Thus, the ! 316: value indicates the first unused register in a given category. ! 317: ! 318: Normally, you would use `__builtin_args_info' in the ! 319: implementation of `va_start', accessing each category just once ! 320: and storing the value in the `va_list' object. This is because ! 321: `va_list' will have to update the values, and there is no way to ! 322: alter the values accessed by `__builtin_args_info'. ! 323: ! 324: `__builtin_next_arg ()' ! 325: This is the equivalent of `__builtin_args_info', for stack ! 326: arguments. It returns the address of the first anonymous stack ! 327: argument, as type `void *'. If `ARGS_GROW_DOWNWARD', it returns ! 328: the address of the location above the first anonymous stack ! 329: argument. Use it in `va_start' to initialize the pointer for ! 330: fetching arguments from the stack. ! 331: ! 332: `__builtin_classify_type (OBJECT)' ! 333: Since each machine has its own conventions for which data types ! 334: are passed in which kind of register, your implementation of ! 335: `va_arg' has to embody these conventions. The easiest way to ! 336: categorize the specified data type is to use ! 337: `__builtin_classify_type' together with `sizeof' and ! 338: `__alignof__'. ! 339: ! 340: `__builtin_classify_type' ignores the value of OBJECT, ! 341: considering only its data type. It returns an integer describing ! 342: what kind of type that is--integer, floating, pointer, structure, ! 343: and so on. ! 344: ! 345: The file `typeclass.h' defines an enumeration that you can use to ! 346: interpret the values of `__builtin_classify_type'. ! 347: ! 348: These machine description macros help implement varargs: ! 349: ! 350: `EXPAND_BUILTIN_SAVEREGS (ARGS)' ! 351: If defined, is a C expression that produces the machine-specific ! 352: code for a call to `__builtin_saveregs'. This code will be moved ! 353: to the very beginning of the function, before any parameter ! 354: access are made. The return value of this function should be an ! 355: RTX that contains the value to use as the return of ! 356: `__builtin_saveregs'. ! 357: ! 358: The argument ARGS is a `tree_list' containing the arguments that ! 359: were passed to `__builtin_saveregs'. ! 360: ! 361: If this macro is not defined, the compiler will output an ordinary ! 362: call to the library function `__builtin_saveregs'. ! 363: ! 364: `SETUP_INCOMING_VARARGS (ARGS_SO_FAR, MODE, TYPE, PRETEND_ARGS_SIZE, SECOND_TIME)' ! 365: This macro offers an alternative to using `__builtin_saveregs' and ! 366: defining the macro `EXPAND_BUILTIN_SAVEREGS'. Use it to store the ! 367: anonymous register arguments into the stack so that all the ! 368: arguments appear to have been passed consecutively on the stack. ! 369: Once this is done, you can use the standard implementation of ! 370: varargs that works for machines that pass all their arguments on ! 371: the stack. ! 372: ! 373: The argument ARGS_SO_FAR is the `CUMULATIVE_ARGS' data structure, ! 374: containing the values that obtain after processing of the named ! 375: arguments. The arguments MODE and TYPE describe the last named ! 376: argument--its machine mode and its data type as a tree node. ! 377: ! 378: The macro implementation should do two things: first, push onto ! 379: the stack all the argument registers *not* used for the named ! 380: arguments, and second, store the size of the data thus pushed ! 381: into the `int'-valued variable whose name is supplied as the ! 382: argument PRETEND_ARGS_SIZE. The value that you store here will ! 383: serve as additional offset for setting up the stack frame. ! 384: ! 385: Because you must generate code to push the anonymous arguments at ! 386: compile time without knowing their data types, ! 387: `SETUP_INCOMING_VARARGS' is only useful on machines that have just ! 388: a single category of argument register and use it uniformly for ! 389: all data types. ! 390: ! 391: If the argument SECOND_TIME is nonzero, it means that the ! 392: arguments of the function are being analyzed for the second time. ! 393: This happens for an inline function, which is not actually ! 394: compiled until the end of the source file. The macro ! 395: `SETUP_INCOMING_VARARGS' should not generate any instructions in ! 396: this case. ! 397: ! 398: ! 399: File: gcc.info, Node: Trampolines, Next: Library Calls, Prev: Varargs, Up: Target Macros 1.1 root 400: 401: Trampolines for Nested Functions 402: ================================ 403: 404: A "trampoline" is a small piece of code that is created at run time 405: when the address of a nested function is taken. It normally resides on 406: the stack, in the stack frame of the containing function. These macros 407: tell GNU CC how to generate code to allocate and initialize a 408: trampoline. 409: 410: The instructions in the trampoline must do two things: load a 411: constant address into the static chain register, and jump to the real 412: address of the nested function. On CISC machines such as the m68k, 413: this requires two instructions, a move immediate and a jump. Then the 414: two addresses exist in the trampoline as word-long immediate operands. 415: On RISC machines, it is often necessary to load each address into a 416: register in two parts. Then pieces of each address form separate 417: immediate operands. 418: 419: The code generated to initialize the trampoline must store the 420: variable parts--the static chain value and the function address--into 421: the immediate operands of the instructions. On a CISC machine, this is 422: simply a matter of copying each address to a memory reference at the 423: proper offset from the start of the trampoline. On a RISC machine, it 424: may be necessary to take out pieces of the address and store them 425: separately. 426: 427: `TRAMPOLINE_TEMPLATE (FILE)' 428: A C statement to output, on the stream FILE, assembler code for a 429: block of data that contains the constant parts of a trampoline. 430: This code should not include a label--the label is taken care of 431: automatically. 432: 433: `TRAMPOLINE_SIZE' 434: A C expression for the size in bytes of the trampoline, as an 435: integer. 436: 437: `TRAMPOLINE_ALIGNMENT' 438: Alignment required for trampolines, in bits. 439: 440: If you don't define this macro, the value of `BIGGEST_ALIGNMENT' 441: is used for aligning trampolines. 442: 443: `INITIALIZE_TRAMPOLINE (ADDR, FNADDR, STATIC_CHAIN)' 444: A C statement to initialize the variable parts of a trampoline. 445: ADDR is an RTX for the address of the trampoline; FNADDR is an 446: RTX for the address of the nested function; STATIC_CHAIN is an 447: RTX for the static chain value that should be passed to the 448: function when it is called. 449: 450: `ALLOCATE_TRAMPOLINE (FP)' 451: A C expression to allocate run-time space for a trampoline. The 452: expression value should be an RTX representing a memory reference 453: to the space for the trampoline. 454: 455: If this macro is not defined, by default the trampoline is 456: allocated as a stack slot. This default is right for most 457: machines. The exceptions are machines where it is impossible to 458: execute instructions in the stack area. On such machines, you 459: may have to implement a separate stack, using this macro in 460: conjunction with `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE'. 461: 462: FP points to a data structure, a `struct function', which 463: describes the compilation status of the immediate containing 464: function of the function which the trampoline is for. Normally 465: (when `ALLOCATE_TRAMPOLINE' is not defined), the stack slot for 466: the trampoline is in the stack frame of this containing function. 467: Other allocation strategies probably must do something analogous 468: with this information. 469: 470: Implementing trampolines is difficult on many machines because they 471: have separate instruction and data caches. Writing into a stack 472: location fails to clear the memory in the instruction cache, so when 473: the program jumps to that location, it executes the old contents. 474: 475: Here are two possible solutions. One is to clear the relevant 476: parts of the instruction cache whenever a trampoline is set up. The 477: other is to make all trampolines identical, by having them jump to a 478: standard subroutine. The former technique makes trampoline execution 479: faster; the latter makes initialization faster. 480: 481: To clear the instruction cache when a trampoline is initialized, 482: define the following macros which describe the shape of the cache. 483: 484: `INSN_CACHE_SIZE' 485: The total size in bytes of the cache. 486: 487: `INSN_CACHE_LINE_WIDTH' 488: The length in bytes of each cache line. The cache is divided 489: into cache lines which are disjoint slots, each holding a 490: contiguous chunk of data fetched from memory. Each time data is 491: brought into the cache, an entire line is read at once. The data 492: loaded into a cache line is always aligned on a boundary equal to 493: the line size. 494: 495: `INSN_CACHE_DEPTH' 496: The number of alternative cache lines that can hold any 497: particular memory location. 498: 499: To use a standard subroutine, define the following macro. In 500: addition, you must make sure that the instructions in a trampoline 501: fill an entire cache line with identical instructions, or else ensure 502: that the beginning of the trampoline code is always aligned at the 503: same point in its cache line. Look in `m68k.h' as a guide. 504: 505: `TRANSFER_FROM_TRAMPOLINE' 506: Define this macro if trampolines need a special subroutine to do 507: their work. The macro should expand to a series of `asm' 508: statements which will be compiled with GNU CC. They go in a 509: library function named `__transfer_from_trampoline'. 510: 511: If you need to avoid executing the ordinary prologue code of a 512: compiled C function when you jump to the subroutine, you can do 513: so by placing a special label of your own in the assembler code. 514: Use one `asm' statement to generate an assembler label, and 515: another to make the label global. Then trampolines can use that 516: label to jump directly to your special assembler code. 517: 518: 1.1.1.2 ! root 519: File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 1.1 root 520: 521: Implicit Calls to Library Routines 522: ================================== 523: 524: `MULSI3_LIBCALL' 525: A C string constant giving the name of the function to call for 526: multiplication of one signed full-word by another. If you do not 527: define this macro, the default name is used, which is `__mulsi3', 528: a function defined in `libgcc.a'. 529: 530: `DIVSI3_LIBCALL' 531: A C string constant giving the name of the function to call for 532: division of one signed full-word by another. If you do not define 533: this macro, the default name is used, which is `__divsi3', a 534: function defined in `libgcc.a'. 535: 536: `UDIVSI3_LIBCALL' 537: A C string constant giving the name of the function to call for 538: division of one unsigned full-word by another. If you do not 539: define this macro, the default name is used, which is 540: `__udivsi3', a function defined in `libgcc.a'. 541: 542: `MODSI3_LIBCALL' 543: A C string constant giving the name of the function to call for 544: the remainder in division of one signed full-word by another. If 545: you do not define this macro, the default name is used, which is 546: `__modsi3', a function defined in `libgcc.a'. 547: 548: `UMODSI3_LIBCALL' 549: A C string constant giving the name of the function to call for 550: the remainder in division of one unsigned full-word by another. 551: If you do not define this macro, the default name is used, which 552: is `__umodsi3', a function defined in `libgcc.a'. 553: 554: `MULDI3_LIBCALL' 555: A C string constant giving the name of the function to call for 556: multiplication of one signed double-word by another. If you do 557: not define this macro, the default name is used, which is 558: `__muldi3', a function defined in `libgcc.a'. 559: 560: `DIVDI3_LIBCALL' 561: A C string constant giving the name of the function to call for 562: division of one signed double-word by another. If you do not 563: define this macro, the default name is used, which is `__divdi3', 564: a function defined in `libgcc.a'. 565: 566: `UDIVDI3_LIBCALL' 567: A C string constant giving the name of the function to call for 568: division of one unsigned full-word by another. If you do not 569: define this macro, the default name is used, which is 570: `__udivdi3', a function defined in `libgcc.a'. 571: 572: `MODDI3_LIBCALL' 573: A C string constant giving the name of the function to call for 574: the remainder in division of one signed double-word by another. 575: If you do not define this macro, the default name is used, which 576: is `__moddi3', a function defined in `libgcc.a'. 577: 578: `UMODDI3_LIBCALL' 579: A C string constant giving the name of the function to call for 580: the remainder in division of one unsigned full-word by another. 581: If you do not define this macro, the default name is used, which 582: is `__umoddi3', a function defined in `libgcc.a'. 583: 584: `TARGET_MEM_FUNCTIONS' 585: Define this macro if GNU CC should generate calls to the System V 586: (and ANSI C) library functions `memcpy' and `memset' rather than 587: the BSD functions `bcopy' and `bzero'. 588: 589: `LIBGCC_NEEDS_DOUBLE' 590: Define this macro if only `float' arguments cannot be passed to 591: library routines (so they must be converted to `double'). This 592: macro affects both how library calls are generated and how the 593: library routines in `libgcc1.c' accept their arguments. It is 594: useful on machines where floating and fixed point arguments are 595: passed differently, such as the i860. 596: 597: `FLOAT_ARG_TYPE' 598: Define this macro to override the type used by the library 599: routines to pick up arguments of type `float'. (By default, they 600: use a union of `float' and `int'.) 601: 602: The obvious choice would be `float'--but that won't work with 603: traditional C compilers that expect all arguments declared as 604: `float' to arrive as `double'. To avoid this conversion, the 605: library routines ask for the value as some other type and then 606: treat it as a `float'. 607: 608: On some systems, no other type will work for this. For these 609: systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force 610: conversion of the values `double' before they are passed. 611: 612: `FLOATIFY (PASSED-VALUE)' 613: Define this macro to override the way library routines 614: redesignate a `float' argument as a `float' instead of the type 615: it was passed as. The default is an expression which takes the 616: `float' field of the union. 617: 618: `FLOAT_VALUE_TYPE' 619: Define this macro to override the type used by the library 620: routines to return values that ought to have type `float'. (By 621: default, they use `int'.) 622: 623: The obvious choice would be `float'--but that won't work with 624: traditional C compilers gratuitously convert values declared as 625: `float' into `double'. 626: 627: `INTIFY (FLOAT-VALUE)' 628: Define this macro to override the way the value of a 629: `float'-returning library routine should be packaged in order to 630: return it. These functions are actually declared to return type 631: `FLOAT_VALUE_TYPE' (normally `int'). 632: 633: These values can't be returned as type `float' because traditional 634: C compilers would gratuitously convert the value to a `double'. 635: 636: A local variable named `intify' is always available when the macro 637: `INTIFY' is used. It is a union of a `float' field named `f' and 638: a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. 639: 640: If you don't define this macro, the default definition works by 641: copying the value through that union. 642: 643: `SItype' 644: Define this macro as the name of the data type corresponding to 645: `SImode' in the system's own C compiler. 646: 647: You need not define this macro if that type is `int', as it 648: usually is. 649: 650: `perform_...' 651: Define these macros to supply explicit C statements to carry out 652: various arithmetic operations on types `float' and `double' in the 653: library routines in `libgcc1.c'. See that file for a full list 654: of these macros and their arguments. 655: 656: On most machines, you don't need to define any of these macros, 657: because the C compiler that comes with the system takes care of 658: doing them. 659: 660: `NEXT_OBJC_RUNTIME' 661: Define this macro to generate code for Objective C message 662: sending using the calling convention of the NeXT system. This 663: calling convention involves passing the object, the selector and 664: the method arguments all at once to the method-lookup library 665: function. 666: 667: The default calling convention passes just the object and the 668: selector to the lookup function, which returns a pointer to the 669: method. 670: 671: 1.1.1.2 ! root 672: File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros 1.1 root 673: 674: Addressing Modes 675: ================ 676: 677: `HAVE_POST_INCREMENT' 678: Define this macro if the machine supports post-increment 679: addressing. 680: 681: `HAVE_PRE_INCREMENT' 682: `HAVE_POST_DECREMENT' 683: `HAVE_PRE_DECREMENT' 684: Similar for other kinds of addressing. 685: 686: `CONSTANT_ADDRESS_P (X)' 687: A C expression that is 1 if the RTX X is a constant which is a 688: valid address. On most machines, this can be defined as 689: `CONSTANT_P (X)', but a few machines are more restrictive in 690: which constant addresses are supported. 691: 692: `CONSTANT_P' accepts integer-values expressions whose values are 693: not explicitly known, such as `symbol_ref', `label_ref', and 694: `high' expressions and `const' arithmetic expressions, in 695: addition to `const_int' and `const_double' expressions. 696: 697: `MAX_REGS_PER_ADDRESS' 698: A number, the maximum number of registers that can appear in a 699: valid memory address. Note that it is up to you to specify a 700: value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' 701: would ever accept. 702: 703: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' 704: A C compound statement with a conditional `goto LABEL;' executed 705: if X (an RTX) is a legitimate memory address on the target 706: machine for a memory operand of mode MODE. 707: 708: It usually pays to define several simpler macros to serve as 709: subroutines for this one. Otherwise it may be too complicated to 710: understand. 711: 712: This macro must exist in two variants: a strict variant and a 713: non-strict one. The strict variant is used in the reload pass. 714: It must be defined so that any pseudo-register that has not been 715: allocated a hard register is considered a memory reference. In 716: contexts where some kind of register is required, a 717: pseudo-register with no hard register must be rejected. 718: 719: The non-strict variant is used in other passes. It must be 720: defined to accept all pseudo-registers in every context where 721: some kind of register is required. 722: 723: Compiler source files that want to use the strict variant of this 724: macro define the macro `REG_OK_STRICT'. You should use an 725: `#ifdef REG_OK_STRICT' conditional to define the strict variant 726: in that case and the non-strict variant otherwise. 727: 728: Typically among the subroutines used to define 729: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for 730: acceptable registers for various purposes (one for base 731: registers, one for index registers, and so on). Then only these 732: subroutine macros need have two variants; the higher levels of 733: macros may be the same whether strict or not. 734: 735: Normally, constant addresses which are the sum of a `symbol_ref' 736: and an integer are stored inside a `const' RTX to mark them as 737: constant. Therefore, there is no need to recognize such sums 738: specifically as legitimate addresses. Normally you would simply 739: recognize any `const' as legitimate. 740: 741: Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 742: sums that are not marked with `const'. It assumes that a naked 743: `plus' indicates indexing. If so, then you *must* reject such 744: naked constant sums as illegitimate addresses, so that none of 745: them will be given to `PRINT_OPERAND_ADDRESS'. 746: 747: On some machines, whether a symbolic address is legitimate 748: depends on the section that the address refers to. On these 749: machines, define the macro `ENCODE_SECTION_INFO' to store the 750: information into the `symbol_ref', and then check for it here. 751: When you see a `const', you will have to look inside it to find 752: the `symbol_ref' in order to determine the section. *Note 753: Assembler Format::. 754: 755: The best way to modify the name string is by adding text to the 756: beginning, with suitable punctuation to prevent any ambiguity. 757: Allocate the new name in `saveable_obstack'. You will have to 758: modify `ASM_OUTPUT_LABELREF' to remove and decode the added text 759: and output the name accordingly. 760: 761: You can check the information stored here into the `symbol_ref' in 762: the definitions of `GO_IF_LEGITIMATE_ADDRESS' and 763: `PRINT_OPERAND_ADDRESS'. 764: 765: `REG_OK_FOR_BASE_P (X)' 766: A C expression that is nonzero if X (assumed to be a `reg' RTX) 767: is valid for use as a base register. For hard registers, it 768: should always accept those which the hardware permits and reject 769: the others. Whether the macro accepts or rejects pseudo 770: registers must be controlled by `REG_OK_STRICT' as described 771: above. This usually requires two variant definitions, of which 772: `REG_OK_STRICT' controls the one actually used. 773: 774: `REG_OK_FOR_INDEX_P (X)' 775: A C expression that is nonzero if X (assumed to be a `reg' RTX) 776: is valid for use as an index register. 777: 778: The difference between an index register and a base register is 779: that the index register may be scaled. If an address involves 780: the sum of two registers, neither one of them scaled, then either 781: one may be labeled the "base" and the other the "index"; but 782: whichever labeling is used must fit the machine's constraints of 783: which registers may serve in each capacity. The compiler will 784: try both labelings, looking for one that is valid, and will 785: reload one or both registers only if neither labeling works. 786: 787: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' 788: A C compound statement that attempts to replace X with a valid 789: memory address for an operand of mode MODE. WIN will be a C 790: statement label elsewhere in the code; the macro definition may 791: use 792: 793: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); 794: 795: to avoid further processing if the address has become legitimate. 796: 797: X will always be the result of a call to `break_out_memory_refs', 798: and OLDX will be the operand that was given to that function to 799: produce X. 800: 801: The code generated by this macro should not alter the 802: substructure of X. If it transforms X into a more legitimate 803: form, it should assign X (which will always be a C variable) a 804: new value. 805: 806: It is not necessary for this macro to come up with a legitimate 807: address. The compiler has standard ways of doing so in all 808: cases. In fact, it is safe for this macro to do nothing. But 809: often a machine-dependent strategy can generate better code. 810: 811: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' 812: A C statement or compound statement with a conditional `goto 813: LABEL;' executed if memory address X (an RTX) can have different 814: meanings depending on the machine mode of the memory reference it 815: is used for. 816: 817: Autoincrement and autodecrement addresses typically have 818: mode-dependent effects because the amount of the increment or 819: decrement is the size of the operand being addressed. Some 820: machines have other mode-dependent addresses. Many RISC machines 821: have no mode-dependent addresses. 822: 823: You may assume that ADDR is a valid address for the machine. 824: 825: `LEGITIMATE_CONSTANT_P (X)' 826: A C expression that is nonzero if X is a legitimate constant for 827: an immediate operand on the target machine. You can assume that 828: X satisfies `CONSTANT_P', so you need not check this. In fact, 829: `1' is a suitable definition for this macro on machines where 830: anything `CONSTANT_P' is valid. 831: 832: `LEGITIMATE_PIC_OPERAND_P (X)' 833: A C expression that is nonzero if X is a legitimate immediate 834: operand on the target machine when generating position 835: independent code. You can assume that X satisfies `CONSTANT_P', 836: so you need not check this. You can also assume FLAG_PIC is 837: true, so you need not check it either. You need not define this 838: macro if all constants (including `SYMBOL_REF') can be immediate 839: operands when generating position independent code. 840: 841: 1.1.1.2 ! root 842: File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros 1.1 root 843: 844: Condition Code Status 845: ===================== 846: 847: The file `conditions.h' defines a variable `cc_status' to describe 848: how the condition code was computed (in case the interpretation of the 849: condition code depends on the instruction that it was set by). This 850: variable contains the RTL expressions on which the condition code is 851: currently based, and several standard flags. 852: 853: Sometimes additional machine-specific flags must be defined in the 854: machine description header file. It can also add additional 855: machine-specific information by defining `CC_STATUS_MDEP'. 856: 857: `CC_STATUS_MDEP' 858: C code for a data type which is used for declaring the `mdep' 859: component of `cc_status'. It defaults to `int'. 860: 861: This macro is not used on machines that do not use `cc0'. 862: 863: `CC_STATUS_MDEP_INIT' 864: A C expression to initialize the `mdep' field to "empty". The 865: default definition does nothing, since most machines don't use 866: the field anyway. If you want to use the field, you should 867: probably define this macro to initialize it. 868: 869: This macro is not used on machines that do not use `cc0'. 870: 871: `NOTICE_UPDATE_CC (EXP, INSN)' 872: A C compound statement to set the components of `cc_status' 873: appropriately for an insn INSN whose body is EXP. It is this 874: macro's responsibility to recognize insns that set the condition 875: code as a byproduct of other activity as well as those that 876: explicitly set `(cc0)'. 877: 878: This macro is not used on machines that do not use `cc0'. 879: 880: If there are insns that do not set the condition code but do alter 881: other machine registers, this macro must check to see whether they 882: invalidate the expressions that the condition code is recorded as 883: reflecting. For example, on the 68000, insns that store in 884: address registers do not set the condition code, which means that 885: usually `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for 886: such insns. But suppose that the previous insn set the condition 887: code based on location `a4@(102)' and the current insn stores a 888: new value in `a4'. Although the condition code is not changed by 889: this, it will no longer be true that it reflects the contents of 890: `a4@(102)'. Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' 891: in this case to say that nothing is known about the condition 892: code value. 893: 894: The definition of `NOTICE_UPDATE_CC' must be prepared to deal 895: with the results of peephole optimization: insns whose patterns 896: are `parallel' RTXs containing various `reg', `mem' or constants 897: which are just the operands. The RTL structure of these insns is 898: not sufficient to indicate what the insns actually do. What 899: `NOTICE_UPDATE_CC' should do when it sees one is just to run 900: `CC_STATUS_INIT'. 901: 902: A possible definition of `NOTICE_UPDATE_CC' is to call a function 903: that looks at an attribute (*note Insn Attributes::.) named, for 904: example, `cc'. This avoids having detailed information about 905: patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 906: 907: `EXTRA_CC_MODES' 908: A list of names to be used for additional modes for condition code 909: values in registers (*note Jump Patterns::.). These names are 910: added to `enum machine_mode' and all have class `MODE_CC'. By 911: convention, they should start with `CC' and end with `mode'. 912: 913: You should only define this macro if your machine does not use 914: `cc0' and only if additional modes are required. 915: 916: `EXTRA_CC_NAMES' 917: A list of C strings giving the names for the modes listed in 918: `EXTRA_CC_MODES'. For example, the Sparc defines this macro and 919: `EXTRA_CC_MODES' as 920: 921: #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode 922: #define EXTRA_CC_NAMES "CC_NOOV", "CCFP" 923: 924: This macro is not required if `EXTRA_CC_MODES' is not defined. 925: 926: `SELECT_CC_MODE (OP, X)' 927: Returns a mode from class `MODE_CC' to be used when comparison 928: operation code OP is applied to rtx X. For example, on the Sparc, 929: `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. for a 930: description of the reason for this definition) 931: 932: #define SELECT_CC_MODE(OP,X) \ 933: (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \ 934: : (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 935: || GET_CODE (X) == NEG) \ 936: ? CC_NOOVmode : CCmode) 937: 938: This macro is not required if `EXTRA_CC_MODES' is not defined. 939: 940:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.