![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-22 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-22 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 ! root 1: This is Info file gcc.info, produced by Makeinfo version 1.67 from the ! 2: input file gcc.texi. 1.1 root 3: 4: This file documents the use and the internals of the GNU compiler. 5: 1.1.1.4 root 6: Published by the Free Software Foundation 59 Temple Place - Suite 330 7: Boston, MA 02111-1307 USA 1.1 root 8: 1.1.1.4 root 9: Copyright (C) 1988, 1989, 1992, 1993, 1994, 1995 Free Software 10: Foundation, Inc. 1.1 root 11: 12: Permission is granted to make and distribute verbatim copies of this 13: manual provided the copyright notice and this permission notice are 14: preserved on all copies. 15: 16: Permission is granted to copy and distribute modified versions of 17: this manual under the conditions for verbatim copying, provided also 1.1.1.3 root 18: that the sections entitled "GNU General Public License," "Funding for 19: Free Software," and "Protect Your Freedom--Fight `Look And Feel'" are 20: included exactly as in the original, and provided that the entire 21: resulting derived work is distributed under the terms of a permission 22: notice identical to this one. 1.1 root 23: 24: Permission is granted to copy and distribute translations of this 25: manual into another language, under the above conditions for modified 26: versions, except that the sections entitled "GNU General Public 1.1.1.3 root 27: License," "Funding for Free Software," and "Protect Your Freedom--Fight 28: `Look And Feel'", and this permission notice, may be included in 29: translations approved by the Free Software Foundation instead of in the 30: original English. 31: 32: 1.1.1.4 root 33: File: gcc.info, Node: Library Calls, Next: Addressing Modes, Prev: Trampolines, Up: Target Macros 1.1.1.3 root 34: 1.1.1.4 root 35: Implicit Calls to Library Routines 36: ================================== 1.1.1.3 root 37: 1.1.1.4 root 38: Here is an explanation of implicit calls to library routines. 1.1.1.3 root 39: 1.1.1.4 root 40: `MULSI3_LIBCALL' 41: A C string constant giving the name of the function to call for 42: multiplication of one signed full-word by another. If you do not 43: define this macro, the default name is used, which is `__mulsi3', 44: a function defined in `libgcc.a'. 45: 46: `DIVSI3_LIBCALL' 47: A C string constant giving the name of the function to call for 48: division of one signed full-word by another. If you do not define 49: this macro, the default name is used, which is `__divsi3', a 50: function defined in `libgcc.a'. 51: 52: `UDIVSI3_LIBCALL' 53: A C string constant giving the name of the function to call for 54: division of one unsigned full-word by another. If you do not 55: define this macro, the default name is used, which is `__udivsi3', 56: a function defined in `libgcc.a'. 57: 58: `MODSI3_LIBCALL' 59: A C string constant giving the name of the function to call for the 60: remainder in division of one signed full-word by another. If you 61: do not define this macro, the default name is used, which is 62: `__modsi3', a function defined in `libgcc.a'. 63: 64: `UMODSI3_LIBCALL' 65: A C string constant giving the name of the function to call for the 66: remainder in division of one unsigned full-word by another. If 67: you do not define this macro, the default name is used, which is 68: `__umodsi3', a function defined in `libgcc.a'. 69: 70: `MULDI3_LIBCALL' 71: A C string constant giving the name of the function to call for 72: multiplication of one signed double-word by another. If you do not 73: define this macro, the default name is used, which is `__muldi3', 74: a function defined in `libgcc.a'. 75: 76: `DIVDI3_LIBCALL' 77: A C string constant giving the name of the function to call for 78: division of one signed double-word by another. If you do not 79: define this macro, the default name is used, which is `__divdi3', a 80: function defined in `libgcc.a'. 81: 82: `UDIVDI3_LIBCALL' 83: A C string constant giving the name of the function to call for 84: division of one unsigned full-word by another. If you do not 85: define this macro, the default name is used, which is `__udivdi3', 86: a function defined in `libgcc.a'. 87: 88: `MODDI3_LIBCALL' 89: A C string constant giving the name of the function to call for the 90: remainder in division of one signed double-word by another. If 91: you do not define this macro, the default name is used, which is 92: `__moddi3', a function defined in `libgcc.a'. 93: 94: `UMODDI3_LIBCALL' 95: A C string constant giving the name of the function to call for the 96: remainder in division of one unsigned full-word by another. If 97: you do not define this macro, the default name is used, which is 98: `__umoddi3', a function defined in `libgcc.a'. 99: 100: `INIT_TARGET_OPTABS' 101: Define this macro as a C statement that declares additional library 102: routines renames existing ones. `init_optabs' calls this macro 103: after initializing all the normal library routines. 104: 105: `TARGET_EDOM' 106: The value of `EDOM' on the target machine, as a C integer constant 107: expression. If you don't define this macro, GNU CC does not 108: attempt to deposit the value of `EDOM' into `errno' directly. 109: Look in `/usr/include/errno.h' to find the value of `EDOM' on your 110: system. 111: 112: If you do not define `TARGET_EDOM', then compiled code reports 113: domain errors by calling the library function and letting it 114: report the error. If mathematical functions on your system use 115: `matherr' when there is an error, then you should leave 116: `TARGET_EDOM' undefined so that `matherr' is used normally. 117: 118: `GEN_ERRNO_RTX' 119: Define this macro as a C expression to create an rtl expression 120: that refers to the global "variable" `errno'. (On certain systems, 121: `errno' may not actually be a variable.) If you don't define this 122: macro, a reasonable default is used. 123: 124: `TARGET_MEM_FUNCTIONS' 125: Define this macro if GNU CC should generate calls to the System V 126: (and ANSI C) library functions `memcpy' and `memset' rather than 127: the BSD functions `bcopy' and `bzero'. 128: 129: `LIBGCC_NEEDS_DOUBLE' 130: Define this macro if only `float' arguments cannot be passed to 131: library routines (so they must be converted to `double'). This 132: macro affects both how library calls are generated and how the 133: library routines in `libgcc1.c' accept their arguments. It is 134: useful on machines where floating and fixed point arguments are 135: passed differently, such as the i860. 136: 137: `FLOAT_ARG_TYPE' 138: Define this macro to override the type used by the library 139: routines to pick up arguments of type `float'. (By default, they 140: use a union of `float' and `int'.) 141: 142: The obvious choice would be `float'--but that won't work with 143: traditional C compilers that expect all arguments declared as 144: `float' to arrive as `double'. To avoid this conversion, the 145: library routines ask for the value as some other type and then 146: treat it as a `float'. 147: 148: On some systems, no other type will work for this. For these 149: systems, you must use `LIBGCC_NEEDS_DOUBLE' instead, to force 150: conversion of the values `double' before they are passed. 151: 152: `FLOATIFY (PASSED-VALUE)' 153: Define this macro to override the way library routines redesignate 154: a `float' argument as a `float' instead of the type it was passed 155: as. The default is an expression which takes the `float' field of 156: the union. 157: 158: `FLOAT_VALUE_TYPE' 159: Define this macro to override the type used by the library 160: routines to return values that ought to have type `float'. (By 161: default, they use `int'.) 162: 163: The obvious choice would be `float'--but that won't work with 164: traditional C compilers gratuitously convert values declared as 165: `float' into `double'. 166: 167: `INTIFY (FLOAT-VALUE)' 168: Define this macro to override the way the value of a 169: `float'-returning library routine should be packaged in order to 170: return it. These functions are actually declared to return type 171: `FLOAT_VALUE_TYPE' (normally `int'). 172: 173: These values can't be returned as type `float' because traditional 174: C compilers would gratuitously convert the value to a `double'. 175: 176: A local variable named `intify' is always available when the macro 177: `INTIFY' is used. It is a union of a `float' field named `f' and 178: a field named `i' whose type is `FLOAT_VALUE_TYPE' or `int'. 179: 180: If you don't define this macro, the default definition works by 181: copying the value through that union. 182: 183: `nongcc_SI_type' 184: Define this macro as the name of the data type corresponding to 185: `SImode' in the system's own C compiler. 186: 187: You need not define this macro if that type is `long int', as it 188: usually is. 189: 190: `nongcc_word_type' 191: Define this macro as the name of the data type corresponding to the 192: word_mode in the system's own C compiler. 193: 194: You need not define this macro if that type is `long int', as it 195: usually is. 196: 197: `perform_...' 198: Define these macros to supply explicit C statements to carry out 199: various arithmetic operations on types `float' and `double' in the 200: library routines in `libgcc1.c'. See that file for a full list of 201: these macros and their arguments. 202: 203: On most machines, you don't need to define any of these macros, 204: because the C compiler that comes with the system takes care of 205: doing them. 206: 207: `NEXT_OBJC_RUNTIME' 208: Define this macro to generate code for Objective C message sending 209: using the calling convention of the NeXT system. This calling 210: convention involves passing the object, the selector and the 211: method arguments all at once to the method-lookup library function. 212: 213: The default calling convention passes just the object and the 214: selector to the lookup function, which returns a pointer to the 215: method. 1.1.1.3 root 216: 217: 1.1.1.4 root 218: File: gcc.info, Node: Addressing Modes, Next: Condition Code, Prev: Library Calls, Up: Target Macros 1.1.1.3 root 219: 1.1.1.4 root 220: Addressing Modes 221: ================ 1.1.1.3 root 222: 1.1.1.4 root 223: This is about addressing modes. 1.1.1.3 root 224: 1.1.1.4 root 225: `HAVE_POST_INCREMENT' 226: Define this macro if the machine supports post-increment 227: addressing. 228: 229: `HAVE_PRE_INCREMENT' 230: `HAVE_POST_DECREMENT' 231: `HAVE_PRE_DECREMENT' 232: Similar for other kinds of addressing. 233: 234: `CONSTANT_ADDRESS_P (X)' 235: A C expression that is 1 if the RTX X is a constant which is a 236: valid address. On most machines, this can be defined as 237: `CONSTANT_P (X)', but a few machines are more restrictive in which 238: constant addresses are supported. 239: 240: `CONSTANT_P' accepts integer-values expressions whose values are 241: not explicitly known, such as `symbol_ref', `label_ref', and 242: `high' expressions and `const' arithmetic expressions, in addition 243: to `const_int' and `const_double' expressions. 244: 245: `MAX_REGS_PER_ADDRESS' 246: A number, the maximum number of registers that can appear in a 247: valid memory address. Note that it is up to you to specify a 248: value equal to the maximum number that `GO_IF_LEGITIMATE_ADDRESS' 249: would ever accept. 250: 251: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)' 252: A C compound statement with a conditional `goto LABEL;' executed 253: if X (an RTX) is a legitimate memory address on the target machine 254: for a memory operand of mode MODE. 255: 256: It usually pays to define several simpler macros to serve as 257: subroutines for this one. Otherwise it may be too complicated to 258: understand. 259: 260: This macro must exist in two variants: a strict variant and a 261: non-strict one. The strict variant is used in the reload pass. It 262: must be defined so that any pseudo-register that has not been 263: allocated a hard register is considered a memory reference. In 264: contexts where some kind of register is required, a pseudo-register 265: with no hard register must be rejected. 266: 267: The non-strict variant is used in other passes. It must be 268: defined to accept all pseudo-registers in every context where some 269: kind of register is required. 270: 271: Compiler source files that want to use the strict variant of this 272: macro define the macro `REG_OK_STRICT'. You should use an `#ifdef 273: REG_OK_STRICT' conditional to define the strict variant in that 274: case and the non-strict variant otherwise. 275: 276: Subroutines to check for acceptable registers for various purposes 277: (one for base registers, one for index registers, and so on) are 278: typically among the subroutines used to define 279: `GO_IF_LEGITIMATE_ADDRESS'. Then only these subroutine macros 280: need have two variants; the higher levels of macros may be the 281: same whether strict or not. 282: 283: Normally, constant addresses which are the sum of a `symbol_ref' 284: and an integer are stored inside a `const' RTX to mark them as 285: constant. Therefore, there is no need to recognize such sums 286: specifically as legitimate addresses. Normally you would simply 287: recognize any `const' as legitimate. 288: 289: Usually `PRINT_OPERAND_ADDRESS' is not prepared to handle constant 290: sums that are not marked with `const'. It assumes that a naked 291: `plus' indicates indexing. If so, then you *must* reject such 292: naked constant sums as illegitimate addresses, so that none of 293: them will be given to `PRINT_OPERAND_ADDRESS'. 294: 295: On some machines, whether a symbolic address is legitimate depends 296: on the section that the address refers to. On these machines, 297: define the macro `ENCODE_SECTION_INFO' to store the information 298: into the `symbol_ref', and then check for it here. When you see a 299: `const', you will have to look inside it to find the `symbol_ref' 300: in order to determine the section. *Note Assembler Format::. 301: 302: The best way to modify the name string is by adding text to the 303: beginning, with suitable punctuation to prevent any ambiguity. 304: Allocate the new name in `saveable_obstack'. You will have to 305: modify `ASM_OUTPUT_LABELREF' to remove and decode the added text 306: and output the name accordingly, and define `STRIP_NAME_ENCODING' 307: to access the original name string. 308: 309: You can check the information stored here into the `symbol_ref' in 310: the definitions of the macros `GO_IF_LEGITIMATE_ADDRESS' and 311: `PRINT_OPERAND_ADDRESS'. 312: 313: `REG_OK_FOR_BASE_P (X)' 314: A C expression that is nonzero if X (assumed to be a `reg' RTX) is 315: valid for use as a base register. For hard registers, it should 316: always accept those which the hardware permits and reject the 317: others. Whether the macro accepts or rejects pseudo registers 318: must be controlled by `REG_OK_STRICT' as described above. This 319: usually requires two variant definitions, of which `REG_OK_STRICT' 320: controls the one actually used. 321: 322: `REG_OK_FOR_INDEX_P (X)' 323: A C expression that is nonzero if X (assumed to be a `reg' RTX) is 324: valid for use as an index register. 325: 326: The difference between an index register and a base register is 327: that the index register may be scaled. If an address involves the 328: sum of two registers, neither one of them scaled, then either one 329: may be labeled the "base" and the other the "index"; but whichever 330: labeling is used must fit the machine's constraints of which 331: registers may serve in each capacity. The compiler will try both 332: labelings, looking for one that is valid, and will reload one or 333: both registers only if neither labeling works. 334: 335: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)' 336: A C compound statement that attempts to replace X with a valid 337: memory address for an operand of mode MODE. WIN will be a C 338: statement label elsewhere in the code; the macro definition may use 339: 340: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN); 341: 342: to avoid further processing if the address has become legitimate. 343: 344: X will always be the result of a call to `break_out_memory_refs', 345: and OLDX will be the operand that was given to that function to 346: produce X. 347: 348: The code generated by this macro should not alter the substructure 349: of X. If it transforms X into a more legitimate form, it should 350: assign X (which will always be a C variable) a new value. 351: 352: It is not necessary for this macro to come up with a legitimate 353: address. The compiler has standard ways of doing so in all cases. 354: In fact, it is safe for this macro to do nothing. But often a 355: machine-dependent strategy can generate better code. 356: 357: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)' 358: A C statement or compound statement with a conditional `goto 359: LABEL;' executed if memory address X (an RTX) can have different 360: meanings depending on the machine mode of the memory reference it 361: is used for or if the address is valid for some modes but not 362: others. 363: 364: Autoincrement and autodecrement addresses typically have 365: mode-dependent effects because the amount of the increment or 366: decrement is the size of the operand being addressed. Some 367: machines have other mode-dependent addresses. Many RISC machines 368: have no mode-dependent addresses. 369: 370: You may assume that ADDR is a valid address for the machine. 371: 372: `LEGITIMATE_CONSTANT_P (X)' 373: A C expression that is nonzero if X is a legitimate constant for 374: an immediate operand on the target machine. You can assume that X 375: satisfies `CONSTANT_P', so you need not check this. In fact, `1' 376: is a suitable definition for this macro on machines where anything 377: `CONSTANT_P' is valid. 1.1.1.3 root 378: 379: 1.1.1.4 root 380: File: gcc.info, Node: Condition Code, Next: Costs, Prev: Addressing Modes, Up: Target Macros 1.1.1.3 root 381: 1.1.1.4 root 382: Condition Code Status 383: ===================== 1.1.1.3 root 384: 1.1.1.4 root 385: This describes the condition code status. 1.1.1.3 root 386: 1.1.1.4 root 387: The file `conditions.h' defines a variable `cc_status' to describe 388: how the condition code was computed (in case the interpretation of the 389: condition code depends on the instruction that it was set by). This 390: variable contains the RTL expressions on which the condition code is 391: currently based, and several standard flags. 392: 393: Sometimes additional machine-specific flags must be defined in the 394: machine description header file. It can also add additional 395: machine-specific information by defining `CC_STATUS_MDEP'. 396: 397: `CC_STATUS_MDEP' 398: C code for a data type which is used for declaring the `mdep' 399: component of `cc_status'. It defaults to `int'. 400: 401: This macro is not used on machines that do not use `cc0'. 402: 403: `CC_STATUS_MDEP_INIT' 404: A C expression to initialize the `mdep' field to "empty". The 405: default definition does nothing, since most machines don't use the 406: field anyway. If you want to use the field, you should probably 407: define this macro to initialize it. 408: 409: This macro is not used on machines that do not use `cc0'. 410: 411: `NOTICE_UPDATE_CC (EXP, INSN)' 412: A C compound statement to set the components of `cc_status' 413: appropriately for an insn INSN whose body is EXP. It is this 414: macro's responsibility to recognize insns that set the condition 415: code as a byproduct of other activity as well as those that 416: explicitly set `(cc0)'. 417: 418: This macro is not used on machines that do not use `cc0'. 419: 420: If there are insns that do not set the condition code but do alter 421: other machine registers, this macro must check to see whether they 422: invalidate the expressions that the condition code is recorded as 423: reflecting. For example, on the 68000, insns that store in address 424: registers do not set the condition code, which means that usually 425: `NOTICE_UPDATE_CC' can leave `cc_status' unaltered for such insns. 426: But suppose that the previous insn set the condition code based 427: on location `a4@(102)' and the current insn stores a new value in 428: `a4'. Although the condition code is not changed by this, it will 429: no longer be true that it reflects the contents of `a4@(102)'. 430: Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this case 431: to say that nothing is known about the condition code value. 432: 433: The definition of `NOTICE_UPDATE_CC' must be prepared to deal with 434: the results of peephole optimization: insns whose patterns are 435: `parallel' RTXs containing various `reg', `mem' or constants which 436: are just the operands. The RTL structure of these insns is not 437: sufficient to indicate what the insns actually do. What 438: `NOTICE_UPDATE_CC' should do when it sees one is just to run 439: `CC_STATUS_INIT'. 440: 441: A possible definition of `NOTICE_UPDATE_CC' is to call a function 442: that looks at an attribute (*note Insn Attributes::.) named, for 443: example, `cc'. This avoids having detailed information about 444: patterns in two places, the `md' file and in `NOTICE_UPDATE_CC'. 445: 446: `EXTRA_CC_MODES' 447: A list of names to be used for additional modes for condition code 448: values in registers (*note Jump Patterns::.). These names are 449: added to `enum machine_mode' and all have class `MODE_CC'. By 450: convention, they should start with `CC' and end with `mode'. 451: 452: You should only define this macro if your machine does not use 453: `cc0' and only if additional modes are required. 454: 455: `EXTRA_CC_NAMES' 456: A list of C strings giving the names for the modes listed in 457: `EXTRA_CC_MODES'. For example, the Sparc defines this macro and 458: `EXTRA_CC_MODES' as 459: 460: #define EXTRA_CC_MODES CC_NOOVmode, CCFPmode, CCFPEmode 461: #define EXTRA_CC_NAMES "CC_NOOV", "CCFP", "CCFPE" 462: 463: This macro is not required if `EXTRA_CC_MODES' is not defined. 464: 465: `SELECT_CC_MODE (OP, X, Y)' 466: Returns a mode from class `MODE_CC' to be used when comparison 467: operation code OP is applied to rtx X and Y. For example, on the 468: Sparc, `SELECT_CC_MODE' is defined as (see *note Jump Patterns::. 469: for a description of the reason for this definition) 470: 471: #define SELECT_CC_MODE(OP,X,Y) \ 472: (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT \ 473: ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode) \ 474: : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \ 475: || GET_CODE (X) == NEG) \ 476: ? CC_NOOVmode : CCmode)) 477: 478: You need not define this macro if `EXTRA_CC_MODES' is not defined. 479: 480: `CANONICALIZE_COMPARISON (CODE, OP0, OP1)' 481: One some machines not all possible comparisons are defined, but 482: you can convert an invalid comparison into a valid one. For 483: example, the Alpha does not have a `GT' comparison, but you can 484: use an `LT' comparison instead and swap the order of the operands. 485: 486: On such machines, define this macro to be a C statement to do any 487: required conversions. CODE is the initial comparison code and OP0 488: and OP1 are the left and right operands of the comparison, 489: respectively. You should modify CODE, OP0, and OP1 as required. 490: 491: GNU CC will not assume that the comparison resulting from this 492: macro is valid but will see if the resulting insn matches a 493: pattern in the `md' file. 494: 495: You need not define this macro if it would never change the 496: comparison code or operands. 497: 498: `REVERSIBLE_CC_MODE (MODE)' 499: A C expression whose value is one if it is always safe to reverse a 500: comparison whose mode is MODE. If `SELECT_CC_MODE' can ever 501: return MODE for a floating-point inequality comparison, then 502: `REVERSIBLE_CC_MODE (MODE)' must be zero. 503: 504: You need not define this macro if it would always returns zero or 505: if the floating-point format is anything other than 506: `IEEE_FLOAT_FORMAT'. For example, here is the definition used on 507: the Sparc, where floating-point inequality comparisons are always 508: given `CCFPEmode': 1.1.1.3 root 509: 1.1.1.4 root 510: #define REVERSIBLE_CC_MODE(MODE) ((MODE) != CCFPEmode) 1.1.1.3 root 511: 512: 1.1.1.4 root 513: File: gcc.info, Node: Costs, Next: Sections, Prev: Condition Code, Up: Target Macros 1.1.1.3 root 514: 1.1.1.4 root 515: Describing Relative Costs of Operations 516: ======================================= 1.1.1.3 root 517: 1.1.1.4 root 518: These macros let you describe the relative speed of various 519: operations on the target machine. 1.1.1.3 root 520: 1.1.1.4 root 521: `CONST_COSTS (X, CODE, OUTER_CODE)' 522: A part of a C `switch' statement that describes the relative costs 523: of constant RTL expressions. It must contain `case' labels for 524: expression codes `const_int', `const', `symbol_ref', `label_ref' 525: and `const_double'. Each case must ultimately reach a `return' 526: statement to return the relative cost of the use of that kind of 527: constant value in an expression. The cost may depend on the 528: precise value of the constant, which is available for examination 529: in X, and the rtx code of the expression in which it is contained, 530: found in OUTER_CODE. 531: 532: CODE is the expression code--redundant, since it can be obtained 533: with `GET_CODE (X)'. 534: 535: `RTX_COSTS (X, CODE, OUTER_CODE)' 536: Like `CONST_COSTS' but applies to nonconstant RTL expressions. 537: This can be used, for example, to indicate how costly a multiply 538: instruction is. In writing this macro, you can use the construct 539: `COSTS_N_INSNS (N)' to specify a cost equal to N fast 540: instructions. OUTER_CODE is the code of the expression in which X 541: is contained. 542: 543: This macro is optional; do not define it if the default cost 544: assumptions are adequate for the target machine. 545: 546: `ADDRESS_COST (ADDRESS)' 547: An expression giving the cost of an addressing mode that contains 548: ADDRESS. If not defined, the cost is computed from the ADDRESS 549: expression and the `CONST_COSTS' values. 550: 551: For most CISC machines, the default cost is a good approximation 552: of the true cost of the addressing mode. However, on RISC 553: machines, all instructions normally have the same length and 554: execution time. Hence all addresses will have equal costs. 555: 556: In cases where more than one form of an address is known, the form 557: with the lowest cost will be used. If multiple forms have the 558: same, lowest, cost, the one that is the most complex will be used. 559: 560: For example, suppose an address that is equal to the sum of a 561: register and a constant is used twice in the same basic block. 562: When this macro is not defined, the address will be computed in a 563: register and memory references will be indirect through that 564: register. On machines where the cost of the addressing mode 565: containing the sum is no higher than that of a simple indirect 566: reference, this will produce an additional instruction and 567: possibly require an additional register. Proper specification of 568: this macro eliminates this overhead for such machines. 569: 570: Similar use of this macro is made in strength reduction of loops. 571: 572: ADDRESS need not be valid as an address. In such a case, the cost 573: is not relevant and can be any value; invalid addresses need not be 574: assigned a different cost. 575: 576: On machines where an address involving more than one register is as 577: cheap as an address computation involving only one register, 578: defining `ADDRESS_COST' to reflect this can cause two registers to 579: be live over a region of code where only one would have been if 580: `ADDRESS_COST' were not defined in that manner. This effect should 581: be considered in the definition of this macro. Equivalent costs 582: should probably only be given to addresses with different numbers 583: of registers on machines with lots of registers. 584: 585: This macro will normally either not be defined or be defined as a 586: constant. 587: 588: `REGISTER_MOVE_COST (FROM, TO)' 589: A C expression for the cost of moving data from a register in class 590: FROM to one in class TO. The classes are expressed using the 591: enumeration values such as `GENERAL_REGS'. A value of 4 is the 592: default; other values are interpreted relative to that. 593: 594: It is not required that the cost always equal 2 when FROM is the 595: same as TO; on some machines it is expensive to move between 596: registers if they are not general registers. 597: 598: If reload sees an insn consisting of a single `set' between two 599: hard registers, and if `REGISTER_MOVE_COST' applied to their 600: classes returns a value of 2, reload does not check to ensure that 601: the constraints of the insn are met. Setting a cost of other than 602: 2 will allow reload to verify that the constraints are met. You 603: should do this if the `movM' pattern's constraints do not allow 604: such copying. 605: 606: `MEMORY_MOVE_COST (M)' 607: A C expression for the cost of moving data of mode M between a 608: register and memory. A value of 2 is the default; this cost is 609: relative to those in `REGISTER_MOVE_COST'. 610: 611: If moving between registers and memory is more expensive than 612: between two registers, you should define this macro to express the 613: relative cost. 614: 615: `BRANCH_COST' 616: A C expression for the cost of a branch instruction. A value of 1 617: is the default; other values are interpreted relative to that. 618: 619: Here are additional macros which do not specify precise relative 620: costs, but only that certain actions are more expensive than GNU CC 621: would ordinarily expect. 622: 623: `SLOW_BYTE_ACCESS' 624: Define this macro as a C expression which is nonzero if accessing 625: less than a word of memory (i.e. a `char' or a `short') is no 626: faster than accessing a word of memory, i.e., if such access 627: require more than one instruction or if there is no difference in 628: cost between byte and (aligned) word loads. 629: 630: When this macro is not defined, the compiler will access a field by 631: finding the smallest containing object; when it is defined, a 632: fullword load will be used if alignment permits. Unless bytes 633: accesses are faster than word accesses, using word accesses is 634: preferable since it may eliminate subsequent memory access if 635: subsequent accesses occur to other fields in the same word of the 636: structure, but to different bytes. 637: 638: `SLOW_ZERO_EXTEND' 639: Define this macro if zero-extension (of a `char' or `short' to an 640: `int') can be done faster if the destination is a register that is 641: known to be zero. 642: 643: If you define this macro, you must have instruction patterns that 644: recognize RTL structures like this: 645: 646: (set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...) 647: 648: and likewise for `HImode'. 649: 650: `SLOW_UNALIGNED_ACCESS' 651: Define this macro to be the value 1 if unaligned accesses have a 652: cost many times greater than aligned accesses, for example if they 653: are emulated in a trap handler. 654: 655: When this macro is non-zero, the compiler will act as if 656: `STRICT_ALIGNMENT' were non-zero when generating code for block 657: moves. This can cause significantly more instructions to be 658: produced. Therefore, do not set this macro non-zero if unaligned 659: accesses only add a cycle or two to the time for a memory access. 660: 661: If the value of this macro is always zero, it need not be defined. 662: 663: `DONT_REDUCE_ADDR' 664: Define this macro to inhibit strength reduction of memory 665: addresses. (On some machines, such strength reduction seems to do 666: harm rather than good.) 667: 668: `MOVE_RATIO' 669: The number of scalar move insns which should be generated instead 670: of a string move insn or a library call. Increasing the value 671: will always make code faster, but eventually incurs high cost in 672: increased code size. 673: 674: If you don't define this, a reasonable default is used. 675: 676: `NO_FUNCTION_CSE' 677: Define this macro if it is as good or better to call a constant 678: function address than to call an address kept in a register. 679: 680: `NO_RECURSIVE_FUNCTION_CSE' 681: Define this macro if it is as good or better for a function to call 682: itself with an explicit address than to call an address kept in a 683: register. 684: 685: `ADJUST_COST (INSN, LINK, DEP_INSN, COST)' 686: A C statement (sans semicolon) to update the integer variable COST 687: based on the relationship between INSN that is dependent on 688: DEP_INSN through the dependence LINK. The default is to make no 689: adjustment to COST. This can be used for example to specify to 690: the scheduler that an output- or anti-dependence does not incur 691: the same cost as a data-dependence. 1.1.1.3 root 692: 693: 1.1.1.4 root 694: File: gcc.info, Node: Sections, Next: PIC, Prev: Costs, Up: Target Macros 1.1.1.3 root 695: 1.1.1.4 root 696: Dividing the Output into Sections (Texts, Data, ...) 697: ==================================================== 1.1.1.3 root 698: 1.1.1.4 root 699: An object file is divided into sections containing different types of 700: data. In the most common case, there are three sections: the "text 701: section", which holds instructions and read-only data; the "data 702: section", which holds initialized writable data; and the "bss section", 703: which holds uninitialized data. Some systems have other kinds of 704: sections. 705: 706: The compiler must tell the assembler when to switch sections. These 707: macros control what commands to output to tell the assembler this. You 708: can also define additional sections. 709: 710: `TEXT_SECTION_ASM_OP' 711: A C expression whose value is a string containing the assembler 712: operation that should precede instructions and read-only data. 713: Normally `".text"' is right. 714: 715: `DATA_SECTION_ASM_OP' 716: A C expression whose value is a string containing the assembler 717: operation to identify the following data as writable initialized 718: data. Normally `".data"' is right. 719: 720: `SHARED_SECTION_ASM_OP' 721: if defined, a C expression whose value is a string containing the 722: assembler operation to identify the following data as shared data. 723: If not defined, `DATA_SECTION_ASM_OP' will be used. 1.1.1.3 root 724: 1.1.1.4 root 725: `INIT_SECTION_ASM_OP' 726: if defined, a C expression whose value is a string containing the 727: assembler operation to identify the following data as 728: initialization code. If not defined, GNU CC will assume such a 729: section does not exist. 730: 731: `EXTRA_SECTIONS' 732: A list of names for sections other than the standard two, which are 733: `in_text' and `in_data'. You need not define this macro on a 734: system with no other sections (that GCC needs to use). 735: 736: `EXTRA_SECTION_FUNCTIONS' 737: One or more functions to be defined in `varasm.c'. These 738: functions should do jobs analogous to those of `text_section' and 739: `data_section', for your additional sections. Do not define this 740: macro if you do not define `EXTRA_SECTIONS'. 741: 742: `READONLY_DATA_SECTION' 743: On most machines, read-only variables, constants, and jump tables 744: are placed in the text section. If this is not the case on your 745: machine, this macro should be defined to be the name of a function 746: (either `data_section' or a function defined in `EXTRA_SECTIONS') 747: that switches to the section to be used for read-only items. 748: 749: If these items should be placed in the text section, this macro 750: should not be defined. 751: 752: `SELECT_SECTION (EXP, RELOC)' 753: A C statement or statements to switch to the appropriate section 754: for output of EXP. You can assume that EXP is either a `VAR_DECL' 755: node or a constant of some sort. RELOC indicates whether the 756: initial value of EXP requires link-time relocations. Select the 757: section by calling `text_section' or one of the alternatives for 758: other sections. 759: 760: Do not define this macro if you put all read-only variables and 761: constants in the read-only data section (usually the text section). 762: 763: `SELECT_RTX_SECTION (MODE, RTX)' 764: A C statement or statements to switch to the appropriate section 765: for output of RTX in mode MODE. You can assume that RTX is some 766: kind of constant in RTL. The argument MODE is redundant except in 767: the case of a `const_int' rtx. Select the section by calling 768: `text_section' or one of the alternatives for other sections. 769: 770: Do not define this macro if you put all constants in the read-only 771: data section. 772: 773: `JUMP_TABLES_IN_TEXT_SECTION' 774: Define this macro if jump tables (for `tablejump' insns) should be 775: output in the text section, along with the assembler instructions. 776: Otherwise, the readonly data section is used. 777: 778: This macro is irrelevant if there is no separate readonly data 779: section. 780: 781: `ENCODE_SECTION_INFO (DECL)' 782: Define this macro if references to a symbol must be treated 783: differently depending on something about the variable or function 784: named by the symbol (such as what section it is in). 785: 786: The macro definition, if any, is executed immediately after the 787: rtl for DECL has been created and stored in `DECL_RTL (DECL)'. 788: The value of the rtl will be a `mem' whose address is a 789: `symbol_ref'. 790: 791: The usual thing for this macro to do is to record a flag in the 792: `symbol_ref' (such as `SYMBOL_REF_FLAG') or to store a modified 793: name string in the `symbol_ref' (if one bit is not enough 794: information). 795: 796: `STRIP_NAME_ENCODING (VAR, SYM_NAME)' 797: Decode SYM_NAME and store the real name part in VAR, sans the 798: characters that encode section info. Define this macro if 799: `ENCODE_SECTION_INFO' alters the symbol's name string. 1.1.1.3 root 800: 801: 1.1.1.4 root 802: File: gcc.info, Node: PIC, Next: Assembler Format, Prev: Sections, Up: Target Macros 1.1.1.3 root 803: 1.1.1.4 root 804: Position Independent Code 805: ========================= 1.1.1.3 root 806: 1.1.1.4 root 807: This section describes macros that help implement generation of 808: position independent code. Simply defining these macros is not enough 809: to generate valid PIC; you must also add support to the macros 810: `GO_IF_LEGITIMATE_ADDRESS' and `PRINT_OPERAND_ADDRESS', as well as 811: `LEGITIMIZE_ADDRESS'. You must modify the definition of `movsi' to do 812: something appropriate when the source operand contains a symbolic 813: address. You may also need to alter the handling of switch statements 814: so that they use relative addresses. 815: 816: `PIC_OFFSET_TABLE_REGNUM' 817: The register number of the register used to address a table of 818: static data addresses in memory. In some cases this register is 819: defined by a processor's "application binary interface" (ABI). 820: When this macro is defined, RTL is generated for this register 821: once, as with the stack pointer and frame pointer registers. If 822: this macro is not defined, it is up to the machine-dependent files 823: to allocate such a register (if necessary). 824: 825: `PIC_OFFSET_TABLE_REG_CALL_CLOBBERED' 826: Define this macro if the register defined by 827: `PIC_OFFSET_TABLE_REGNUM' is clobbered by calls. Do not define 828: this macro if `PPIC_OFFSET_TABLE_REGNUM' is not defined. 829: 830: `FINALIZE_PIC' 831: By generating position-independent code, when two different 832: programs (A and B) share a common library (libC.a), the text of 833: the library can be shared whether or not the library is linked at 834: the same address for both programs. In some of these 835: environments, position-independent code requires not only the use 836: of different addressing modes, but also special code to enable the 837: use of these addressing modes. 838: 839: The `FINALIZE_PIC' macro serves as a hook to emit these special 840: codes once the function is being compiled into assembly code, but 841: not before. (It is not done before, because in the case of 842: compiling an inline function, it would lead to multiple PIC 843: prologues being included in functions which used inline functions 844: and were compiled to assembly language.) 845: 846: `LEGITIMATE_PIC_OPERAND_P (X)' 847: A C expression that is nonzero if X is a legitimate immediate 848: operand on the target machine when generating position independent 849: code. You can assume that X satisfies `CONSTANT_P', so you need 850: not check this. You can also assume FLAG_PIC is true, so you need 851: not check it either. You need not define this macro if all 852: constants (including `SYMBOL_REF') can be immediate operands when 853: generating position independent code. 1.1.1.3 root 854: 855: 1.1.1.4 root 856: File: gcc.info, Node: Assembler Format, Next: Debugging Info, Prev: PIC, Up: Target Macros 1.1.1.3 root 857: 1.1.1.4 root 858: Defining the Output Assembler Language 859: ====================================== 1.1.1.3 root 860: 1.1.1.4 root 861: This section describes macros whose principal purpose is to describe 862: how to write instructions in assembler language-rather than what the 863: instructions do. 1.1.1.3 root 864: 1.1.1.4 root 865: * Menu: 1.1.1.3 root 866: 1.1.1.4 root 867: * File Framework:: Structural information for the assembler file. 868: * Data Output:: Output of constants (numbers, strings, addresses). 869: * Uninitialized Data:: Output of uninitialized variables. 870: * Label Output:: Output and generation of labels. 871: * Initialization:: General principles of initialization 872: and termination routines. 873: * Macros for Initialization:: 874: Specific macros that control the handling of 875: initialization and termination routines. 876: * Instruction Output:: Output of actual instructions. 877: * Dispatch Tables:: Output of jump tables. 878: * Alignment Output:: Pseudo ops for alignment and skipping data. 1.1.1.3 root 879: 880: 1.1.1.4 root 881: File: gcc.info, Node: File Framework, Next: Data Output, Up: Assembler Format 1.1.1.3 root 882: 1.1.1.4 root 883: The Overall Framework of an Assembler File 884: ------------------------------------------ 1.1.1.3 root 885: 1.1.1.4 root 886: This describes the overall framework of an assembler file. 1.1.1.3 root 887: 1.1.1.4 root 888: `ASM_FILE_START (STREAM)' 889: A C expression which outputs to the stdio stream STREAM some 890: appropriate text to go at the start of an assembler file. 891: 892: Normally this macro is defined to output a line containing 893: `#NO_APP', which is a comment that has no effect on most 894: assemblers but tells the GNU assembler that it can save time by not 895: checking for certain assembler constructs. 896: 897: On systems that use SDB, it is necessary to output certain 898: commands; see `attasm.h'. 899: 900: `ASM_FILE_END (STREAM)' 901: A C expression which outputs to the stdio stream STREAM some 902: appropriate text to go at the end of an assembler file. 903: 904: If this macro is not defined, the default is to output nothing 905: special at the end of the file. Most systems don't require any 906: definition. 907: 908: On systems that use SDB, it is necessary to output certain 909: commands; see `attasm.h'. 910: 911: `ASM_IDENTIFY_GCC (FILE)' 912: A C statement to output assembler commands which will identify the 913: object file as having been compiled with GNU CC (or another GNU 914: compiler). 915: 916: If you don't define this macro, the string `gcc_compiled.:' is 917: output. This string is calculated to define a symbol which, on 918: BSD systems, will never be defined for any other reason. GDB 919: checks for the presence of this symbol when reading the symbol 920: table of an executable. 921: 922: On non-BSD systems, you must arrange communication with GDB in 923: some other fashion. If GDB is not used on your system, you can 924: define this macro with an empty body. 925: 926: `ASM_COMMENT_START' 927: A C string constant describing how to begin a comment in the target 928: assembler language. The compiler assumes that the comment will 929: end at the end of the line. 930: 931: `ASM_APP_ON' 932: A C string constant for text to be output before each `asm' 933: statement or group of consecutive ones. Normally this is 934: `"#APP"', which is a comment that has no effect on most assemblers 935: but tells the GNU assembler that it must check the lines that 936: follow for all valid assembler constructs. 937: 938: `ASM_APP_OFF' 939: A C string constant for text to be output after each `asm' 940: statement or group of consecutive ones. Normally this is 941: `"#NO_APP"', which tells the GNU assembler to resume making the 942: time-saving assumptions that are valid for ordinary compiler 943: output. 944: 945: `ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)' 946: A C statement to output COFF information or DWARF debugging 947: information which indicates that filename NAME is the current 948: source file to the stdio stream STREAM. 1.1.1.3 root 949: 950: This macro need not be defined if the standard form of output for 1.1.1.4 root 951: the file format in use is appropriate. 1.1.1.3 root 952: 1.1.1.4 root 953: `ASM_OUTPUT_SOURCE_LINE (STREAM, LINE)' 954: A C statement to output DBX or SDB debugging information before 955: code for line number LINE of the current source file to the stdio 956: stream STREAM. 957: 958: This macro need not be defined if the standard form of debugging 959: information for the debugger in use is appropriate. 960: 961: `ASM_OUTPUT_IDENT (STREAM, STRING)' 962: A C statement to output something to the assembler file to handle a 963: `#ident' directive containing the text STRING. If this macro is 964: not defined, nothing is output for a `#ident' directive. 965: 966: `ASM_OUTPUT_SECTION_NAME (STREAM, DECL, NAME)' 967: A C statement to output something to the assembler file to switch 968: to section NAME for object DECL which is either a `FUNCTION_DECL', 969: a `VAR_DECL' or `NULL_TREE'. Some target formats do not support 970: arbitrary sections. Do not define this macro in such cases. 971: 972: At present this macro is only used to support section attributes. 973: When this macro is undefined, section attributes are disabled. 974: 975: `OBJC_PROLOGUE' 976: A C statement to output any assembler statements which are 977: required to precede any Objective C object definitions or message 978: sending. The statement is executed only when compiling an 979: Objective C program. 1.1.1.3 root 980: 1.1.1.4 root 981: 982: File: gcc.info, Node: Data Output, Next: Uninitialized Data, Prev: File Framework, Up: Assembler Format 1.1.1.3 root 983: 1.1.1.4 root 984: Output of Data 985: -------------- 1.1.1.3 root 986: 1.1.1.4 root 987: This describes data output. 1.1.1.3 root 988: 1.1.1.4 root 989: `ASM_OUTPUT_LONG_DOUBLE (STREAM, VALUE)' 990: `ASM_OUTPUT_DOUBLE (STREAM, VALUE)' 991: `ASM_OUTPUT_FLOAT (STREAM, VALUE)' 992: `ASM_OUTPUT_THREE_QUARTER_FLOAT (STREAM, VALUE)' 993: `ASM_OUTPUT_SHORT_FLOAT (STREAM, VALUE)' 994: `ASM_OUTPUT_BYTE_FLOAT (STREAM, VALUE)' 995: A C statement to output to the stdio stream STREAM an assembler 996: instruction to assemble a floating-point constant of `TFmode', 997: `DFmode', `SFmode', `TQFmode', `HFmode', or `QFmode', 998: respectively, whose value is VALUE. VALUE will be a C expression 999: of type `REAL_VALUE_TYPE'. Macros such as 1000: `REAL_VALUE_TO_TARGET_DOUBLE' are useful for writing these 1001: definitions. 1002: 1003: `ASM_OUTPUT_QUADRUPLE_INT (STREAM, EXP)' 1004: `ASM_OUTPUT_DOUBLE_INT (STREAM, EXP)' 1005: `ASM_OUTPUT_INT (STREAM, EXP)' 1006: `ASM_OUTPUT_SHORT (STREAM, EXP)' 1007: `ASM_OUTPUT_CHAR (STREAM, EXP)' 1008: A C statement to output to the stdio stream STREAM an assembler 1009: instruction to assemble an integer of 16, 8, 4, 2 or 1 bytes, 1010: respectively, whose value is VALUE. The argument EXP will be an 1011: RTL expression which represents a constant value. Use 1012: `output_addr_const (STREAM, EXP)' to output this value as an 1013: assembler expression. 1014: 1015: For sizes larger than `UNITS_PER_WORD', if the action of a macro 1016: would be identical to repeatedly calling the macro corresponding to 1017: a size of `UNITS_PER_WORD', once for each word, you need not define 1018: the macro. 1.1.1.3 root 1019: 1.1.1.4 root 1020: `ASM_OUTPUT_BYTE (STREAM, VALUE)' 1021: A C statement to output to the stdio stream STREAM an assembler 1022: instruction to assemble a single byte containing the number VALUE. 1.1.1.3 root 1023: 1.1.1.4 root 1024: `ASM_BYTE_OP' 1025: A C string constant giving the pseudo-op to use for a sequence of 1026: single-byte constants. If this macro is not defined, the default 1027: is `"byte"'. 1.1.1.3 root 1028: 1.1.1.4 root 1029: `ASM_OUTPUT_ASCII (STREAM, PTR, LEN)' 1030: A C statement to output to the stdio stream STREAM an assembler 1031: instruction to assemble a string constant containing the LEN bytes 1032: at PTR. PTR will be a C expression of type `char *' and LEN a C 1033: expression of type `int'. 1.1.1.3 root 1034: 1.1.1.4 root 1035: If the assembler has a `.ascii' pseudo-op as found in the Berkeley 1036: Unix assembler, do not define the macro `ASM_OUTPUT_ASCII'. 1.1.1.3 root 1037: 1.1.1.4 root 1038: `ASM_OUTPUT_POOL_PROLOGUE (FILE FUNNAME FUNDECL SIZE)' 1039: A C statement to output assembler commands to define the start of 1040: the constant pool for a function. FUNNAME is a string giving the 1041: name of the function. Should the return type of the function be 1042: required, it can be obtained via FUNDECL. SIZE is the size, in 1043: bytes, of the constant pool that will be written immediately after 1044: this call. 1045: 1046: If no constant-pool prefix is required, the usual case, this macro 1047: need not be defined. 1048: 1049: `ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO, JUMPTO)' 1050: A C statement (with or without semicolon) to output a constant in 1051: the constant pool, if it needs special treatment. (This macro 1052: need not do anything for RTL expressions that can be output 1053: normally.) 1054: 1055: The argument FILE is the standard I/O stream to output the 1056: assembler code on. X is the RTL expression for the constant to 1057: output, and MODE is the machine mode (in case X is a `const_int'). 1058: ALIGN is the required alignment for the value X; you should 1059: output an assembler directive to force this much alignment. 1060: 1061: The argument LABELNO is a number to use in an internal label for 1062: the address of this pool entry. The definition of this macro is 1063: responsible for outputting the label definition at the proper 1064: place. Here is how to do this: 1065: 1066: ASM_OUTPUT_INTERNAL_LABEL (FILE, "LC", LABELNO); 1067: 1068: When you output a pool entry specially, you should end with a 1069: `goto' to the label JUMPTO. This will prevent the same pool entry 1070: from being output a second time in the usual manner. 1071: 1072: You need not define this macro if it would do nothing. 1073: 1074: `IS_ASM_LOGICAL_LINE_SEPARATOR (C)' 1075: Define this macro as a C expression which is nonzero if C is used 1076: as a logical line separator by the assembler. 1077: 1078: If you do not define this macro, the default is that only the 1079: character `;' is treated as a logical line separator. 1080: 1081: `ASM_OPEN_PAREN' 1082: `ASM_CLOSE_PAREN' 1083: These macros are defined as C string constant, describing the 1084: syntax in the assembler for grouping arithmetic expressions. The 1085: following definitions are correct for most assemblers: 1086: 1087: #define ASM_OPEN_PAREN "(" 1088: #define ASM_CLOSE_PAREN ")" 1089: 1090: These macros are provided by `real.h' for writing the definitions of 1091: `ASM_OUTPUT_DOUBLE' and the like: 1092: 1093: `REAL_VALUE_TO_TARGET_SINGLE (X, L)' 1094: `REAL_VALUE_TO_TARGET_DOUBLE (X, L)' 1095: `REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)' 1096: These translate X, of type `REAL_VALUE_TYPE', to the target's 1097: floating point representation, and store its bit pattern in the 1098: array of `long int' whose address is L. The number of elements in 1099: the output array is determined by the size of the desired target 1100: floating point data type: 32 bits of it go in each `long int' array 1101: element. Each array element holds 32 bits of the result, even if 1102: `long int' is wider than 32 bits on the host machine. 1103: 1104: The array element values are designed so that you can print them 1105: out using `fprintf' in the order they should appear in the target 1106: machine's memory. 1107: 1108: `REAL_VALUE_TO_DECIMAL (X, FORMAT, STRING)' 1109: This macro converts X, of type `REAL_VALUE_TYPE', to a decimal 1110: number and stores it as a string into STRING. You must pass, as 1111: STRING, the address of a long enough block of space to hold the 1112: result. 1.1.1.3 root 1113: 1.1.1.4 root 1114: The argument FORMAT is a `printf'-specification that serves as a 1115: suggestion for how to format the output string. 1.1 root 1116:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.