![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-3 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-3 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: Interface, Next: Passes, Prev: Portability, Up: Top ! 29: ! 30: Interfacing to GNU CC Output ! 31: **************************** ! 32: ! 33: GNU CC is normally configured to use the same function calling ! 34: convention normally in use on the target system. This is done with ! 35: the machine-description macros described (*note Machine Macros::.). ! 36: ! 37: However, returning of structure and union values is done differently ! 38: on some target machines. As a result, functions compiled with PCC ! 39: returning such types cannot be called from code compiled with GNU CC, ! 40: and vice versa. This does not cause trouble often because few Unix ! 41: library routines return structures or unions. ! 42: ! 43: GNU CC code returns structures and unions that are 1, 2, 4 or 8 bytes ! 44: long in the same registers used for `int' or `double' return values. ! 45: (GNU CC typically allocates variables of such types in registers ! 46: also.) Structures and unions of other sizes are returned by storing ! 47: them into an address passed by the caller (usually in a register). ! 48: The machine-description macros `STRUCT_VALUE' and ! 49: `STRUCT_INCOMING_VALUE' tell GNU CC where to pass this address. ! 50: ! 51: By contrast, PCC on most target machines returns structures and ! 52: unions of any size by copying the data into an area of static ! 53: storage, and then returning the address of that storage as if it were ! 54: a pointer value. The caller must copy the data from that memory area ! 55: to the place where the value is wanted. This is slower than the ! 56: method used by GNU CC, and fails to be reentrant. ! 57: ! 58: On some target machines, such as RISC machines and the 80386, the ! 59: standard system convention is to pass to the subroutine the address ! 60: of where to return the value. On these machines, GNU CC has been ! 61: configured to be compatible with the standard compiler, when this ! 62: method is used. It may not be compatible for structures of 1, 2, 4 ! 63: or 8 bytes. ! 64: ! 65: GNU CC uses the system's standard convention for passing arguments. ! 66: On some machines, the first few arguments are passed in registers; in ! 67: others, all are passed on the stack. It would be possible to use ! 68: registers for argument passing on any machine, and this would ! 69: probably result in a significant speedup. But the result would be ! 70: complete incompatibility with code that follows the standard ! 71: convention. So this change is practical only if you are switching to ! 72: GNU CC as the sole C compiler for the system. We may implement ! 73: register argument passing on certain machines once we have a complete ! 74: GNU system so that we can compile the libraries with GNU CC. ! 75: ! 76: If you use `longjmp', beware of automatic variables. ANSI C says ! 77: that automatic variables that are not declared `volatile' have ! 78: undefined values after a `longjmp'. And this is all GNU CC promises ! 79: to do, because it is very difficult to restore register variables ! 80: correctly, and one of GNU CC's features is that it can put variables ! 81: in registers without your asking it to. ! 82: ! 83: If you want a variable to be unaltered by `longjmp', and you don't ! 84: want to write `volatile' because old C compilers don't accept it, ! 85: just take the address of the variable. If a variable's address is ! 86: ever taken, even if just to compute it and ignore it, then the ! 87: variable cannot go in a register: ! 88: ! 89: { ! 90: int careful; ! 91: &careful; ! 92: ... ! 93: } ! 94: ! 95: Code compiled with GNU CC may call certain library routines. Most of ! 96: them handle arithmetic for which there are no instructions. This ! 97: includes multiply and divide on some machines, and floating point ! 98: operations on any machine for which floating point support is ! 99: disabled with `-msoft-float'. Some standard parts of the C library, ! 100: such as `bcopy' or `memcpy', are also called automatically. The ! 101: usual function call interface is used for calling the library routines. ! 102: ! 103: These library routines should be defined in the library `gnulib', ! 104: which GNU CC automatically searches whenever it links a program. On ! 105: machines that have multiply and divide instructions, if hardware ! 106: floating point is in use, normally `gnulib' is not needed, but it is ! 107: searched just in case. ! 108: ! 109: Each arithmetic function is defined in `gnulib.c' to use the ! 110: corresponding C arithmetic operator. As long as the file is compiled ! 111: with another C compiler, which supports all the C arithmetic ! 112: operators, this file will work portably. However, `gnulib.c' does ! 113: not work if compiled with GNU CC, because each arithmetic function ! 114: would compile into a call to itself! ! 115: ! 116: ! 117: ! 118: File: gcc.info, Node: Passes, Next: RTL, Prev: Interface, Up: Top ! 119: ! 120: Passes and Files of the Compiler ! 121: ******************************** ! 122: ! 123: The overall control structure of the compiler is in `toplev.c'. This ! 124: file is responsible for initialization, decoding arguments, opening ! 125: and closing files, and sequencing the passes. ! 126: ! 127: The parsing pass is invoked only once, to parse the entire input. ! 128: The RTL intermediate code for a function is generated as the function ! 129: is parsed, a statement at a time. Each statement is read in as a ! 130: syntax tree and then converted to RTL; then the storage for the tree ! 131: for the statement is reclaimed. Storage for types (and the ! 132: expressions for their sizes), declarations, and a representation of ! 133: the binding contours and how they nest, remains until the function is ! 134: finished being compiled; these are all needed to output the debugging ! 135: information. ! 136: ! 137: Each time the parsing pass reads a complete function definition or ! 138: top-level declaration, it calls the function `rest_of_compilation' or ! 139: `rest_of_decl_compilation' in `toplev.c', which are responsible for ! 140: all further processing necessary, ending with output of the assembler ! 141: language. All other compiler passes run, in sequence, within ! 142: `rest_of_compilation'. When that function returns from compiling a ! 143: function definition, the storage used for that function definition's ! 144: compilation is entirely freed, unless it is an inline function (*note ! 145: Inline::.). ! 146: ! 147: Here is a list of all the passes of the compiler and their source ! 148: files. Also included is a description of where debugging dumps can ! 149: be requested with `-d' options. ! 150: ! 151: * Parsing. This pass reads the entire text of a function ! 152: definition, constructing partial syntax trees. This and RTL ! 153: generation are no longer truly separate passes (formerly they ! 154: were), but it is easier to think of them as separate. ! 155: ! 156: The tree representation does not entirely follow C syntax, ! 157: because it is intended to support other languages as well. ! 158: ! 159: C data type analysis is also done in this pass, and every tree ! 160: node that represents an expression has a data type attached. ! 161: Variables are represented as declaration nodes. ! 162: ! 163: Constant folding and associative-law simplifications are also ! 164: done during this pass. ! 165: ! 166: The source files for parsing are `c-parse.y', `c-decl.c', ! 167: `c-typeck.c', `c-convert.c', `stor-layout.c', `fold-const.c', ! 168: and `tree.c'. The last three files are intended to be ! 169: language-independent. There are also header files `c-parse.h', ! 170: `c-tree.h', `tree.h' and `tree.def'. The last two define the ! 171: format of the tree representation. ! 172: ! 173: * RTL generation. This is the conversion of syntax tree into RTL ! 174: code. It is actually done statement-by-statement during ! 175: parsing, but for most purposes it can be thought of as a ! 176: separate pass. ! 177: ! 178: This is where the bulk of target-parameter-dependent code is ! 179: found, since often it is necessary for strategies to apply only ! 180: when certain standard kinds of instructions are available. The ! 181: purpose of named instruction patterns is to provide this ! 182: information to the RTL generation pass. ! 183: ! 184: Optimization is done in this pass for `if'-conditions that are ! 185: comparisons, boolean operations or conditional expressions. ! 186: Tail recursion is detected at this time also. Decisions are ! 187: made about how best to arrange loops and how to output `switch' ! 188: statements. ! 189: ! 190: The source files for RTL generation are `stmt.c', `expr.c', ! 191: `explow.c', `expmed.c', `optabs.c' and `emit-rtl.c'. Also, the ! 192: file `insn-emit.c', generated from the machine description by ! 193: the program `genemit', is used in this pass. The header files ! 194: `expr.h' is used for communication within this pass. ! 195: ! 196: The header files `insn-flags.h' and `insn-codes.h', generated ! 197: from the machine description by the programs `genflags' and ! 198: `gencodes', tell this pass which standard names are available ! 199: for use and which patterns correspond to them. ! 200: ! 201: Aside from debugging information output, none of the following ! 202: passes refers to the tree structure representation of the ! 203: function (only part of which is saved). ! 204: ! 205: The decision of whether the function can and should be expanded ! 206: inline in its subsequent callers is made at the end of rtl ! 207: generation. The function must meet certain criteria, currently ! 208: related to the size of the function and the types and number of ! 209: parameters it has. Note that this function may contain loops, ! 210: recursive calls to itself (tail-recursive functions can be ! 211: inlined!), gotos, in short, all constructs supported by GNU CC. ! 212: ! 213: The option `-dr' causes a debugging dump of the RTL code after ! 214: this pass. This dump file's name is made by appending `.rtl' to ! 215: the input file name. ! 216: ! 217: * Jump optimization. This pass simplifies jumps to the following ! 218: instruction, jumps across jumps, and jumps to jumps. It deletes ! 219: unreferenced labels and unreachable code, except that ! 220: unreachable code that contains a loop is not recognized as ! 221: unreachable in this pass. (Such loops are deleted later in the ! 222: basic block analysis.) ! 223: ! 224: Jump optimization is performed two or three times. The first ! 225: time is immediately following RTL generation. The second time ! 226: is after CSE, but only if CSE says repeated jump optimization is ! 227: needed. The last time is right before the final pass. That ! 228: time, cross-jumping and deletion of no-op move instructions are ! 229: done together with the optimizations described above. ! 230: ! 231: The source file of this pass is `jump.c'. ! 232: ! 233: The option `-dj' causes a debugging dump of the RTL code after ! 234: this pass is run for the first time. This dump file's name is ! 235: made by appending `.jump' to the input file name. ! 236: ! 237: * Register scan. This pass finds the first and last use of each ! 238: register, as a guide for common subexpression elimination. Its ! 239: source is in `regclass.c'. ! 240: ! 241: * Common subexpression elimination. This pass also does constant ! 242: propagation. Its source file is `cse.c'. If constant ! 243: propagation causes conditional jumps to become unconditional or ! 244: to become no-ops, jump optimization is run again when CSE is ! 245: finished. ! 246: ! 247: The option `-ds' causes a debugging dump of the RTL code after ! 248: this pass. This dump file's name is made by appending `.cse' to ! 249: the input file name. ! 250: ! 251: * Loop optimization. This pass moves constant expressions out of ! 252: loops. Its source file is `loop.c'. ! 253: ! 254: The option `-dL' causes a debugging dump of the RTL code after ! 255: this pass. This dump file's name is made by appending `.loop' ! 256: to the input file name. ! 257: ! 258: * Stupid register allocation is performed at this point in a ! 259: nonoptimizing compilation. It does a little data flow analysis ! 260: as well. When stupid register allocation is in use, the next ! 261: pass executed is the reloading pass; the others in between are ! 262: skipped. The source file is `stupid.c'. ! 263: ! 264: * Data flow analysis (`flow.c'). This pass divides the program ! 265: into basic blocks (and in the process deletes unreachable ! 266: loops); then it computes which pseudo-registers are live at each ! 267: point in the program, and makes the first instruction that uses ! 268: a value point at the instruction that computed the value. ! 269: ! 270: This pass also deletes computations whose results are never ! 271: used, and combines memory references with add or subtract ! 272: instructions to make autoincrement or autodecrement addressing. ! 273: ! 274: The option `-df' causes a debugging dump of the RTL code after ! 275: this pass. This dump file's name is made by appending `.flow' ! 276: to the input file name. If stupid register allocation is in ! 277: use, this dump file reflects the full results of such allocation. ! 278: ! 279: * Instruction combination (`combine.c'). This pass attempts to ! 280: combine groups of two or three instructions that are related by ! 281: data flow into single instructions. It combines the RTL ! 282: expressions for the instructions by substitution, simplifies the ! 283: result using algebra, and then attempts to match the result ! 284: against the machine description. ! 285: ! 286: The option `-dc' causes a debugging dump of the RTL code after ! 287: this pass. This dump file's name is made by appending ! 288: `.combine' to the input file name. ! 289: ! 290: * Register class preferencing. The RTL code is scanned to find ! 291: out which register class is best for each pseudo register. The ! 292: source file is `regclass.c'. ! 293: ! 294: * Local register allocation (`local-alloc.c'). This pass ! 295: allocates hard registers to pseudo registers that are used only ! 296: within one basic block. Because the basic block is linear, it ! 297: can use fast and powerful techniques to do a very good job. ! 298: ! 299: The option `-dl' causes a debugging dump of the RTL code after ! 300: this pass. This dump file's name is made by appending `.lreg' ! 301: to the input file name. ! 302: ! 303: * Global register allocation (`global-alloc.c'). This pass ! 304: allocates hard registers for the remaining pseudo registers ! 305: (those whose life spans are not contained in one basic block). ! 306: ! 307: * Reloading. This pass renumbers pseudo registers with the ! 308: hardware registers numbers they were allocated. Pseudo ! 309: registers that did not get hard registers are replaced with ! 310: stack slots. Then it finds instructions that are invalid ! 311: because a value has failed to end up in a register, or has ended ! 312: up in a register of the wrong kind. It fixes up these ! 313: instructions by reloading the problematical values temporarily ! 314: into registers. Additional instructions are generated to do the ! 315: copying. ! 316: ! 317: Source files are `reload.c' and `reload1.c', plus the header ! 318: `reload.h' used for communication between them. ! 319: ! 320: The option `-dg' causes a debugging dump of the RTL code after ! 321: this pass. This dump file's name is made by appending `.greg' ! 322: to the input file name. ! 323: ! 324: * Jump optimization is repeated, this time including cross-jumping ! 325: and deletion of no-op move instructions. Machine-specific ! 326: peephole optimizations are performed at the same time. ! 327: ! 328: The option `-dJ' causes a debugging dump of the RTL code after ! 329: this pass. This dump file's name is made by appending `.jump2' ! 330: to the input file name. ! 331: ! 332: * Final. This pass outputs the assembler code for the function. ! 333: It is also responsible for identifying spurious test and compare ! 334: instructions. The function entry and exit sequences are ! 335: generated directly as assembler code in this pass; they never ! 336: exist as RTL. ! 337: ! 338: The source files are `final.c' plus `insn-output.c'; the latter ! 339: is generated automatically from the machine description by the ! 340: tool `genoutput'. The header file `conditions.h' is used for ! 341: communication between these files. ! 342: ! 343: * Debugging information output. This is run after final because ! 344: it must output the stack slot offsets for pseudo registers that ! 345: did not get hard registers. Source files are `dbxout.c' for DBX ! 346: symbol table format and `symout.c' for GDB's own symbol table ! 347: format. ! 348: ! 349: Some additional files are used by all or many passes: ! 350: ! 351: * Every pass uses `machmode.def', which defines the machine modes. ! 352: ! 353: * All the passes that work with RTL use the header files `rtl.h' ! 354: and `rtl.def', and subroutines in file `rtl.c'. The tools ! 355: `gen*' also use these files to read and work with the machine ! 356: description RTL. ! 357: ! 358: * Several passes refer to the header file `insn-config.h' which ! 359: contains a few parameters (C macro definitions) generated ! 360: automatically from the machine description RTL by the tool ! 361: `genconfig'. ! 362: ! 363: * Several passes use the instruction recognizer, which consists of ! 364: `recog.c' and `recog.h', plus the files `insn-recog.c' and ! 365: `insn-extract.c' that are generated automatically from the ! 366: machine description by the tools `genrecog' and `genextract'. ! 367: ! 368: * Several passes use the header files `regs.h' which defines the ! 369: information recorded about pseudo register usage, and ! 370: `basic-block.h' which defines the information recorded about ! 371: basic blocks. ! 372: ! 373: * `hard-reg-set.h' defines the type `HARD_REG_SET', a bit-vector ! 374: with a bit for each hard register, and some macros to manipulate ! 375: it. This type is just `int' if the machine has few enough hard ! 376: registers; otherwise it is an array of `int' and some of the ! 377: macros expand into loops. ! 378: ! 379: ! 380: ! 381: File: gcc.info, Node: RTL, Next: Machine Desc, Prev: Passes, Up: Top ! 382: ! 383: RTL Representation ! 384: ****************** ! 385: ! 386: Most of the work of the compiler is done on an intermediate ! 387: representation called register transfer language. In this language, ! 388: the instructions to be output are described, pretty much one by one, ! 389: in an algebraic form that describes what the instruction does. ! 390: ! 391: RTL is inspired by Lisp lists. It has both an internal form, made up ! 392: of structures that point at other structures, and a textual form that ! 393: is used in the machine description and in printed debugging dumps. ! 394: The textual form uses nested parentheses to indicate the pointers in ! 395: the internal form. ! 396: ! 397: * Menu: ! 398: ! 399: * RTL Objects:: Expressions vs vectors vs strings vs integers. ! 400: * Accessors:: Macros to access expression operands or vector elts. ! 401: * Flags:: Other flags in an RTL expression. ! 402: * Machine Modes:: Describing the size and format of a datum. ! 403: * Constants:: Expressions with constant values. ! 404: * Regs and Memory:: Expressions representing register contents or memory. ! 405: * Arithmetic:: Expressions representing arithmetic on other expressions. ! 406: * Comparisons:: Expressions representing comparison of expressions. ! 407: * Bit Fields:: Expressions representing bit-fields in memory or reg. ! 408: * Conversions:: Extending, truncating, floating or fixing. ! 409: * RTL Declarations:: Declaring volatility, constancy, etc. ! 410: * Side Effects:: Expressions for storing in registers, etc. ! 411: * Incdec:: Embedded side-effects for autoincrement addressing. ! 412: * Assembler:: Representing `asm' with operands. ! 413: * Insns:: Expression types for entire insns. ! 414: * Calls:: RTL representation of function call insns. ! 415: * Sharing:: Some expressions are unique; others *must* be copied. ! 416: ! 417: ! 418: ! 419: File: gcc.info, Node: RTL Objects, Next: Accessors, Prev: RTL, Up: RTL ! 420: ! 421: RTL Object Types ! 422: ================ ! 423: ! 424: RTL uses four kinds of objects: expressions, integers, strings and ! 425: vectors. Expressions are the most important ones. An RTL expression ! 426: (``RTX'', for short) is a C structure, but it is usually referred to ! 427: with a pointer; a type that is given the typedef name `rtx'. ! 428: ! 429: An integer is simply an `int', and a string is a `char *'. Within ! 430: RTL code, strings appear only inside `symbol_ref' expressions, but ! 431: they appear in other contexts in the RTL expressions that make up ! 432: machine descriptions. Their written form uses decimal digits. ! 433: ! 434: A string is a sequence of characters. In core it is represented as a ! 435: `char *' in usual C fashion, and it is written in C syntax as well. ! 436: However, strings in RTL may never be null. If you write an empty ! 437: string in a machine description, it is represented in core as a null ! 438: pointer rather than as a pointer to a null character. In certain ! 439: contexts, these null pointers instead of strings are valid. ! 440: ! 441: A vector contains an arbitrary, specified number of pointers to ! 442: expressions. The number of elements in the vector is explicitly ! 443: present in the vector. The written form of a vector consists of ! 444: square brackets (`[...]') surrounding the elements, in sequence and ! 445: with whitespace separating them. Vectors of length zero are not ! 446: created; null pointers are used instead. ! 447: ! 448: Expressions are classified by "expression codes" (also called RTX ! 449: codes). The expression code is a name defined in `rtl.def', which is ! 450: also (in upper case) a C enumeration constant. The possible ! 451: expression codes and their meanings are machine-independent. The ! 452: code of an RTX can be extracted with the macro `GET_CODE (X)' and ! 453: altered with `PUT_CODE (X, NEWCODE)'. ! 454: ! 455: The expression code determines how many operands the expression ! 456: contains, and what kinds of objects they are. In RTL, unlike Lisp, ! 457: you cannot tell by looking at an operand what kind of object it is. ! 458: Instead, you must know from its context--from the expression code of ! 459: the containing expression. For example, in an expression of code ! 460: `subreg', the first operand is to be regarded as an expression and ! 461: the second operand as an integer. In an expression of code `plus', ! 462: there are two operands, both of which are to be regarded as ! 463: expressions. In a `symbol_ref' expression, there is one operand, ! 464: which is to be regarded as a string. ! 465: ! 466: Expressions are written as parentheses containing the name of the ! 467: expression type, its flags and machine mode if any, and then the ! 468: operands of the expression (separated by spaces). ! 469: ! 470: Expression code names in the `md' file are written in lower case, but ! 471: when they appear in C code they are written in upper case. In this ! 472: manual, they are shown as follows: `const_int'. ! 473: ! 474: In a few contexts a null pointer is valid where an expression is ! 475: normally wanted. The written form of this is `(nil)'. ! 476: ! 477: ! 478: ! 479: File: gcc.info, Node: Accessors, Next: Flags, Prev: RTL Objects, Up: RTL ! 480: ! 481: Access to Operands ! 482: ================== ! 483: ! 484: For each expression type `rtl.def' specifies the number of contained ! 485: objects and their kinds, with four possibilities: `e' for expression ! 486: (actually a pointer to an expression), `i' for integer, `s' for ! 487: string, and `E' for vector of expressions. The sequence of letters ! 488: for an expression code is called its "format". Thus, the format of ! 489: `subreg' is `ei'. ! 490: ! 491: Two other format characters are used occasionally: `u' and `0'. `u' ! 492: is equivalent to `e' except that it is printed differently in ! 493: debugging dumps, and `0' means a slot whose contents do not fit any ! 494: normal category. `0' slots are not printed at all in dumps, and are ! 495: often used in special ways by small parts of the compiler. ! 496: ! 497: There are macros to get the number of operands and the format of an ! 498: expression code: ! 499: ! 500: `GET_RTX_LENGTH (CODE)' ! 501: Number of operands of an RTX of code CODE. ! 502: ! 503: `GET_RTX_FORMAT (CODE)' ! 504: The format of an RTX of code CODE, as a C string. ! 505: ! 506: Operands of expressions are accessed using the macros `XEXP', `XINT' ! 507: and `XSTR'. Each of these macros takes two arguments: an ! 508: expression-pointer (RTX) and an operand number (counting from zero). ! 509: Thus, ! 510: ! 511: XEXP (X, 2) ! 512: ! 513: accesses operand 2 of expression X, as an expression. ! 514: ! 515: XINT (X, 2) ! 516: ! 517: accesses the same operand as an integer. `XSTR', used in the same ! 518: fashion, would access it as a string. ! 519: ! 520: Any operand can be accessed as an integer, as an expression or as a ! 521: string. You must choose the correct method of access for the kind of ! 522: value actually stored in the operand. You would do this based on the ! 523: expression code of the containing expression. That is also how you ! 524: would know how many operands there are. ! 525: ! 526: For example, if X is a `subreg' expression, you know that it has two ! 527: operands which can be correctly accessed as `XEXP (X, 0)' and `XINT ! 528: (X, 1)'. If you did `XINT (X, 0)', you would get the address of the ! 529: expression operand but cast as an integer; that might occasionally be ! 530: useful, but it would be cleaner to write `(int) XEXP (X, 0)'. `XEXP ! 531: (X, 1)' would also compile without error, and would return the ! 532: second, integer operand cast as an expression pointer, which would ! 533: probably result in a crash when accessed. Nothing stops you from ! 534: writing `XEXP (X, 28)' either, but this will access memory past the ! 535: end of the expression with unpredictable results. ! 536: ! 537: Access to operands which are vectors is more complicated. You can ! 538: use the macro `XVEC' to get the vector-pointer itself, or the macros ! 539: `XVECEXP' and `XVECLEN' to access the elements and length of a vector. ! 540: ! 541: `XVEC (EXP, IDX)' ! 542: Access the vector-pointer which is operand number IDX in EXP. ! 543: ! 544: `XVECLEN (EXP, IDX)' ! 545: Access the length (number of elements) in the vector which is in ! 546: operand number IDX in EXP. This value is an `int'. ! 547: ! 548: `XVECEXP (EXP, IDX, ELTNUM)' ! 549: Access element number ELTNUM in the vector which is in operand ! 550: number IDX in EXP. This value is an RTX. ! 551: ! 552: It is up to you to make sure that ELTNUM is not negative and is ! 553: less than `XVECLEN (EXP, IDX)'. ! 554: ! 555: All the macros defined in this section expand into lvalues and ! 556: therefore can be used to assign the operands, lengths and vector ! 557: elements as well as to access them. ! 558: ! 559: ! 560: ! 561: File: gcc.info, Node: Flags, Next: Machine Modes, Prev: Accessors, Up: RTL ! 562: ! 563: Flags in an RTL Expression ! 564: ========================== ! 565: ! 566: RTL expressions contain several flags (one-bit bit-fields) that are ! 567: used in certain types of expression. Most often they are accessed ! 568: with the following macros: ! 569: ! 570: `MEM_VOLATILE_P (X)' ! 571: In `mem' expressions, nonzero for volatile memory references. ! 572: Stored in the `volatil' field and printed as `/v'. ! 573: ! 574: `MEM_IN_STRUCT_P (X)' ! 575: In `mem' expressions, nonzero for reference to an entire ! 576: structure, union or array, or to a component of one. Zero for ! 577: references to a scalar variable or through a pointer to a scalar. ! 578: Stored in the `in_struct' field and printed as `/s'. ! 579: ! 580: `REG_USER_VAR_P (X)' ! 581: In a `reg', nonzero if it corresponds to a variable present in ! 582: the user's source code. Zero for temporaries generated ! 583: internally by the compiler. Stored in the `volatil' field and ! 584: printed as `/v'. ! 585: ! 586: `REG_FUNCTION_VALUE_P (X)' ! 587: Nonzero in a `reg' if it is the place in which this function's ! 588: value is going to be returned. (This happens only in a hard ! 589: register.) Stored in the `integrated' field and printed as `/i'. ! 590: ! 591: The same hard register may be used also for collecting the ! 592: values of functions called by this one, but ! 593: `REG_FUNCTION_VALUE_P' is zero in this kind of use. ! 594: ! 595: `RTX_UNCHANGING_P (X)' ! 596: Nonzero in a `reg' or `mem' if the value is not changed ! 597: explicitly by the current function. (If it is a memory ! 598: reference then it may be changed by other functions or by ! 599: aliasing.) Stored in the `unchanging' field and printed as `/u'. ! 600: ! 601: `RTX_INTEGRATED_P (INSN)' ! 602: Nonzero in an insn if it resulted from an in-line function call. ! 603: Stored in the `integrated' field and printed as `/i'. This may ! 604: be deleted; nothing currently depends on it. ! 605: ! 606: `INSN_DELETED_P (INSN)' ! 607: In an insn, nonzero if the insn has been deleted. Stored in the ! 608: `volatil' field and printed as `/v'. ! 609: ! 610: `CONSTANT_POOL_ADDRESS_P (X)' ! 611: Nonzero in a `symbol_ref' if it refers to part of the current ! 612: function's ``constants pool''. These are addresses close to the ! 613: beginning of the function, and GNU CC assumes they can be ! 614: addressed directly (perhaps with the help of base registers). ! 615: Stored in the `unchanging' field and printed as `/u'. ! 616: ! 617: These are the fields which the above macros refer to: ! 618: ! 619: `used' ! 620: This flag is used only momentarily, at the end of RTL generation ! 621: for a function, to count the number of times an expression ! 622: appears in insns. Expressions that appear more than once are ! 623: copied, according to the rules for shared structure (*note ! 624: Sharing::.). ! 625: ! 626: `volatil' ! 627: This flag is used in `mem' and `reg' expressions and in insns. ! 628: In RTL dump files, it is printed as `/v'. ! 629: ! 630: In a `mem' expression, it is 1 if the memory reference is ! 631: volatile. Volatile memory references may not be deleted, ! 632: reordered or combined. ! 633: ! 634: In a `reg' expression, it is 1 if the value is a user-level ! 635: variable. 0 indicates an internal compiler temporary. ! 636: ! 637: In an insn, 1 means the insn has been deleted. ! 638: ! 639: `in_struct' ! 640: This flag is used in `mem' expressions. It is 1 if the memory ! 641: datum referred to is all or part of a structure or array; 0 if ! 642: it is (or might be) a scalar variable. A reference through a C ! 643: pointer has 0 because the pointer might point to a scalar ! 644: variable. ! 645: ! 646: This information allows the compiler to determine something ! 647: about possible cases of aliasing. ! 648: ! 649: In an RTL dump, this flag is represented as `/s'. ! 650: ! 651: `unchanging' ! 652: This flag is used in `reg' and `mem' expressions. 1 means that ! 653: the value of the expression never changes (at least within the ! 654: current function). ! 655: ! 656: In an RTL dump, this flag is represented as `/u'. ! 657: ! 658: `integrated' ! 659: In some kinds of expressions, including insns, this flag means ! 660: the rtl was produced by procedure integration. ! 661: ! 662: In a `reg' expression, this flag indicates the register ! 663: containing the value to be returned by the current function. On ! 664: machines that pass parameters in registers, the same register ! 665: number may be used for parameters as well, but this flag is not ! 666: set on such uses. ! 667: ! 668: ! 669: ! 670: File: gcc.info, Node: Machine Modes, Next: Constants, Prev: Flags, Up: RTL ! 671: ! 672: Machine Modes ! 673: ============= ! 674: ! 675: A machine mode describes a size of data object and the representation ! 676: used for it. In the C code, machine modes are represented by an ! 677: enumeration type, `enum machine_mode', defined in `machmode.def'. ! 678: Each RTL expression has room for a machine mode and so do certain ! 679: kinds of tree expressions (declarations and types, to be precise). ! 680: ! 681: In debugging dumps and machine descriptions, the machine mode of an ! 682: RTL expression is written after the expression code with a colon to ! 683: separate them. The letters `mode' which appear at the end of each ! 684: machine mode name are omitted. For example, `(reg:SI 38)' is a `reg' ! 685: expression with machine mode `SImode'. If the mode is `VOIDmode', it ! 686: is not written at all. ! 687: ! 688: Here is a table of machine modes. ! 689: ! 690: `QImode' ! 691: ``Quarter-Integer'' mode represents a single byte treated as an ! 692: integer. ! 693: ! 694: `HImode' ! 695: ``Half-Integer'' mode represents a two-byte integer. ! 696: ! 697: `SImode' ! 698: ``Single Integer'' mode represents a four-byte integer. ! 699: ! 700: `DImode' ! 701: ``Double Integer'' mode represents an eight-byte integer. ! 702: ! 703: `TImode' ! 704: ``Tetra Integer'' (?) mode represents a sixteen-byte integer. ! 705: ! 706: `SFmode' ! 707: ``Single Floating'' mode represents a single-precision (four ! 708: byte) floating point number. ! 709: ! 710: `DFmode' ! 711: ``Double Floating'' mode represents a double-precision (eight ! 712: byte) floating point number. ! 713: ! 714: `TFmode' ! 715: ``Tetra Floating'' mode represents a quadruple-precision ! 716: (sixteen byte) floating point number. ! 717: ! 718: `BLKmode' ! 719: ``Block'' mode represents values that are aggregates to which ! 720: none of the other modes apply. In RTL, only memory references ! 721: can have this mode, and only if they appear in string-move or ! 722: vector instructions. On machines which have no such ! 723: instructions, `BLKmode' will not appear in RTL. ! 724: ! 725: `VOIDmode' ! 726: Void mode means the absence of a mode or an unspecified mode. ! 727: For example, RTL expressions of code `const_int' have mode ! 728: `VOIDmode' because they can be taken to have whatever mode the ! 729: context requires. In debugging dumps of RTL, `VOIDmode' is ! 730: expressed by the absence of any mode. ! 731: ! 732: `EPmode' ! 733: ``Entry Pointer'' mode is intended to be used for function ! 734: variables in Pascal and other block structured languages. Such ! 735: values contain both a function address and a static chain ! 736: pointer for access to automatic variables of outer levels. This ! 737: mode is only partially implemented since C does not use it. ! 738: ! 739: `CSImode, ...' ! 740: ``Complex Single Integer'' mode stands for a complex number ! 741: represented as a pair of `SImode' integers. Any of the integer ! 742: and floating modes may have `C' prefixed to its name to obtain a ! 743: complex number mode. For example, there are `CQImode', ! 744: `CSFmode', and `CDFmode'. Since C does not support complex ! 745: numbers, these machine modes are only partially implemented. ! 746: ! 747: `BImode' ! 748: This is the machine mode of a bit-field in a structure. It is ! 749: used only in the syntax tree, never in RTL, and in the syntax ! 750: tree it appears only in declaration nodes. In C, it appears ! 751: only in `FIELD_DECL' nodes for structure fields defined with a ! 752: bit size. ! 753: ! 754: The machine description defines `Pmode' as a C macro which expands ! 755: into the machine mode used for addresses. Normally this is `SImode'. ! 756: ! 757: The only modes which a machine description must support are `QImode', ! 758: `SImode', `SFmode' and `DFmode'. The compiler will attempt to use ! 759: `DImode' for two-word structures and unions, but it would not be hard ! 760: to program it to avoid this. Likewise, you can arrange for the C ! 761: type `short int' to avoid using `HImode'. In the long term it would ! 762: be desirable to make the set of available machine modes ! 763: machine-dependent and eliminate all assumptions about specific ! 764: machine modes or their uses from the machine-independent code of the ! 765: compiler. ! 766: ! 767: Here are some C macros that relate to machine modes: ! 768: ! 769: `GET_MODE (X)' ! 770: Returns the machine mode of the RTX X. ! 771: ! 772: `PUT_MODE (X, NEWMODE)' ! 773: Alters the machine mode of the RTX X to be NEWMODE. ! 774: ! 775: `GET_MODE_SIZE (M)' ! 776: Returns the size in bytes of a datum of mode M. ! 777: ! 778: `GET_MODE_BITSIZE (M)' ! 779: Returns the size in bits of a datum of mode M. ! 780: ! 781: `GET_MODE_UNIT_SIZE (M)' ! 782: Returns the size in bits of the subunits of a datum of mode M. ! 783: This is the same as `GET_MODE_SIZE' except in the case of ! 784: complex modes and `EPmode'. For them, the unit size is the size ! 785: of the real or imaginary part, or the size of the function ! 786: pointer or the context pointer. ! 787: ! 788: ! 789: ! 790: File: gcc.info, Node: Constants, Next: Regs and Memory, Prev: Machine Modes, Up: RTL ! 791: ! 792: Constant Expression Types ! 793: ========================= ! 794: ! 795: The simplest RTL expressions are those that represent constant values. ! 796: ! 797: `(const_int I)' ! 798: This type of expression represents the integer value I. I is ! 799: customarily accessed with the macro `INTVAL' as in `INTVAL ! 800: (EXP)', which is equivalent to `XINT (EXP, 0)'. ! 801: ! 802: There is only one expression object for the integer value zero; ! 803: it is the value of the variable `const0_rtx'. Likewise, the ! 804: only expression for integer value one is found in `const1_rtx'. ! 805: Any attempt to create an expression of code `const_int' and ! 806: value zero or one will return `const0_rtx' or `const1_rtx' as ! 807: appropriate. ! 808: ! 809: `(const_double:M I0 I1)' ! 810: Represents a 64-bit constant or mode M. All floating point ! 811: constants are represented in this way, and so are 64-bit ! 812: `DImode' integer constants. ! 813: ! 814: The two integers I0 and I1 together contain the bits of the ! 815: value. If the constant is floating point (either single or ! 816: double precision), then they represent a `double'. To convert ! 817: them to a `double', do ! 818: ! 819: union { double d; int i[2];} u; ! 820: u.i[0] = XINT (x, 0); ! 821: u.i[1] = XINT (x, 1); ! 822: ! 823: and then refer to `u.d'. ! 824: ! 825: The global variables `dconst0_rtx' and `fconst0_rtx' hold ! 826: `const_double' expressions with value 0, in modes `DFmode' and ! 827: `SFmode', respectively. ! 828: ! 829: `(symbol_ref SYMBOL)' ! 830: Represents the value of an assembler label for data. SYMBOL is ! 831: a string that describes the name of the assembler label. If it ! 832: starts with a `*', the label is the rest of SYMBOL not including ! 833: the `*'. Otherwise, the label is SYMBOL, prefixed with `_'. ! 834: ! 835: `(label_ref LABEL)' ! 836: Represents the value of an assembler label for code. It ! 837: contains one operand, an expression, which must be a ! 838: `code_label' that appears in the instruction sequence to ! 839: identify the place where the label should go. ! 840: ! 841: The reason for using a distinct expression type for code label ! 842: references is so that jump optimization can distinguish them. ! 843: ! 844: `(const EXP)' ! 845: Represents a constant that is the result of an assembly-time ! 846: arithmetic computation. The operand, EXP, is an expression that ! 847: contains only constants (`const_int', `symbol_ref' and ! 848: `label_ref' expressions) combined with `plus' and `minus'. ! 849: However, not all combinations are valid, since the assembler ! 850: cannot do arbitrary arithmetic on relocatable symbols. ! 851: ! 852: ! 853: ! 854: File: gcc.info, Node: Regs and Memory, Next: Arithmetic, Prev: Constants, Up: RTL ! 855: ! 856: Registers and Memory ! 857: ==================== ! 858: ! 859: Here are the RTL expression types for describing access to machine ! 860: registers and to main memory. ! 861: ! 862: `(reg:M N)' ! 863: For small values of the integer N (less than ! 864: `FIRST_PSEUDO_REGISTER'), this stands for a reference to machine ! 865: register number N: a "hard register". For larger values of N, ! 866: it stands for a temporary value or "pseudo register". The ! 867: compiler's strategy is to generate code assuming an unlimited ! 868: number of such pseudo registers, and later convert them into ! 869: hard registers or into memory references. ! 870: ! 871: The symbol `FIRST_PSEUDO_REGISTER' is defined by the machine ! 872: description, since the number of hard registers on the machine ! 873: is an invariant characteristic of the machine. Note, however, ! 874: that not all of the machine registers must be general registers. ! 875: All the machine registers that can be used for storage of data ! 876: are given hard register numbers, even those that can be used ! 877: only in certain instructions or can hold only certain types of ! 878: data. ! 879: ! 880: Each pseudo register number used in a function's RTL code is ! 881: represented by a unique `reg' expression. ! 882: ! 883: M is the machine mode of the reference. It is necessary because ! 884: machines can generally refer to each register in more than one ! 885: mode. For example, a register may contain a full word but there ! 886: may be instructions to refer to it as a half word or as a single ! 887: byte, as well as instructions to refer to it as a floating point ! 888: number of various precisions. ! 889: ! 890: Even for a register that the machine can access in only one ! 891: mode, the mode must always be specified. ! 892: ! 893: A hard register may be accessed in various modes throughout one ! 894: function, but each pseudo register is given a natural mode and ! 895: is accessed only in that mode. When it is necessary to describe ! 896: an access to a pseudo register using a nonnatural mode, a ! 897: `subreg' expression is used. ! 898: ! 899: A `reg' expression with a machine mode that specifies more than ! 900: one word of data may actually stand for several consecutive ! 901: registers. If in addition the register number specifies a ! 902: hardware register, then it actually represents several ! 903: consecutive hardware registers starting with the specified one. ! 904: ! 905: Such multi-word hardware register `reg' expressions may not be ! 906: live across the boundary of a basic block. The lifetime ! 907: analysis pass does not know how to record properly that several ! 908: consecutive registers are actually live there, and therefore ! 909: register allocation would be confused. The CSE pass must go out ! 910: of its way to make sure the situation does not arise. ! 911: ! 912: `(subreg:M REG WORDNUM)' ! 913: `subreg' expressions are used to refer to a register in a ! 914: machine mode other than its natural one, or to refer to one ! 915: register of a multi-word `reg' that actually refers to several ! 916: registers. ! 917: ! 918: Each pseudo-register has a natural mode. If it is necessary to ! 919: operate on it in a different mode--for example, to perform a ! 920: fullword move instruction on a pseudo-register that contains a ! 921: single byte-- the pseudo-register must be enclosed in a ! 922: `subreg'. In such a case, WORDNUM is zero. ! 923: ! 924: The other use of `subreg' is to extract the individual registers ! 925: of a multi-register value. Machine modes such as `DImode' and ! 926: `EPmode' indicate values longer than a word, values which ! 927: usually require two consecutive registers. To access one of the ! 928: registers, use a `subreg' with mode `SImode' and a WORDNUM that ! 929: says which register. ! 930: ! 931: The compilation parameter `WORDS_BIG_ENDIAN', if defined, says ! 932: that word number zero is the most significant part; otherwise, ! 933: it is the least significant part. ! 934: ! 935: Between the combiner pass and the reload pass, it is possible to ! 936: have a `subreg' which contains a `mem' instead of a `reg' as its ! 937: first operand. The reload pass eliminates these cases by ! 938: reloading the `mem' into a suitable register. ! 939: ! 940: Note that it is not valid to access a `DFmode' value in `SFmode' ! 941: using a `subreg'. On some machines the most significant part of ! 942: a `DFmode' value does not have the same format as a ! 943: single-precision floating value. ! 944: ! 945: `(cc0)' ! 946: This refers to the machine's condition code register. It has no ! 947: operands and may not have a machine mode. It may be validly ! 948: used in only two contexts: as the destination of an assignment ! 949: (in test and compare instructions) and in comparison operators ! 950: comparing against zero (`const_int' with value zero; that is to ! 951: say, `const0_rtx'). ! 952: ! 953: There is only one expression object of code `cc0'; it is the ! 954: value of the variable `cc0_rtx'. Any attempt to create an ! 955: expression of code `cc0' will return `cc0_rtx'. ! 956: ! 957: One special thing about the condition code register is that ! 958: instructions can set it implicitly. On many machines, nearly ! 959: all instructions set the condition code based on the value that ! 960: they compute or store. It is not necessary to record these ! 961: actions explicitly in the RTL because the machine description ! 962: includes a prescription for recognizing the instructions that do ! 963: so (by means of the macro `NOTICE_UPDATE_CC'). Only ! 964: instructions whose sole purpose is to set the condition code, ! 965: and instructions that use the condition code, need mention ! 966: `(cc0)'. ! 967: ! 968: `(pc)' ! 969: This represents the machine's program counter. It has no ! 970: operands and may not have a machine mode. `(pc)' may be validly ! 971: used only in certain specific contexts in jump instructions. ! 972: ! 973: There is only one expression object of code `pc'; it is the ! 974: value of the variable `pc_rtx'. Any attempt to create an ! 975: expression of code `pc' will return `pc_rtx'. ! 976: ! 977: All instructions that do not jump alter the program counter ! 978: implicitly by incrementing it, but there is no need to mention ! 979: this in the RTL. ! 980: ! 981: `(mem:M ADDR)' ! 982: This RTX represents a reference to main memory at an address ! 983: represented by the expression ADDR. M specifies how large a ! 984: unit of memory is accessed. ! 985: ! 986: ! 987: ! 988: File: gcc.info, Node: Arithmetic, Next: Comparisons, Prev: Regs and Memory, Up: RTL ! 989: ! 990: RTL Expressions for Arithmetic ! 991: ============================== ! 992: ! 993: `(plus:M X Y)' ! 994: Represents the sum of the values represented by X and Y carried ! 995: out in machine mode M. This is valid only if X and Y both are ! 996: valid for mode M. ! 997: ! 998: `(minus:M X Y)' ! 999: Like `plus' but represents subtraction. ! 1000: ! 1001: `(minus X Y)' ! 1002: Represents the result of subtracting Y from X for purposes of ! 1003: comparison. The absence of a machine mode in the `minus' ! 1004: expression indicates that the result is computed without ! 1005: overflow, as if with infinite precision. ! 1006: ! 1007: Of course, machines can't really subtract with infinite precision. ! 1008: However, they can pretend to do so when only the sign of the ! 1009: result will be used, which is the case when the result is stored ! 1010: in `(cc0)'. And that is the only way this kind of expression ! 1011: may validly be used: as a value to be stored in the condition ! 1012: codes. ! 1013: ! 1014: `(neg:M X)' ! 1015: Represents the negation (subtraction from zero) of the value ! 1016: represented by X, carried out in mode M. X must be valid for ! 1017: mode M. ! 1018: ! 1019: `(mult:M X Y)' ! 1020: Represents the signed product of the values represented by X and ! 1021: Y carried out in machine mode M. If X and Y are both valid for ! 1022: mode M, this is ordinary size-preserving multiplication. ! 1023: Alternatively, both X and Y may be valid for a different, ! 1024: narrower mode. This represents the kind of multiplication that ! 1025: generates a product wider than the operands. Widening ! 1026: multiplication and same-size multiplication are completely ! 1027: distinct and supported by different machine instructions; ! 1028: machines may support one but not the other. ! 1029: ! 1030: `mult' may be used for floating point division as well. Then M ! 1031: is a floating point machine mode. ! 1032: ! 1033: `(umult:M X Y)' ! 1034: Like `mult' but represents unsigned multiplication. It may be ! 1035: used in both same-size and widening forms, like `mult'. `umult' ! 1036: is used only for fixed-point multiplication. ! 1037: ! 1038: `(div:M X Y)' ! 1039: Represents the quotient in signed division of X by Y, carried ! 1040: out in machine mode M. If M is a floating-point mode, it ! 1041: represents the exact quotient; otherwise, the integerized ! 1042: quotient. If X and Y are both valid for mode M, this is ! 1043: ordinary size-preserving division. Some machines have division ! 1044: instructions in which the operands and quotient widths are not ! 1045: all the same; such instructions are represented by `div' ! 1046: expressions in which the machine modes are not all the same. ! 1047: ! 1048: `(udiv:M X Y)' ! 1049: Like `div' but represents unsigned division. ! 1050: ! 1051: `(mod:M X Y)' ! 1052: `(umod:M X Y)' ! 1053: Like `div' and `udiv' but represent the remainder instead of the ! 1054: quotient. ! 1055: ! 1056: `(not:M X)' ! 1057: Represents the bitwise complement of the value represented by X, ! 1058: carried out in mode M, which must be a fixed-point machine mode. ! 1059: x must be valid for mode M, which must be a fixed-point mode. ! 1060: ! 1061: `(and:M X Y)' ! 1062: Represents the bitwise logical-and of the values represented by ! 1063: X and Y, carried out in machine mode M. This is valid only if X ! 1064: and Y both are valid for mode M, which must be a fixed-point mode. ! 1065: ! 1066: `(ior:M X Y)' ! 1067: Represents the bitwise inclusive-or of the values represented by ! 1068: X and Y, carried out in machine mode M. This is valid only if X ! 1069: and Y both are valid for mode M, which must be a fixed-point mode. ! 1070: ! 1071: `(xor:M X Y)' ! 1072: Represents the bitwise exclusive-or of the values represented by ! 1073: X and Y, carried out in machine mode M. This is valid only if X ! 1074: and Y both are valid for mode M, which must be a fixed-point mode. ! 1075: ! 1076: `(lshift:M X C)' ! 1077: Represents the result of logically shifting X left by C places. ! 1078: X must be valid for the mode M, a fixed-point machine mode. C ! 1079: must be valid for a fixed-point mode; which mode is determined ! 1080: by the mode called for in the machine description entry for the ! 1081: left-shift instruction. For example, on the Vax, the mode of C ! 1082: is `QImode' regardless of M. ! 1083: ! 1084: On some machines, negative values of C may be meaningful; this ! 1085: is why logical left shift and arithmetic left shift are ! 1086: distinguished. For example, Vaxes have no right-shift ! 1087: instructions, and right shifts are represented as left-shift ! 1088: instructions whose counts happen to be negative constants or ! 1089: else computed (in a previous instruction) by negation. ! 1090: ! 1091: `(ashift:M X C)' ! 1092: Like `lshift' but for arithmetic left shift. ! 1093: ! 1094: `(lshiftrt:M X C)' ! 1095: `(ashiftrt:M X C)' ! 1096: Like `lshift' and `ashift' but for right shift. ! 1097: ! 1098: `(rotate:M X C)' ! 1099: `(rotatert:M X C)' ! 1100: Similar but represent left and right rotate. ! 1101: ! 1102: `(abs:M X)' ! 1103: Represents the absolute value of X, computed in mode M. X must ! 1104: be valid for M. ! 1105: ! 1106: `(sqrt:M X)' ! 1107: Represents the square root of X, computed in mode M. X must be ! 1108: valid for M. Most often M will be a floating point mode. ! 1109: ! 1110: `(ffs:M X)' ! 1111: Represents the one plus the index of the least significant 1-bit ! 1112: in X, represented as an integer of mode M. (The value is zero ! 1113: if X is zero.) The mode of X need not be M; depending on the ! 1114: target machine, various mode combinations may be valid. ! 1115: ! 1116:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.