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