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