![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 1.x] / gcc |
1.1 ! root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input ! 2: file gcc.texinfo. ! 3: ! 4: This file documents the use and the internals of the GNU compiler. ! 5: ! 6: Copyright (C) 1988 Free Software Foundation, Inc. ! 7: ! 8: Permission is granted to make and distribute verbatim copies of this ! 9: manual provided the copyright notice and this permission notice are ! 10: preserved on all copies. ! 11: ! 12: Permission is granted to copy and distribute modified versions of ! 13: this manual under the conditions for verbatim copying, provided also ! 14: that the section entitled ``GNU CC General Public License'' is ! 15: 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. ! 18: ! 19: Permission is granted to copy and distribute translations of this ! 20: manual into another language, under the above conditions for modified ! 21: versions, except that the section entitled ``GNU CC General Public ! 22: License'' and this permission notice may be included in translations ! 23: approved by the Free Software Foundation instead of in the original ! 24: English. ! 25: ! 26: ! 27: ! 28: File: gcc.info, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros ! 29: ! 30: Describing Stack Layout ! 31: ======================= ! 32: ! 33: `STACK_GROWS_DOWNWARD' ! 34: Define this macro if pushing a word onto the stack moves the ! 35: stack pointer to a smaller address. ! 36: ! 37: When we say, ``define this macro if ...,'' it means that the ! 38: compiler checks this macro only with `#ifdef' so the precise ! 39: definition used does not matter. ! 40: ! 41: `FRAME_GROWS_DOWNWARD' ! 42: Define this macro if the addresses of local variable slots are ! 43: at negative offsets from the frame pointer. ! 44: ! 45: `STARTING_FRAME_OFFSET' ! 46: Offset from the frame pointer to the first local variable slot ! 47: to be allocated. ! 48: ! 49: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by ! 50: subtracting the length of the first slot from ! 51: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the ! 52: length of the first slot to the value `STARTING_FRAME_OFFSET'. ! 53: ! 54: `PUSH_ROUNDING (NPUSHED)' ! 55: A C expression that is the number of bytes actually pushed onto ! 56: the stack when an instruction attempts to push NPUSHED bytes. ! 57: ! 58: If the target machine does not have a push instruction, do not ! 59: define this macro. That directs GNU CC to use an alternate ! 60: strategy: to allocate the entire argument block and then store ! 61: the arguments into it. ! 62: ! 63: On some machines, the definition ! 64: ! 65: #define PUSH_ROUNDING(BYTES) (BYTES) ! 66: ! 67: will suffice. But on other machines, instructions that appear ! 68: to push one byte actually push two bytes in an attempt to ! 69: maintain alignment. Then the definition should be ! 70: ! 71: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1) ! 72: ! 73: `FIRST_PARM_OFFSET (FUNDECL)' ! 74: Offset from the argument pointer register to the first ! 75: argument's address. On some machines it may depend on the data ! 76: type of the function. (In the next version of GNU CC, the ! 77: argument will be changed to the function data type rather than ! 78: its declaration.) ! 79: ! 80: `FIRST_PARM_CALLER_OFFSET (FUNDECL)' ! 81: Define this macro on machines where register parameters have ! 82: shadow locations on the stack, at addresses below the nominal ! 83: parameter. This matters because certain arguments cannot be ! 84: passed on the stack. On these machines, such arguments must be ! 85: stored into the shadow locations. ! 86: ! 87: This macro should expand into a C expression whose value is the ! 88: offset of the first parameter's shadow location from the nominal ! 89: stack pointer value. (That value is itself computed by adding ! 90: the value of `STACK_POINTER_OFFSET' to the stack pointer ! 91: register.) ! 92: ! 93: `RETURN_POPS_ARGS (FUNTYPE)' ! 94: A C expression that should be 1 if a function pops its own ! 95: arguments on returning, or 0 if the function pops no arguments ! 96: and the caller must therefore pop them all after the function ! 97: returns. ! 98: ! 99: FUNTYPE is a C variable whose value is a tree node that ! 100: describes the function in question. Normally it is a node of ! 101: type `FUNCTION_TYPE' that describes the data type of the function. ! 102: From this it is possible to obtain the data types of the value ! 103: and arguments (if known). ! 104: ! 105: When a call to a library function is being considered, FUNTYPE ! 106: will contain an identifier node for the library function. Thus, ! 107: if you need to distinguish among various library functions, you ! 108: can do so by their names. Note that ``library function'' in ! 109: this context means a function used to perform arithmetic, whose ! 110: name is known specially in the compiler and was not mentioned in ! 111: the C code being compiled. ! 112: ! 113: On the Vax, all functions always pop their arguments, so the ! 114: definition of this macro is 1. On the 68000, using the standard ! 115: calling convention, no functions pop their arguments, so the ! 116: value of the macro is always 0 in this case. But an alternative ! 117: calling convention is available in which functions that take a ! 118: fixed number of arguments pop them but other functions (such as ! 119: `printf') pop nothing (the caller pops all). When this ! 120: convention is in use, FUNTYPE is examined to determine whether a ! 121: function takes a fixed number of arguments. ! 122: ! 123: `FUNCTION_VALUE (VALTYPE, FUNC)' ! 124: A C expression to create an RTX representing the place where a ! 125: function returns a value of data type VALTYPE. VALTYPE is a ! 126: tree node representing a data type. Write `TYPE_MODE (VALTYPE)' ! 127: to get the machine mode used to represent that type. On many ! 128: machines, only the mode is relevant. (Actually, on most ! 129: machines, scalar values are returned in the same place ! 130: regardless of mode). ! 131: ! 132: If the precise function being called is known, FUNC is a tree ! 133: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null ! 134: pointer. This makes it possible to use a different ! 135: value-returning convention for specific functions when all their ! 136: calls are known. ! 137: ! 138: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)' ! 139: Define this macro if the target machine has ``register windows'' ! 140: so that the register in which a function returns its value is ! 141: not the same as the one in which the caller sees the value. ! 142: ! 143: For such machines, `FUNCTION_VALUE' computes the register in ! 144: which the caller will see the value, and ! 145: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion ! 146: to tell the function where to put the value. ! 147: ! 148: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE' ! 149: serves both purposes. ! 150: ! 151: `LIBCALL_VALUE (MODE)' ! 152: A C expression to create an RTX representing the place where a ! 153: library function returns a value of mode MODE. If the precise ! 154: function being called is known, FUNC is a tree node ! 155: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer. ! 156: This makes it possible to use a different value-returning ! 157: convention for specific functions when all their calls are known. ! 158: ! 159: Note that ``library function'' in this context means a compiler ! 160: support routine, used to perform arithmetic, whose name is known ! 161: specially by the compiler and was not mentioned in the C code ! 162: being compiled. ! 163: ! 164: `FUNCTION_VALUE_REGNO_P (REGNO)' ! 165: A C expression that is nonzero if REGNO is the number of a hard ! 166: register in which the values of called function may come back. ! 167: ! 168: A register whose use for returning values is limited to serving ! 169: as the second of a pair (for a value of type `double', say) need ! 170: not be recognized by this macro. So for most machines, this ! 171: definition suffices: ! 172: ! 173: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0) ! 174: ! 175: If the machine has register windows, so that the caller and the ! 176: called function use different registers for the return value, ! 177: this macro should recognize only the caller's register numbers. ! 178: ! 179: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)' ! 180: A C expression that controls whether a function argument is ! 181: passed in a register, and which register. ! 182: ! 183: The arguments are CUM, which summarizes all the previous ! 184: arguments; MODE, the machine mode of the argument; TYPE, the ! 185: data type of the argument as a tree node or 0 if that is not ! 186: known (which happens for C support library functions); and ! 187: NAMED, which is 1 for an ordinary argument and 0 for nameless ! 188: arguments that correspond to `...' in the called function's ! 189: prototype. ! 190: ! 191: The value of the expression should either be a `reg' RTX for the ! 192: hard register in which to pass the argument, or zero to pass the ! 193: argument on the stack. ! 194: ! 195: For the Vax and 68000, where normally all arguments are pushed, ! 196: zero suffices as a definition. ! 197: ! 198: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)' ! 199: Define this macro if the target machine has ``register ! 200: windows'', so that the register in which a function sees an ! 201: arguments is not necessarily the same as the one in which the ! 202: caller passed the argument. ! 203: ! 204: For such machines, `FUNCTION_ARG' computes the register in which ! 205: the caller passes the value, and `FUNCTION_INCOMING_ARG' should ! 206: be defined in a similar fashion to tell the function being ! 207: called where the arguments will arrive. ! 208: ! 209: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves ! 210: both purposes. ! 211: ! 212: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)' ! 213: A C expression for the number of words, at the beginning of an ! 214: argument, must be put in registers. The value must be zero for ! 215: arguments that are passed entirely in registers or that are ! 216: entirely pushed on the stack. ! 217: ! 218: On some machines, certain arguments must be passed partially in ! 219: registers and partially in memory. On these machines, typically ! 220: the first N words of arguments are passed in registers, and the ! 221: rest on the stack. If a multi-word argument (a `double' or a ! 222: structure) crosses that boundary, its first few words must be ! 223: passed in registers and the rest must be pushed. This macro ! 224: tells the compiler when this occurs, and how many of the words ! 225: should go in registers. ! 226: ! 227: `FUNCTION_ARG' for these arguments should return the first ! 228: register to be used by the caller for this argument; likewise ! 229: `FUNCTION_INCOMING_ARG', for the called function. ! 230: ! 231: `CUMULATIVE_ARGS' ! 232: A C type for declaring a variable that is used as the first ! 233: argument of `FUNCTION_ARG' and other related values. For some ! 234: target machines, the type `int' suffices and can hold the number ! 235: of bytes of argument so far. ! 236: ! 237: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE)' ! 238: A C statement (sans semicolon) for initializing the variable CUM ! 239: for the state at the beginning of the argument list. The ! 240: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the ! 241: tree node for the data type of the function which will receive ! 242: the args, or 0 if the args are to a compiler support library ! 243: function. ! 244: ! 245: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)' ! 246: Update the summarizer variable CUM to advance past an argument ! 247: in the argument list. The values MODE, TYPE and NAMED describe ! 248: that argument. Once this is done, the variable CUM is suitable ! 249: for analyzing the *following* argument with `FUNCTION_ARG', etc. ! 250: ! 251: `FUNCTION_ARG_REGNO_P (REGNO)' ! 252: A C expression that is nonzero if REGNO is the number of a hard ! 253: register in which function arguments are sometimes passed. This ! 254: does *not* include implicit arguments such as the static chain ! 255: and the structure-value address. On many machines, no registers ! 256: can be used for this purpose since all function arguments are ! 257: pushed on the stack. ! 258: ! 259: `FUNCTION_ARG_PADDING (MODE, SIZE)' ! 260: If defined, a C expression which determines whether, and in ! 261: which direction, to pad out an argument with extra space. The ! 262: value should be of type `enum direction': either `upward' to pad ! 263: above the argument, `downward' to pad below, or `none' to ! 264: inhibit padding. ! 265: ! 266: The argument SIZE is an RTX which describes the size of the ! 267: argument, in bytes. It should be used only if MODE is ! 268: `BLKmode'. Otherwise, SIZE is 0. ! 269: ! 270: This macro does not control the *amount* of padding; that is ! 271: always just enough to reach the next multiple of `PARM_BOUNDARY'. ! 272: ! 273: This macro has a default definition which is right for most ! 274: systems. For little-endian machines, the default is to pad ! 275: upward. For big-endian machines, the default is to pad downward ! 276: for an argument of constant size shorter than an `int', and ! 277: upward otherwise. ! 278: ! 279: `FUNCTION_PROLOGUE (FILE, SIZE)' ! 280: A C compound statement that outputs the assembler code for entry ! 281: to a function. The prologue is responsible for setting up the ! 282: stack frame, initializing the frame pointer register, saving ! 283: registers that must be saved, and allocating SIZE additional ! 284: bytes of storage for the local variables. SIZE is an integer. ! 285: FILE is a stdio stream to which the assembler code should be ! 286: output. ! 287: ! 288: The label for the beginning of the function need not be output ! 289: by this macro. That has already been done when the macro is run. ! 290: ! 291: To determine which registers to save, the macro can refer to the ! 292: array `regs_ever_live': element R is nonzero if hard register R ! 293: is used anywhere within the function. This implies the function ! 294: prologue should save register R, but not if it is one of the ! 295: call-used registers. ! 296: ! 297: On machines where functions may or may not have frame-pointers, ! 298: the function entry code must vary accordingly; it must set up ! 299: the frame pointer if one is wanted, and not otherwise. To ! 300: determine whether a frame pointer is in wanted, the macro can ! 301: refer to the variable `frame_pointer_needed'. The variable's ! 302: value will be 1 at run time in a function that needs a frame ! 303: pointer. ! 304: ! 305: `FUNCTION_PROFILER (FILE, LABELNO)' ! 306: A C statement or compound statement to output to FILE some ! 307: assembler code to call the profiling subroutine `mcount'. ! 308: Before calling, the assembler code must load the address of a ! 309: counter variable into a register where `mcount' expects to find ! 310: the address. The name of this variable is `LP' followed by the ! 311: number LABELNO, so you would generate the name using `LP%d' in a ! 312: `fprintf'. ! 313: ! 314: The details of how the address should be passed to `mcount' are ! 315: determined by your operating system environment, not by GNU CC. ! 316: To figure them out, compile a small program for profiling using ! 317: the system's installed C compiler and look at the assembler code ! 318: that results. ! 319: ! 320: `EXIT_IGNORES_STACK' ! 321: Define this macro as a C expression that is nonzero if the ! 322: return instruction or the function epilogue ignores the value of ! 323: the stack pointer; in other words, if it is safe to delete an ! 324: instruction to adjust the stack pointer before a return from the ! 325: function. ! 326: ! 327: Note that this macro's value is relevant only for for which ! 328: frame pointers are maintained. It is never possible to delete a ! 329: final stack adjustment in a function that has no frame pointer, ! 330: and the compiler knows this regardless of `EXIT_IGNORES_STACK'. ! 331: ! 332: `FUNCTION_EPILOGUE (FILE, SIZE)' ! 333: A C compound statement that outputs the assembler code for exit ! 334: from a function. The epilogue is responsible for restoring the ! 335: saved registers and stack pointer to their values when the ! 336: function was called, and returning control to the caller. This ! 337: macro takes the same arguments as the macro `FUNCTION_PROLOGUE', ! 338: and the registers to restore are determined from ! 339: `regs_ever_live' and `CALL_USED_REGISTERS' in the same way. ! 340: ! 341: On some machines, there is a single instruction that does all ! 342: the work of returning from the function. On these machines, ! 343: give that instruction the name `return' and do not define the ! 344: macro `FUNCTION_EPILOGUE' at all. ! 345: ! 346: Do not define a pattern named `return' if you want the ! 347: `FUNCTION_EPILOGUE' to be used. If you want the target switches ! 348: to control whether return instructions or epilogues are used, ! 349: define a `return' pattern with a validity condition that tests ! 350: the target switches appropriately. If the `return' pattern's ! 351: validity condition is false, epilogues will be used. ! 352: ! 353: On machines where functions may or may not have frame-pointers, ! 354: the function exit code must vary accordingly. Sometimes the ! 355: code for these two cases is completely different. To determine ! 356: whether a frame pointer is in wanted, the macro can refer to the ! 357: variable `frame_pointer_needed'. The variable's value will be 1 ! 358: at run time in a function that needs a frame pointer. ! 359: ! 360: On some machines, some functions pop their arguments on exit ! 361: while others leave that for the caller to do. For example, the ! 362: 68020 when given `-mrtd' pops arguments in functions that take a ! 363: fixed number of arguments. ! 364: ! 365: Your definition of the macro `RETURN_POPS_ARGS' decides which ! 366: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to ! 367: know what was decided. The variable ! 368: `current_function_pops_args' is nonzero if the function should ! 369: pop its own arguments. If so, use the variable ! 370: `current_function_args_size' as the number of bytes to pop. ! 371: ! 372: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)' ! 373: A C compound statement to alter a memory address that uses the ! 374: frame pointer register so that it uses the stack pointer ! 375: register instead. This must be done in the instructions that ! 376: load parameter values into registers, when the reload pass ! 377: determines that a frame pointer is not necessary for the ! 378: function. ADDR will be a C variable name, and the updated ! 379: address should be stored in that variable. DEPTH will be the ! 380: current depth of stack temporaries (number of bytes of arguments ! 381: currently pushed). The change in offset between a ! 382: frame-pointer-relative address and a stack-pointer-relative ! 383: address must include DEPTH. ! 384: ! 385: Even if your machine description specifies there will always be ! 386: a frame pointer in the frame pointer register, you must still ! 387: define `FIX_FRAME_POINTER_ADDRESS', but the definition will ! 388: never be executed at run time, so it may be empty. ! 389: ! 390: ! 391: ! 392: File: gcc.info, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros ! 393: ! 394: Library Subroutine Names ! 395: ======================== ! 396: ! 397: `UDIVSI3_LIBCALL' ! 398: A C string constant giving the name of the function to call for ! 399: division of a full-word by a full-word. If you do not define ! 400: this macro, the default name is used, which is `_udivsi3', a ! 401: function defined in `gnulib'. ! 402: ! 403: `UMODSI3_LIBCALL' ! 404: A C string constant giving the name of the function to call for ! 405: the remainder in division of a full-word by a full-word. If you ! 406: do not define this macro, the default name is used, which is ! 407: `_umodsi3', a function defined in `gnulib'. ! 408: ! 409: `TARGET_MEM_FUNCTIONS' ! 410: Define this macro if GNU CC should generate calls to the System ! 411: V (and ANSI C) library functions `memcpy' and `memset' rather ! 412: than the BSD functions `bcopy' and `bzero'. ! 413: ! 414: ! 415: ! 416: File: gcc.info, Node: Addressing Modes, Next: Misc, Prev: Library Names, Up: Machine Macros ! 417: ! 418: Addressing Modes ! 419: ================ ! 420: ! 421: `HAVE_POST_INCREMENT' ! 422: Define this macro if the machine supports post-increment ! 423: addressing. ! 424: ! 425: `HAVE_PRE_INCREMENT' ! 426: `HAVE_POST_DECREMENT' ! 427: `HAVE_PRE_DECREMENT' ! 428: Similar for other kinds of addressing. ! 429: ! 430: `CONSTANT_ADDRESS_P (X)' ! 431: A C expression that is 1 if the RTX X is a constant whose value ! 432: is an integer. This includes integers whose values are not ! 433: explicitly known, such as `symbol_ref' and `label_ref' ! 434: expressions and `const' arithmetic expressions. ! 435: ! 436: On most machines, this can be defined as `CONSTANT_P (X)', but a ! 437: few machines are more restrictive in which constant addresses ! 438: are supported. ! 439: ! 440: `MAX_REGS_PER_ADDRESS' ! 441: A number, the maximum number of registers that can appear in a ! 442: valid memory address. ! 443: ! 444: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' ! 445: A C compound statement with a conditional `goto LABEL;' executed ! 446: if X (an RTX) is a legitimate memory address on the target ! 447: machine for a memory operand of mode MODE. ! 448: ! 449: It usually pays to define several simpler macros to serve as ! 450: subroutines for this one. Otherwise it may be too complicated ! 451: to understand. ! 452: ! 453: This macro must exist in two variants: a strict variant and a ! 454: non-strict one. The strict variant is used in the reload pass. ! 455: It must be defined so that any pseudo-register that has not been ! 456: allocated a hard register is considered a memory reference. In ! 457: contexts where some kind of register is required, a ! 458: pseudo-register with no hard register must be rejected. ! 459: ! 460: The non-strict variant is used in other passes. It must be ! 461: defined to accept all pseudo-registers in every context where ! 462: some kind of register is required. ! 463: ! 464: Compiler source files that want to use the strict variant of ! 465: this macro define the macro `REG_OK_STRICT'. You should use an ! 466: `#ifdef REG_OK_STRICT' conditional to define the strict variant ! 467: in that case and the non-strict variant otherwise. ! 468: ! 469: Typically among the subroutines used to define ! 470: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for ! 471: acceptable registers for various purposes (one for base ! 472: registers, one for index registers, and so on). Then only these ! 473: subroutine macros need have two variants; the higher levels of ! 474: macros may be the same whether strict or not. ! 475: ! 476: `REG_OK_FOR_BASE_P (X)' ! 477: A C expression that is nonzero if X (asumed to be a `reg' RTX) ! 478: is valid for use as a base register. For hard registers, it ! 479: should always accept those which the hardware permits and reject ! 480: the others. Whether the macro accepts or rejects pseudo ! 481: registers must be controlled by `REG_OK_STRICT' as described ! 482: above. This usually requires two variant definitions, of which ! 483: `REG_OK_STRICT' controls the one actually used. ! 484: ! 485: `REG_OK_FOR_INDEX_P (X)' ! 486: A C expression that is nonzero if X (asumed to be a `reg' RTX) ! 487: is valid for use as an index register. ! 488: ! 489: The difference between an index register and a base register is ! 490: that the index register may be scaled. If an address involves ! 491: the sum of two registers, neither one of them scaled, then ! 492: either one may be labeled the ``base'' and the other the ! 493: ``index''; but whichever labeling is used must fit the machine's ! 494: constraints of which registers may serve in each capacity. The ! 495: compiler will try both labelings, looking for one that is valid, ! 496: and will reload one or both registers only if neither labeling ! 497: works. ! 498: ! 499: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' ! 500: A C compound statement that attempts to replace X with a valid ! 501: memory address for an operand of mode MODE. WIN will be a C ! 502: statement label elsewhere in the code; the macro definition may ! 503: use ! 504: ! 505: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); ! 506: ! 507: to avoid further processing if the address has become legitimate. ! 508: ! 509: X will always be the result of a call to ! 510: `break_out_memory_refs', and OLDX will be the operand that was ! 511: given to that function to produce X. ! 512: ! 513: The code generated by this macro should not alter the ! 514: substructure of X. If it transforms X into a more legitimate ! 515: form, it should assign X (which will always be a C variable) a ! 516: new value. ! 517: ! 518: It is not necessary for this macro to come up with a legitimate ! 519: address. The compiler has standard ways of doing so in all ! 520: cases. In fact, it is safe for this macro to do nothing. But ! 521: often a machine-dependent strategy can generate better code. ! 522: ! 523: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' ! 524: A C statement or compound statement with a conditional `goto ! 525: LABEL;' executed if memory address X (an RTX) can have different ! 526: meanings depending on the machine mode of the memory reference ! 527: it is used for. ! 528: ! 529: Autoincrement and autodecrement addresses typically have ! 530: mode-dependent effects because the amount of the increment or ! 531: decrement is the size of the operand being addressed. Some ! 532: machines have other mode-dependent addresses. Many RISC ! 533: machines have no mode-dependent addresses. ! 534: ! 535: You may assume that ADDR is a valid address for the machine. ! 536: ! 537: `LEGITIMATE_CONSTANT_P (X)' ! 538: A C expression that is nonzero if X is a legitimate constant for ! 539: an immediate operand on the target machine. You can assume that ! 540: either X is a `const_double' or it satisfies `CONSTANT_P', so ! 541: you need not check these things. In fact, `1' is a suitable ! 542: definition for this macro on machines where any `const_double' ! 543: is valid and anything `CONSTANT_P' is valid. ! 544: ! 545: ! 546: ! 547: File: gcc.info, Node: Misc, Next: Condition Code, Prev: Addressing Modes, Up: Machine Macros ! 548: ! 549: Miscellaneous Parameters ! 550: ======================== ! 551: ! 552: `CASE_VECTOR_MODE' ! 553: An alias for a machine mode name. This is the machine mode that ! 554: elements of a jump-table should have. ! 555: ! 556: `CASE_VECTOR_PC_RELATIVE' ! 557: Define this macro if jump-tables should contain relative ! 558: addresses. ! 559: ! 560: `CASE_DROPS_THROUGH' ! 561: Define this if control falls through a `case' insn when the ! 562: index value is out of range. This means the specified ! 563: default-label is actually ignored by the `case' insn proper. ! 564: ! 565: `IMPLICIT_FIX_EXPR' ! 566: An alias for a tree code that should be used by default for ! 567: conversion of floating point values to fixed point. Normally, ! 568: `FIX_ROUND_EXPR' is used. ! 569: ! 570: `FIXUNS_TRUNC_LIKE_FIX_TRUNC' ! 571: Define this macro if the same instructions that convert a ! 572: floating point number to a signed fixed point number also ! 573: convert validly to an unsigned one. ! 574: ! 575: `EASY_DIV_EXPR' ! 576: An alias for a tree code that is the easiest kind of division to ! 577: compile code for in the general case. It may be ! 578: `TRUNC_DIV_EXPR', `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or ! 579: `ROUND_DIV_EXPR'. These four division operators differ in how ! 580: they round the result to an integer. `EASY_DIV_EXPR' is used ! 581: when it is permissible to use any of those kinds of division and ! 582: the choice should be made on the basis of efficiency. ! 583: ! 584: `DEFAULT_SIGNED_CHAR' ! 585: An expression whose value is 1 or 0, according to whether the ! 586: type `char' should be signed or unsigned by default. The user ! 587: can always override this default with the options ! 588: `-fsigned-char' and `-funsigned-char'. ! 589: ! 590: `SCCS_DIRECTIVE' ! 591: Define this if the preprocessor should ignore `#sccs' directives ! 592: and print no error message. ! 593: ! 594: `IDENT_DIRECTIVE' ! 595: Define this if the preprocessor should ignore `#ident' ! 596: directives and print no error message. ! 597: ! 598: `MOVE_MAX' ! 599: The maximum number of bytes that a single instruction can move ! 600: quickly from memory to memory. ! 601: ! 602: `INT_TYPE_SIZE' ! 603: A C expression for the size in bits of the type `int' on the ! 604: target machine. ! 605: ! 606: `SLOW_BYTE_ACCESS' ! 607: Define this macro as a C expression which is nonzero if ! 608: accessing less than a word of memory (i.e. a `char' or a ! 609: `short') is slow (requires more than one instruction). ! 610: ! 611: `SLOW_ZERO_EXTEND' ! 612: Define this macro if zero-extension (of a `char' or `short' to ! 613: an `int') can be done faster if the destination is a register ! 614: that is known to be zero. ! 615: ! 616: If you define this macro, you must have instruction patterns ! 617: that recognize RTL structures like this: ! 618: ! 619: (set (strict-low-part (subreg:QI (reg:SI ...) 0)) ...) ! 620: ! 621: and likewise for `HImode'. ! 622: ! 623: `SHIFT_COUNT_TRUNCATED' ! 624: Define this macro if shift instructions ignore all but the ! 625: lowest few bits of the shift count. It implies that a ! 626: sign-extend or zero-extend instruction for the shift count can ! 627: be omitted. ! 628: ! 629: `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)' ! 630: A C expression which is nonzero if on this machine it is safe to ! 631: ``convert'' an integer of INPREC bits to one of OUTPREC bits ! 632: (where OUTPREC is smaller than INPREC) by merely operating on it ! 633: as if it had only OUTPREC bits. ! 634: ! 635: On many machines, this expression can be 1. ! 636: ! 637: `NO_FUNCTION_CSE' ! 638: Define this macro if it is as good or better to call a constant ! 639: function address than to call an address kept in a register. ! 640: ! 641: `PROMOTE_PROTOTYPES' ! 642: Define this macro if an argument declared as `char' or `short' ! 643: in a prototype should actually be passed as an `int'. In ! 644: addition to avoiding errors in certain cases of mismatch, it ! 645: also makes for better code on certain machines. ! 646: ! 647: `STORE_FLAG_VALUE' ! 648: A C expression for the value stored by a store-flag instruction ! 649: (`sCOND') when the condition is true. This is usually 1 or -1; ! 650: it is required to be an odd number. ! 651: ! 652: Do not define `STORE_FLAG_VALUE' if the machine has no ! 653: store-flag instructions. ! 654: ! 655: `Pmode' ! 656: An alias for the machine mode for pointers. Normally the ! 657: definition can be ! 658: ! 659: #define Pmode SImode ! 660: ! 661: `FUNCTION_MODE' ! 662: An alias for the machine mode used for memory references to ! 663: functions being called, in `call' RTL expressions. On most ! 664: machines this should be `QImode'. ! 665: ! 666: `INSN_MACHINE_INFO' ! 667: This macro should expand into a C structure type to use for the ! 668: machine-dependent info field specified with the optional last ! 669: argument in `define_insn' and `define_peephole' patterns. For ! 670: example, it might expand into `struct machine_info'; then it ! 671: would be up to you to define this structure in the `tm.h' file. ! 672: ! 673: You do not need to define this macro if you do not write the ! 674: optional last argument in any of the patterns in the machine ! 675: description. ! 676: ! 677: `CONST_COSTS (X, CODE)' ! 678: A part of a C `switch' statement that describes the relative ! 679: costs of constant RTL expressions. It must contain `case' ! 680: labels for expression codes `const_int', `const', `symbol_ref', ! 681: `label_ref' and `const_double'. Each case must ultimately reach ! 682: a `return' statement to return the relative cost of the use of ! 683: that kind of constant value in an expression. The cost may ! 684: depend on the precise value of the constant, which is available ! 685: for examination in X. ! 686: ! 687: CODE is the expression code--redundant, since it can be obtained ! 688: with `GET_CODE (X)'. ! 689: ! 690: `DOLLARS_IN_IDENTIFIERS' ! 691: Define this to be nonzero if the character `$' should be allowed ! 692: by default in identifier names. ! 693: ! 694: ! 695: ! 696: File: gcc.info, Node: Condition Code, Next: Assembler Format, Prev: Misc, Up: Machine Macros ! 697: ! 698: Condition Code Information ! 699: ========================== ! 700: ! 701: The file `conditions.h' defines a variable `cc_status' to describe ! 702: how the condition code was computed (in case the interpretation of ! 703: the condition code depends on the instruction that it was set by). ! 704: This variable contains the RTL expressions on which the condition ! 705: code is currently based, and several standard flags. ! 706: ! 707: Sometimes additional machine-specific flags must be defined in the ! 708: machine description header file. It can also add additional ! 709: machine-specific information by defining `CC_STATUS_MDEP'. ! 710: ! 711: `CC_STATUS_MDEP' ! 712: C code for a data type which is used for declaring the `mdep' ! 713: component of `cc_status'. It defaults to `int'. ! 714: ! 715: `CC_STATUS_MDEP_INIT' ! 716: A C expression for the initial value of the `mdep' field. It ! 717: defaults to 0. ! 718: ! 719: `NOTICE_UPDATE_CC (EXP, INSN)' ! 720: A C compound statement to set the components of `cc_status' ! 721: appropriately for an insn INSN whose body is EXP. It is this ! 722: macro's responsibility to recognize insns that set the condition ! 723: code as a byproduct of other activity as well as those that ! 724: explicitly set `(cc0)'. ! 725: ! 726: If there are insn that do not set the condition code but do ! 727: alter other machine registers, this macro must check to see ! 728: whether they invalidate the expressions that the condition code ! 729: is recorded as reflecting. For example, on the 68000, insns ! 730: that store in address registers do not set the condition code, ! 731: which means that usually `NOTICE_UPDATE_CC' can leave ! 732: `cc_status' unaltered for such insns. But suppose that the ! 733: previous insn set the condition code based on location ! 734: `a4@(102)' and the current insn stores a new value in `a4'. ! 735: Although the condition code is not changed by this, it will no ! 736: longer be true that it reflects the contents of `a4@(102)'. ! 737: Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this ! 738: case to say that nothing is known about the condition code value. ! 739: ! 740: The definition of `NOTICE_UPDATE_CC' must be prepared to deal ! 741: with the results of peephole optimization: insns whose patterns ! 742: are `parallel' RTXs containing various `reg', `mem' or constants ! 743: which are just the operands. The RTL structure of these insns ! 744: is not sufficient to indicate what the insns actually do. What ! 745: `NOTICE_UPDATE_CC' should do when it sees one is just to run ! 746: `CC_STATUS_INIT'. ! 747: ! 748:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.