![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 2.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 2.x] / gcc |
1.1.1.5 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
1.1 root 2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
1.1.1.5 root 6: Published by the Free Software Foundation 675 Massachusetts Avenue
7: Cambridge, MA 02139 USA
8:
9: Copyright (C) 1988, 1989, 1992, 1993 Free Software Foundation, Inc.
1.1 root 10:
1.1.1.3 root 11: Permission is granted to make and distribute verbatim copies of this
12: manual provided the copyright notice and this permission notice are
13: preserved on all copies.
1.1 root 14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
1.1.1.4 root 17: that the sections entitled "GNU General Public License" and "Protect
18: Your Freedom--Fight `Look And Feel'" are included exactly as in the
19: original, and provided that the entire resulting derived work is
20: distributed under the terms of a permission notice identical to this
21: one.
1.1 root 22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
1.1.1.3 root 25: versions, except that the sections entitled "GNU General Public
1.1.1.4 root 26: License" and "Protect Your Freedom--Fight `Look And Feel'", and this
27: permission notice, may be included in translations approved by the Free
28: Software Foundation instead of in the original English.
1.1.1.3 root 29:
30:
1.1.1.6 ! root 31: File: gcc.info, Node: Complex, Next: Zero Length, Prev: Long Long, Up: C Extensions
! 32:
! 33: Complex Numbers
! 34: ===============
! 35:
! 36: GNU C supports complex data types. You can declare both complex
! 37: integer types and complex floating types, using the keyword
! 38: `__complex__'.
! 39:
! 40: For example, `__complex__ double x;' declares `x' as a variable
! 41: whose real part and imaginary part are both of type `double'.
! 42: `__complex__ short int y;' declares `y' to have real and imaginary
! 43: parts of type `short int'; this is not likely to be useful, but it
! 44: shows that the set of complex types is complete.
! 45:
! 46: To write a constant with a complex data type, use the suffix `i' or
! 47: `j' (either one; they are equivalent). For example, `2.5fi' has type
! 48: `__complex__ float' and `3i' has type `__complex__ int'. Such a
! 49: constant always has a pure imaginary value, but you can form any
! 50: complex value you like by adding one to a real constant.
! 51:
! 52: To extract the real part of a complex-valued expression EXP, write
! 53: `__real__ EXP'. Likewise, use `__imag__' to extract the imaginary part.
! 54:
! 55: The operator `~' performs complex conjugation when used on a value
! 56: with a complex type.
! 57:
! 58: GNU CC can allocate complex automatic variables in a noncontiguous
! 59: fashion; it's even possible for the real part to be in a register while
! 60: the imaginary part is on the stack (or vice-versa). None of the
! 61: supported debugging info formats has a way to represent noncontiguous
! 62: allocation like this, so GNU CC describes a noncontiguous complex
! 63: variable as if it were two separate variables of noncomplex type. If
! 64: the variable's actual name is `foo', the two fictitious variables are
! 65: named `foo$real' and `foo$imag'. You can examine and set these two
! 66: fictitious variables with your debugger.
! 67:
! 68: A future version of GDB will know how to recognize such pairs and
! 69: treat them as a single variable with a complex type.
! 70:
! 71:
! 72: File: gcc.info, Node: Zero Length, Next: Variable Length, Prev: Complex, Up: C Extensions
! 73:
! 74: Arrays of Length Zero
! 75: =====================
! 76:
! 77: Zero-length arrays are allowed in GNU C. They are very useful as
! 78: the last element of a structure which is really a header for a
! 79: variable-length object:
! 80:
! 81: struct line {
! 82: int length;
! 83: char contents[0];
! 84: };
! 85:
! 86: {
! 87: struct line *thisline = (struct line *)
! 88: malloc (sizeof (struct line) + this_length);
! 89: thisline->length = this_length;
! 90: }
! 91:
! 92: In standard C, you would have to give `contents' a length of 1, which
! 93: means either you waste space or complicate the argument to `malloc'.
! 94:
! 95:
! 96: File: gcc.info, Node: Variable Length, Next: Macro Varargs, Prev: Zero Length, Up: C Extensions
! 97:
! 98: Arrays of Variable Length
! 99: =========================
! 100:
! 101: Variable-length automatic arrays are allowed in GNU C. These arrays
! 102: are declared like any other automatic arrays, but with a length that is
! 103: not a constant expression. The storage is allocated at the point of
! 104: declaration and deallocated when the brace-level is exited. For
! 105: example:
! 106:
! 107: FILE *
! 108: concat_fopen (char *s1, char *s2, char *mode)
! 109: {
! 110: char str[strlen (s1) + strlen (s2) + 1];
! 111: strcpy (str, s1);
! 112: strcat (str, s2);
! 113: return fopen (str, mode);
! 114: }
! 115:
! 116: Jumping or breaking out of the scope of the array name deallocates
! 117: the storage. Jumping into the scope is not allowed; you get an error
! 118: message for it.
! 119:
! 120: You can use the function `alloca' to get an effect much like
! 121: variable-length arrays. The function `alloca' is available in many
! 122: other C implementations (but not in all). On the other hand,
! 123: variable-length arrays are more elegant.
! 124:
! 125: There are other differences between these two methods. Space
! 126: allocated with `alloca' exists until the containing *function* returns.
! 127: The space for a variable-length array is deallocated as soon as the
! 128: array name's scope ends. (If you use both variable-length arrays and
! 129: `alloca' in the same function, deallocation of a variable-length array
! 130: will also deallocate anything more recently allocated with `alloca'.)
! 131:
! 132: You can also use variable-length arrays as arguments to functions:
! 133:
! 134: struct entry
! 135: tester (int len, char data[len][len])
! 136: {
! 137: ...
! 138: }
! 139:
! 140: The length of an array is computed once when the storage is allocated
! 141: and is remembered for the scope of the array in case you access it with
! 142: `sizeof'.
! 143:
! 144: If you want to pass the array first and the length afterward, you can
! 145: use a forward declaration in the parameter list--another GNU extension.
! 146:
! 147: struct entry
! 148: tester (int len; char data[len][len], int len)
! 149: {
! 150: ...
! 151: }
! 152:
! 153: The `int len' before the semicolon is a "parameter forward
! 154: declaration", and it serves the purpose of making the name `len' known
! 155: when the declaration of `data' is parsed.
! 156:
! 157: You can write any number of such parameter forward declarations in
! 158: the parameter list. They can be separated by commas or semicolons, but
! 159: the last one must end with a semicolon, which is followed by the "real"
! 160: parameter declarations. Each forward declaration must match a "real"
! 161: declaration in parameter name and data type.
! 162:
! 163:
! 164: File: gcc.info, Node: Macro Varargs, Next: Subscripting, Prev: Variable Length, Up: C Extensions
! 165:
! 166: Macros with Variable Numbers of Arguments
! 167: =========================================
! 168:
! 169: In GNU C, a macro can accept a variable number of arguments, much as
! 170: a function can. The syntax for defining the macro looks much like that
! 171: used for a function. Here is an example:
! 172:
! 173: #define eprintf(format, args...) \
! 174: fprintf (stderr, format , ## args)
! 175:
! 176: Here `args' is a "rest argument": it takes in zero or more
! 177: arguments, as many as the call contains. All of them plus the commas
! 178: between them form the value of `args', which is substituted into the
! 179: macro body where `args' is used. Thus, we have this expansion:
! 180:
! 181: eprintf ("%s:%d: ", input_file_name, line_number)
! 182: ==>
! 183: fprintf (stderr, "%s:%d: " , input_file_name, line_number)
! 184:
! 185: Note that the comma after the string constant comes from the definition
! 186: of `eprintf', whereas the last comma comes from the value of `args'.
! 187:
! 188: The reason for using `##' is to handle the case when `args' matches
! 189: no arguments at all. In this case, `args' has an empty value. In this
! 190: case, the second comma in the definition becomes an embarrassment: if
! 191: it got through to the expansion of the macro, we would get something
! 192: like this:
! 193:
! 194: fprintf (stderr, "success!\n" , )
! 195:
! 196: which is invalid C syntax. `##' gets rid of the comma, so we get the
! 197: following instead:
! 198:
! 199: fprintf (stderr, "success!\n")
! 200:
! 201: This is a special feature of the GNU C preprocessor: `##' before a
! 202: rest argument that is empty discards the preceding sequence of
! 203: non-whitespace characters from the macro definition. (If another macro
! 204: argument precedes, none of it is discarded.)
! 205:
! 206: It might be better to discard the last preprocessor token instead of
! 207: the last preceding sequence of non-whitespace characters; in fact, we
! 208: may someday change this feature to do so. We advise you to write the
! 209: macro definition so that the preceding sequence of non-whitespace
! 210: characters is just a single token, so that the meaning will not change
! 211: if we change the definition of this feature.
! 212:
! 213:
! 214: File: gcc.info, Node: Subscripting, Next: Pointer Arith, Prev: Macro Varargs, Up: C Extensions
! 215:
! 216: Non-Lvalue Arrays May Have Subscripts
! 217: =====================================
! 218:
! 219: Subscripting is allowed on arrays that are not lvalues, even though
! 220: the unary `&' operator is not. For example, this is valid in GNU C
! 221: though not valid in other C dialects:
! 222:
! 223: struct foo {int a[4];};
! 224:
! 225: struct foo f();
! 226:
! 227: bar (int index)
! 228: {
! 229: return f().a[index];
! 230: }
! 231:
! 232:
! 233: File: gcc.info, Node: Pointer Arith, Next: Initializers, Prev: Subscripting, Up: C Extensions
! 234:
! 235: Arithmetic on `void'- and Function-Pointers
! 236: ===========================================
! 237:
! 238: In GNU C, addition and subtraction operations are supported on
! 239: pointers to `void' and on pointers to functions. This is done by
! 240: treating the size of a `void' or of a function as 1.
! 241:
! 242: A consequence of this is that `sizeof' is also allowed on `void' and
! 243: on function types, and returns 1.
! 244:
! 245: The option `-Wpointer-arith' requests a warning if these extensions
! 246: are used.
! 247:
! 248:
! 249: File: gcc.info, Node: Initializers, Next: Constructors, Prev: Pointer Arith, Up: C Extensions
! 250:
! 251: Non-Constant Initializers
! 252: =========================
! 253:
! 254: The elements of an aggregate initializer for an automatic variable
! 255: are not required to be constant expressions in GNU C. Here is an
! 256: example of an initializer with run-time varying elements:
! 257:
! 258: foo (float f, float g)
! 259: {
! 260: float beat_freqs[2] = { f-g, f+g };
! 261: ...
! 262: }
! 263:
! 264:
! 265: File: gcc.info, Node: Constructors, Next: Labeled Elements, Prev: Initializers, Up: C Extensions
! 266:
! 267: Constructor Expressions
! 268: =======================
! 269:
! 270: GNU C supports constructor expressions. A constructor looks like a
! 271: cast containing an initializer. Its value is an object of the type
! 272: specified in the cast, containing the elements specified in the
! 273: initializer.
! 274:
! 275: Usually, the specified type is a structure. Assume that `struct
! 276: foo' and `structure' are declared as shown:
! 277:
! 278: struct foo {int a; char b[2];} structure;
! 279:
! 280: Here is an example of constructing a `struct foo' with a constructor:
! 281:
! 282: structure = ((struct foo) {x + y, 'a', 0});
! 283:
! 284: This is equivalent to writing the following:
! 285:
! 286: {
! 287: struct foo temp = {x + y, 'a', 0};
! 288: structure = temp;
! 289: }
! 290:
! 291: You can also construct an array. If all the elements of the
! 292: constructor are (made up of) simple constant expressions, suitable for
! 293: use in initializers, then the constructor is an lvalue and can be
! 294: coerced to a pointer to its first element, as shown here:
! 295:
! 296: char **foo = (char *[]) { "x", "y", "z" };
! 297:
! 298: Array constructors whose elements are not simple constants are not
! 299: very useful, because the constructor is not an lvalue. There are only
! 300: two valid ways to use it: to subscript it, or initialize an array
! 301: variable with it. The former is probably slower than a `switch'
! 302: statement, while the latter does the same thing an ordinary C
! 303: initializer would do. Here is an example of subscripting an array
! 304: constructor:
! 305:
! 306: output = ((int[]) { 2, x, 28 }) [input];
! 307:
! 308: Constructor expressions for scalar types and union types are is also
! 309: allowed, but then the constructor expression is equivalent to a cast.
! 310:
! 311:
! 312: File: gcc.info, Node: Labeled Elements, Next: Cast to Union, Prev: Constructors, Up: C Extensions
! 313:
! 314: Labeled Elements in Initializers
! 315: ================================
! 316:
! 317: Standard C requires the elements of an initializer to appear in a
! 318: fixed order, the same as the order of the elements in the array or
! 319: structure being initialized.
! 320:
! 321: In GNU C you can give the elements in any order, specifying the array
! 322: indices or structure field names they apply to.
! 323:
! 324: To specify an array index, write `[INDEX] =' before the element
! 325: value. For example,
! 326:
! 327: int a[6] = { [4] = 29, [2] = 15 };
! 328:
! 329: is equivalent to
! 330:
! 331: int a[6] = { 0, 0, 15, 0, 29, 0 };
! 332:
! 333: The index values must be constant expressions, even if the array being
! 334: initialized is automatic.
! 335:
! 336: In a structure initializer, specify the name of a field to initialize
! 337: with `FIELDNAME:' before the element value. For example, given the
! 338: following structure,
! 339:
! 340: struct point { int x, y; };
! 341:
! 342: the following initialization
! 343:
! 344: struct point p = { y: yvalue, x: xvalue };
! 345:
! 346: is equivalent to
! 347:
! 348: struct point p = { xvalue, yvalue };
! 349:
! 350: Another syntax which has the same meaning is `.FIELDNAME ='., as
! 351: shown here:
! 352:
! 353: struct point p = { .y = yvalue, .x = xvalue };
! 354:
! 355: You can also use an element label (with either the colon syntax or
! 356: the period-equal syntax) when initializing a union, to specify which
! 357: element of the union should be used. For example,
! 358:
! 359: union foo { int i; double d; };
! 360:
! 361: union foo f = { d: 4 };
! 362:
! 363: will convert 4 to a `double' to store it in the union using the second
! 364: element. By contrast, casting 4 to type `union foo' would store it
! 365: into the union as the integer `i', since it is an integer. (*Note Cast
! 366: to Union::.)
! 367:
! 368: You can combine this technique of naming elements with ordinary C
! 369: initialization of successive elements. Each initializer element that
! 370: does not have a label applies to the next consecutive element of the
! 371: array or structure. For example,
! 372:
! 373: int a[6] = { [1] = v1, v2, [4] = v4 };
! 374:
! 375: is equivalent to
! 376:
! 377: int a[6] = { 0, v1, v2, 0, v4, 0 };
! 378:
! 379: Labeling the elements of an array initializer is especially useful
! 380: when the indices are characters or belong to an `enum' type. For
! 381: example:
! 382:
! 383: int whitespace[256]
! 384: = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
! 385: ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
! 386:
! 387:
1.1.1.5 root 388: File: gcc.info, Node: Case Ranges, Next: Function Attributes, Prev: Cast to Union, Up: C Extensions
1.1.1.3 root 389:
1.1.1.5 root 390: Case Ranges
391: ===========
1.1.1.3 root 392:
1.1.1.5 root 393: You can specify a range of consecutive values in a single `case'
394: label, like this:
1.1.1.4 root 395:
1.1.1.5 root 396: case LOW ... HIGH:
1.1.1.2 root 397:
1.1.1.5 root 398: This has the same effect as the proper number of individual `case'
399: labels, one for each integer value from LOW to HIGH, inclusive.
400:
401: This feature is especially useful for ranges of ASCII character
402: codes:
403:
404: case 'A' ... 'Z':
405:
406: *Be careful:* Write spaces around the `...', for otherwise it may be
407: parsed wrong when you use it with integer values. For example, write
408: this:
409:
410: case 1 ... 5:
1.1.1.2 root 411:
1.1.1.5 root 412: rather than this:
413:
414: case 1...5:
415:
416: *Warning to C++ users:* When compiling C++, you must write two dots
417: `..' rather than three to specify a range in case statements, thus:
418:
419: case 'A' .. 'Z':
420:
421: This is an anachronism in the GNU C++ front end, and will be
422: rectified in a future release.
1.1.1.2 root 423:
424:
1.1.1.5 root 425: File: gcc.info, Node: Cast to Union, Next: Case Ranges, Prev: Labeled Elements, Up: C Extensions
1.1.1.2 root 426:
1.1.1.5 root 427: Cast to a Union Type
428: ====================
1.1.1.2 root 429:
1.1.1.5 root 430: A cast to union type is similar to other casts, except that the type
431: specified is a union type. You can specify the type either with `union
432: TAG' or with a typedef name. A cast to union is actually a constructor
433: though, not a cast, and hence does not yield an lvalue like normal
434: casts. (*Note Constructors::.)
435:
436: The types that may be cast to the union type are those of the members
437: of the union. Thus, given the following union and variables:
438:
439: union foo { int i; double d; };
440: int x;
441: double y;
442:
443: both `x' and `y' can be cast to type `union' foo.
444:
445: Using the cast as the right-hand side of an assignment to a variable
446: of union type is equivalent to storing in a member of the union:
447:
448: union foo u;
449: ...
450: u = (union foo) x == u.i = x
451: u = (union foo) y == u.d = y
452:
453: You can also use the union cast as a function argument:
454:
455: void hack (union foo);
456: ...
457: hack ((union foo) x);
1.1.1.2 root 458:
1.1.1.5 root 459:
460: File: gcc.info, Node: Function Attributes, Next: Function Prototypes, Prev: Case Ranges, Up: C Extensions
1.1.1.4 root 461:
1.1.1.5 root 462: Declaring Attributes of Functions
463: =================================
1.1.1.4 root 464:
1.1.1.5 root 465: In GNU C, you declare certain things about functions called in your
1.1.1.6 ! root 466: program which help the compiler optimize function calls and check your
! 467: code more carefully.
1.1.1.5 root 468:
469: The keyword `__attribute__' allows you to specify special attributes
470: when making a declaration. This keyword is followed by an attribute
1.1.1.6 ! root 471: specification inside double parentheses. Three attributes, `noreturn',
! 472: `const' and `format', are currently defined for functions. Others are
! 473: implemented for variables and structure fields (*note Variable
! 474: Attributes::.).
! 475:
! 476: `noreturn'
! 477: A few standard library functions, such as `abort' and `exit',
! 478: cannot return. GNU CC knows this automatically. Some programs
! 479: define their own functions that never return. You can declare them
! 480: `noreturn' to tell the compiler this fact. For example,
! 481:
! 482: void fatal () __attribute__ ((noreturn));
! 483:
! 484: void
! 485: fatal (...)
! 486: {
! 487: ... /* Print error message. */ ...
! 488: exit (1);
! 489: }
! 490:
! 491: The `noreturn' keyword tells the compiler to assume that `fatal'
! 492: cannot return. It can then optimize without regard to what would
! 493: happen if `fatal' ever did return. This makes slightly better
! 494: code. More importantly, it helps avoid spurious warnings of
! 495: uninitialized variables.
! 496:
! 497: Do not assume that registers saved by the calling function are
! 498: restored before calling the `noreturn' function.
! 499:
! 500: It does not make sense for a `noreturn' function to have a return
! 501: type other than `void'.
! 502:
! 503: The attribute `noreturn' is not implemented in GNU C versions
! 504: earlier than 2.5. An alternative way to declare that a function
! 505: does not return, which works in the current version and in some
! 506: older versions, is as follows:
! 507:
! 508: typedef void voidfn ();
! 509:
! 510: volatile voidfn fatal;
! 511:
! 512: `const'
! 513: Many functions do not examine any values except their arguments,
! 514: and have no effects except the return value. Such a function can
! 515: be subject to common subexpression elimination and loop
! 516: optimization just as an arithmetic operator would be. These
! 517: functions should be declared with the attribute `const'. For
! 518: example,
! 519:
! 520: int square (int) __attribute__ ((const));
! 521:
! 522: says that the hypothetical function `square' is safe to call fewer
! 523: times than the program says.
! 524:
! 525: The attribute `const' is not implemented in GNU C versions earlier
! 526: than 2.5. An alternative way to declare that a function has no
! 527: side effects, which works in the current version and in some older
! 528: versions, is as follows:
! 529:
! 530: typedef int intfn ();
! 531:
! 532: extern const intfn square;
! 533:
! 534: Note that a function that has pointer arguments and examines the
! 535: data pointed to must *not* be declared `const'. Likewise, a
! 536: function that calls a non-`const' function usually must not be
! 537: `const'. It does not make sense for a `const' function to return
! 538: `void'.
1.1.1.5 root 539:
540: `format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
541: The `format' attribute specifies that a function takes `printf' or
542: `scanf' style arguments which should be type-checked against a
543: format string. For example, the declaration:
544:
545: extern int
546: my_printf (void *my_object, const char *my_format, ...)
547: __attribute__ ((format (printf, 2, 3)));
548:
549: causes the compiler to check the arguments in calls to `my_printf'
550: for consistency with the `printf' style format string argument
551: `my_format'.
552:
553: The parameter ARCHETYPE determines how the format string is
554: interpreted, and should be either `printf' or `scanf'. The
555: parameter STRING-INDEX specifies which argument is the format
556: string argument (starting from 1), while FIRST-TO-CHECK is the
557: number of the first argument to check against the format string.
558: For functions where the arguments are not available to be checked
559: (such as `vprintf'), specify the third parameter as zero. In this
560: case the compiler only checks the format string for consistency.
561:
562: In the example above, the format string (`my_format') is the second
563: argument of the function `my_print', and the arguments to check
564: start with the third argument, so the correct parameters for the
565: format attribute are 2 and 3.
566:
567: The `format' attribute allows you to identify your own functions
568: which take format strings as arguments, so that GNU CC can check
569: the calls to these functions for errors. The compiler always
570: checks formats for the ANSI library functions `printf', `fprintf',
571: `sprintf', `scanf', `fscanf', `sscanf', `vprintf', `vfprintf' and
572: `vsprintf' whenever such warnings are requested (using
573: `-Wformat'), so there is no need to modify the header file
574: `stdio.h'.
1.1.1.4 root 575:
1.1.1.6 ! root 576: You can specify multiple attributes in a declaration by separating
! 577: them by commas within the double parentheses. Currently it is never
! 578: useful to do this for a function, but it can be useful for a variable.
! 579:
! 580: Some people object to the `__attribute__' feature, suggesting that
! 581: ANSI C's `#pragma' should be used instead. There are two reasons for
! 582: not doing this.
! 583:
! 584: 1. It is impossible to generate `#pragma' commands from a macro.
! 585:
! 586: 2. There is no telling what the same `#pragma' might mean in another
! 587: compiler.
! 588:
! 589: These two reasons apply to almost any application that might be
! 590: proposed for `#pragma'. It is basically a mistake to use `#pragma' for
! 591: *anything*.
! 592:
1.1.1.5 root 593:
594: File: gcc.info, Node: Function Prototypes, Next: Dollar Signs, Prev: Function Attributes, Up: C Extensions
1.1.1.4 root 595:
1.1.1.5 root 596: Prototypes and Old-Style Function Definitions
597: =============================================
1.1.1.4 root 598:
1.1.1.5 root 599: GNU C extends ANSI C to allow a function prototype to override a
600: later old-style non-prototype definition. Consider the following
601: example:
602:
603: /* Use prototypes unless the compiler is old-fashioned. */
604: #if __STDC__
1.1.1.6 ! root 605: #define P(x) x
1.1.1.5 root 606: #else
607: #define P(x) ()
608: #endif
609:
610: /* Prototype function declaration. */
611: int isroot P((uid_t));
612:
613: /* Old-style function definition. */
614: int
615: isroot (x) /* ??? lossage here ??? */
616: uid_t x;
617: {
618: return x == 0;
619: }
620:
621: Suppose the type `uid_t' happens to be `short'. ANSI C does not
622: allow this example, because subword arguments in old-style
623: non-prototype definitions are promoted. Therefore in this example the
624: function definition's argument is really an `int', which does not match
625: the prototype argument type of `short'.
626:
627: This restriction of ANSI C makes it hard to write code that is
628: portable to traditional C compilers, because the programmer does not
629: know whether the `uid_t' type is `short', `int', or `long'. Therefore,
630: in cases like these GNU C allows a prototype to override a later
631: old-style definition. More precisely, in GNU C, a function prototype
632: argument type overrides the argument type specified by a later
633: old-style definition if the former type is the same as the latter type
634: before promotion. Thus in GNU C the above example is equivalent to the
635: following:
636:
637: int isroot (uid_t);
638:
639: int
640: isroot (uid_t x)
641: {
642: return x == 0;
643: }
1.1.1.4 root 644:
1.1.1.5 root 645:
646: File: gcc.info, Node: Dollar Signs, Next: Character Escapes, Prev: Function Prototypes, Up: C Extensions
1.1.1.4 root 647:
1.1.1.5 root 648: Dollar Signs in Identifier Names
649: ================================
1.1.1.4 root 650:
1.1.1.5 root 651: In GNU C, you may use dollar signs in identifier names. This is
652: because many traditional C implementations allow such identifiers.
1.1.1.4 root 653:
1.1.1.5 root 654: On some machines, dollar signs are allowed in identifiers if you
655: specify `-traditional'. On a few systems they are allowed by default,
656: even if you do not use `-traditional'. But they are never allowed if
657: you specify `-ansi'.
658:
659: There are certain ANSI C programs (obscure, to be sure) that would
660: compile incorrectly if dollar signs were permitted in identifiers. For
661: example:
662:
663: #define foo(a) #a
664: #define lose(b) foo (b)
665: #define test$
666: lose (test)
1.1.1.2 root 667:
668:
1.1.1.5 root 669: File: gcc.info, Node: Character Escapes, Next: Variable Attributes, Prev: Dollar Signs, Up: C Extensions
1.1 root 670:
1.1.1.5 root 671: The Character ESC in Constants
672: ==============================
673:
674: You can use the sequence `\e' in a string or character constant to
675: stand for the ASCII character ESC.
1.1 root 676:
1.1.1.5 root 677:
678: File: gcc.info, Node: Alignment, Next: Inline, Prev: Variable Attributes, Up: C Extensions
1.1.1.4 root 679:
1.1.1.5 root 680: Inquiring on Alignment of Types or Variables
681: ============================================
1.1.1.4 root 682:
1.1.1.5 root 683: The keyword `__alignof__' allows you to inquire about how an object
684: is aligned, or the minimum alignment usually required by a type. Its
685: syntax is just like `sizeof'.
686:
687: For example, if the target machine requires a `double' value to be
688: aligned on an 8-byte boundary, then `__alignof__ (double)' is 8. This
689: is true on many RISC machines. On more traditional machine designs,
690: `__alignof__ (double)' is 4 or even 2.
691:
692: Some machines never actually require alignment; they allow reference
693: to any data type even at an odd addresses. For these machines,
694: `__alignof__' reports the *recommended* alignment of a type.
695:
696: When the operand of `__alignof__' is an lvalue rather than a type,
697: the value is the largest alignment that the lvalue is known to have.
698: It may have this alignment as a result of its data type, or because it
699: is part of a structure and inherits alignment from that structure. For
700: example, after this declaration:
701:
702: struct foo { int x; char y; } foo1;
703:
704: the value of `__alignof__ (foo1.y)' is probably 2 or 4, the same as
705: `__alignof__ (int)', even though the data type of `foo1.y' does not
706: itself demand any alignment.
1.1.1.4 root 707:
1.1.1.5 root 708: A related feature which lets you specify the alignment of an object
709: is `__attribute__ ((aligned (ALIGNMENT)))'; see the following section.
1.1.1.4 root 710:
1.1.1.5 root 711:
712: File: gcc.info, Node: Variable Attributes, Next: Alignment, Prev: Character Escapes, Up: C Extensions
1.1.1.4 root 713:
1.1.1.5 root 714: Specifying Attributes of Variables
715: ==================================
1.1.1.4 root 716:
1.1.1.5 root 717: The keyword `__attribute__' allows you to specify special attributes
718: of variables or structure fields. This keyword is followed by an
719: attribute specification inside double parentheses. Four attributes are
720: currently defined: `aligned', `format', `mode' and `packed'. `format'
721: is used for functions, and thus not documented here; see *Note Function
722: Attributes::.
723:
724: `aligned (ALIGNMENT)'
725: This attribute specifies a minimum alignment for the variable or
726: structure field, measured in bytes. For example, the declaration:
727:
728: int x __attribute__ ((aligned (16))) = 0;
729:
730: causes the compiler to allocate the global variable `x' on a
731: 16-byte boundary. On a 68040, this could be used in conjunction
732: with an `asm' expression to access the `move16' instruction which
733: requires 16-byte aligned operands.
734:
735: You can also specify the alignment of structure fields. For
736: example, to create a double-word aligned `int' pair, you could
737: write:
738:
739: struct foo { int x[2] __attribute__ ((aligned (8))); };
740:
741: This is an alternative to creating a union with a `double' member
742: that forces the union to be double-word aligned.
743:
744: It is not possible to specify the alignment of functions; the
745: alignment of functions is determined by the machine's requirements
746: and cannot be changed. You cannot specify alignment for a typedef
747: name because such a name is just an alias, not a distinct type.
748:
749: The `aligned' attribute can only increase the alignment; but you
750: can decrease it by specifying `packed' as well. See below.
751:
752: The linker of your operating system imposes a maximum alignment.
753: If the linker aligns each object file on a four byte boundary,
754: then it is beyond the compiler's power to cause anything to be
755: aligned to a larger boundary than that. For example, if the
756: linker happens to put this object file at address 136 (eight more
757: than a multiple of 64), then the compiler cannot guarantee an
758: alignment of more than 8 just by aligning variables in the object
759: file.
760:
761: `mode (MODE)'
762: This attribute specifies the data type for the
763: declaration--whichever type corresponds to the mode MODE. This in
764: effect lets you request an integer or floating point type
765: according to its width.
766:
767: `packed'
768: The `packed' attribute specifies that a variable or structure field
769: should have the smallest possible alignment--one byte for a
770: variable, and one bit for a field, unless you specify a larger
771: value with the `aligned' attribute.
1.1.1.4 root 772:
1.1.1.6 ! root 773: To specify multiple attributes, separate them by commas within the
! 774: double parentheses: for example, `__attribute__ ((aligned (16),
! 775: packed))'.
! 776:
1.1.1.5 root 777:
778: File: gcc.info, Node: Inline, Next: Extended Asm, Prev: Alignment, Up: C Extensions
1.1.1.4 root 779:
1.1.1.5 root 780: An Inline Function is As Fast As a Macro
781: ========================================
782:
783: By declaring a function `inline', you can direct GNU CC to integrate
784: that function's code into the code for its callers. This makes
785: execution faster by eliminating the function-call overhead; in
786: addition, if any of the actual argument values are constant, their known
787: values may permit simplifications at compile time so that not all of the
788: inline function's code needs to be included. The effect on code size is
789: less predictable; object code may be larger or smaller with function
790: inlining, depending on the particular case. Inlining of functions is an
791: optimization and it really "works" only in optimizing compilation. If
792: you don't use `-O', no function is really inline.
793:
794: To declare a function inline, use the `inline' keyword in its
795: declaration, like this:
796:
797: inline int
798: inc (int *a)
799: {
800: (*a)++;
801: }
802:
803: (If you are writing a header file to be included in ANSI C programs,
804: write `__inline__' instead of `inline'. *Note Alternate Keywords::.)
805:
806: You can also make all "simple enough" functions inline with the
807: option `-finline-functions'. Note that certain usages in a function
808: definition can make it unsuitable for inline substitution.
809:
810: For C++ programs, GNU CC automatically inlines member functions even
811: if they are not explicitly declared `inline'. (You can override this
812: with `-fno-default-inline'; *note Options Controlling C++ Dialect: C++
813: Dialect Options..)
814:
815: When a function is both inline and `static', if all calls to the
816: function are integrated into the caller, and the function's address is
817: never used, then the function's own assembler code is never referenced.
818: In this case, GNU CC does not actually output assembler code for the
819: function, unless you specify the option `-fkeep-inline-functions'.
820: Some calls cannot be integrated for various reasons (in particular,
821: calls that precede the function's definition cannot be integrated, and
822: neither can recursive calls within the definition). If there is a
823: nonintegrated call, then the function is compiled to assembler code as
824: usual. The function must also be compiled as usual if the program
825: refers to its address, because that can't be inlined.
826:
827: When an inline function is not `static', then the compiler must
828: assume that there may be calls from other source files; since a global
829: symbol can be defined only once in any program, the function must not
830: be defined in the other source files, so the calls therein cannot be
831: integrated. Therefore, a non-`static' inline function is always
832: compiled on its own in the usual fashion.
833:
834: If you specify both `inline' and `extern' in the function
835: definition, then the definition is used only for inlining. In no case
836: is the function compiled on its own, not even if you refer to its
837: address explicitly. Such an address becomes an external reference, as
838: if you had only declared the function, and had not defined it.
839:
840: This combination of `inline' and `extern' has almost the effect of a
841: macro. The way to use it is to put a function definition in a header
842: file with these keywords, and put another copy of the definition
843: (lacking `inline' and `extern') in a library file. The definition in
844: the header file will cause most calls to the function to be inlined.
845: If any uses of the function remain, they will refer to the single copy
846: in the library.
847:
848: GNU C does not inline any functions when not optimizing. It is not
849: clear whether it is better to inline or not, in this case, but we found
850: that a correct implementation when not optimizing was difficult. So we
851: did the easy thing, and turned it off.
1.1 root 852:
853:
1.1.1.5 root 854: File: gcc.info, Node: Extended Asm, Next: Asm Labels, Prev: Inline, Up: C Extensions
855:
856: Assembler Instructions with C Expression Operands
857: =================================================
858:
859: In an assembler instruction using `asm', you can now specify the
860: operands of the instruction using C expressions. This means no more
861: guessing which registers or memory locations will contain the data you
862: want to use.
863:
864: You must specify an assembler instruction template much like what
865: appears in a machine description, plus an operand constraint string for
866: each operand.
867:
868: For example, here is how to use the 68881's `fsinx' instruction:
869:
870: asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
871:
872: Here `angle' is the C expression for the input operand while `result'
873: is that of the output operand. Each has `"f"' as its operand
874: constraint, saying that a floating point register is required. The `='
875: in `=f' indicates that the operand is an output; all output operands'
876: constraints must use `='. The constraints use the same language used
877: in the machine description (*note Constraints::.).
878:
879: Each operand is described by an operand-constraint string followed
880: by the C expression in parentheses. A colon separates the assembler
881: template from the first output operand, and another separates the last
882: output operand from the first input, if any. Commas separate output
883: operands and separate inputs. The total number of operands is limited
884: to ten or to the maximum number of operands in any instruction pattern
885: in the machine description, whichever is greater.
886:
887: If there are no output operands, and there are input operands, then
888: there must be two consecutive colons surrounding the place where the
889: output operands would go.
890:
891: Output operand expressions must be lvalues; the compiler can check
892: this. The input operands need not be lvalues. The compiler cannot
893: check whether the operands have data types that are reasonable for the
894: instruction being executed. It does not parse the assembler
895: instruction template and does not know what it means, or whether it is
896: valid assembler input. The extended `asm' feature is most often used
897: for machine instructions that the compiler itself does not know exist.
898:
899: The output operands must be write-only; GNU CC will assume that the
900: values in these operands before the instruction are dead and need not be
901: generated. Extended asm does not support input-output or read-write
902: operands. For this reason, the constraint character `+', which
903: indicates such an operand, may not be used.
904:
905: When the assembler instruction has a read-write operand, or an
906: operand in which only some of the bits are to be changed, you must
907: logically split its function into two separate operands, one input
908: operand and one write-only output operand. The connection between them
909: is expressed by constraints which say they need to be in the same
910: location when the instruction executes. You can use the same C
911: expression for both operands, or different expressions. For example,
912: here we write the (fictitious) `combine' instruction with `bar' as its
913: read-only source operand and `foo' as its read-write destination:
914:
915: asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));
916:
917: The constraint `"0"' for operand 1 says that it must occupy the same
918: location as operand 0. A digit in constraint is allowed only in an
919: input operand, and it must refer to an output operand.
920:
921: Only a digit in the constraint can guarantee that one operand will
922: be in the same place as another. The mere fact that `foo' is the value
923: of both operands is not enough to guarantee that they will be in the
924: same place in the generated assembler code. The following would not
925: work:
926:
927: asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));
928:
929: Various optimizations or reloading could cause operands 0 and 1 to
930: be in different registers; GNU CC knows no reason not to do so. For
931: example, the compiler might find a copy of the value of `foo' in one
932: register and use it for operand 1, but generate the output operand 0 in
933: a different register (copying it afterward to `foo''s own address). Of
934: course, since the register for operand 1 is not even mentioned in the
935: assembler code, the result will not work, but GNU CC can't tell that.
936:
937: Some instructions clobber specific hard registers. To describe
938: this, write a third colon after the input operands, followed by the
939: names of the clobbered hard registers (given as strings). Here is a
940: realistic example for the Vax:
941:
942: asm volatile ("movc3 %0,%1,%2"
943: : /* no outputs */
944: : "g" (from), "g" (to), "g" (count)
945: : "r0", "r1", "r2", "r3", "r4", "r5");
946:
947: If you refer to a particular hardware register from the assembler
948: code, then you will probably have to list the register after the third
949: colon to tell the compiler that the register's value is modified. In
950: many assemblers, the register names begin with `%'; to produce one `%'
951: in the assembler code, you must write `%%' in the input.
952:
953: If your assembler instruction can alter the condition code register,
954: add `cc' to the list of clobbered registers. GNU CC on some machines
955: represents the condition codes as a specific hardware register; `cc'
956: serves to name this register. On other machines, the condition code is
957: handled differently, and specifying `cc' has no effect. But it is
958: valid no matter what the machine.
959:
960: If your assembler instruction modifies memory in an unpredictable
961: fashion, add `memory' to the list of clobbered registers. This will
962: cause GNU CC to not keep memory values cached in registers across the
963: assembler instruction.
964:
965: You can put multiple assembler instructions together in a single
966: `asm' template, separated either with newlines (written as `\n') or with
967: semicolons if the assembler allows such semicolons. The GNU assembler
968: allows semicolons and all Unix assemblers seem to do so. The input
969: operands are guaranteed not to use any of the clobbered registers, and
970: neither will the output operands' addresses, so you can read and write
971: the clobbered registers as many times as you like. Here is an example
972: of multiple instructions in a template; it assumes that the subroutine
973: `_foo' accepts arguments in registers 9 and 10:
974:
975: asm ("movl %0,r9;movl %1,r10;call _foo"
976: : /* no outputs */
977: : "g" (from), "g" (to)
978: : "r9", "r10");
979:
980: Unless an output operand has the `&' constraint modifier, GNU CC may
981: allocate it in the same register as an unrelated input operand, on the
982: assumption that the inputs are consumed before the outputs are produced.
983: This assumption may be false if the assembler code actually consists of
984: more than one instruction. In such a case, use `&' for each output
985: operand that may not overlap an input. *Note Modifiers::.
986:
987: If you want to test the condition code produced by an assembler
988: instruction, you must include a branch and a label in the `asm'
989: construct, as follows:
990:
991: asm ("clr %0;frob %1;beq 0f;mov #1,%0;0:"
992: : "g" (result)
993: : "g" (input));
994:
995: This assumes your assembler supports local labels, as the GNU assembler
996: and most Unix assemblers do.
997:
1.1.1.6 ! root 998: Speaking of labels, jumps from one `asm' to another are not
! 999: supported. The compiler's optimizers do not know about these jumps,
! 1000: and therefore they cannot take account of them when deciding how to
! 1001: optimize.
! 1002:
1.1.1.5 root 1003: Usually the most convenient way to use these `asm' instructions is to
1004: encapsulate them in macros that look like functions. For example,
1005:
1006: #define sin(x) \
1007: ({ double __value, __arg = (x); \
1008: asm ("fsinx %1,%0": "=f" (__value): "f" (__arg)); \
1009: __value; })
1010:
1011: Here the variable `__arg' is used to make sure that the instruction
1012: operates on a proper `double' value, and to accept only those arguments
1013: `x' which can convert automatically to a `double'.
1014:
1015: Another way to make sure the instruction operates on the correct
1016: data type is to use a cast in the `asm'. This is different from using a
1017: variable `__arg' in that it converts more different types. For
1018: example, if the desired type were `int', casting the argument to `int'
1019: would accept a pointer with no complaint, while assigning the argument
1020: to an `int' variable named `__arg' would warn about using a pointer
1021: unless the caller explicitly casts it.
1022:
1023: If an `asm' has output operands, GNU CC assumes for optimization
1024: purposes that the instruction has no side effects except to change the
1025: output operands. This does not mean that instructions with a side
1026: effect cannot be used, but you must be careful, because the compiler
1027: may eliminate them if the output operands aren't used, or move them out
1028: of loops, or replace two with one if they constitute a common
1029: subexpression. Also, if your instruction does have a side effect on a
1030: variable that otherwise appears not to change, the old value of the
1031: variable may be reused later if it happens to be found in a register.
1032:
1033: You can prevent an `asm' instruction from being deleted, moved
1034: significantly, or combined, by writing the keyword `volatile' after the
1035: `asm'. For example:
1036:
1037: #define set_priority(x) \
1038: asm volatile ("set_priority %0": /* no outputs */ : "g" (x))
1039:
1040: An instruction without output operands will not be deleted or moved
1041: significantly, regardless, unless it is unreachable.
1042:
1043: Note that even a volatile `asm' instruction can be moved in ways
1044: that appear insignificant to the compiler, such as across jump
1045: instructions. You can't expect a sequence of volatile `asm'
1046: instructions to remain perfectly consecutive. If you want consecutive
1047: output, use a single `asm'.
1048:
1049: It is a natural idea to look for a way to give access to the
1050: condition code left by the assembler instruction. However, when we
1051: attempted to implement this, we found no way to make it work reliably.
1052: The problem is that output operands might need reloading, which would
1053: result in additional following "store" instructions. On most machines,
1054: these instructions would alter the condition code before there was time
1055: to test it. This problem doesn't arise for ordinary "test" and
1056: "compare" instructions because they don't have any output operands.
1057:
1058: If you are writing a header file that should be includable in ANSI C
1059: programs, write `__asm__' instead of `asm'. *Note Alternate Keywords::.
1060:
1061:
1062: File: gcc.info, Node: Asm Labels, Next: Explicit Reg Vars, Prev: Extended Asm, Up: C Extensions
1063:
1064: Controlling Names Used in Assembler Code
1065: ========================================
1066:
1067: You can specify the name to be used in the assembler code for a C
1068: function or variable by writing the `asm' (or `__asm__') keyword after
1069: the declarator as follows:
1070:
1071: int foo asm ("myfoo") = 2;
1072:
1073: This specifies that the name to be used for the variable `foo' in the
1074: assembler code should be `myfoo' rather than the usual `_foo'.
1075:
1076: On systems where an underscore is normally prepended to the name of
1077: a C function or variable, this feature allows you to define names for
1078: the linker that do not start with an underscore.
1079:
1080: You cannot use `asm' in this way in a function *definition*; but you
1081: can get the same effect by writing a declaration for the function
1082: before its definition and putting `asm' there, like this:
1083:
1084: extern func () asm ("FUNC");
1085:
1086: func (x, y)
1087: int x, y;
1088: ...
1089:
1090: It is up to you to make sure that the assembler names you choose do
1091: not conflict with any other assembler symbols. Also, you must not use a
1092: register name; that would produce completely invalid assembler code.
1093: GNU CC does not as yet have the ability to store static variables in
1094: registers. Perhaps that will be added.
1095:
1096:
1097: File: gcc.info, Node: Explicit Reg Vars, Next: Alternate Keywords, Prev: Asm Labels, Up: C Extensions
1098:
1099: Variables in Specified Registers
1100: ================================
1101:
1102: GNU C allows you to put a few global variables into specified
1103: hardware registers. You can also specify the register in which an
1104: ordinary register variable should be allocated.
1105:
1106: * Global register variables reserve registers throughout the program.
1107: This may be useful in programs such as programming language
1108: interpreters which have a couple of global variables that are
1109: accessed very often.
1110:
1111: * Local register variables in specific registers do not reserve the
1112: registers. The compiler's data flow analysis is capable of
1113: determining where the specified registers contain live values, and
1114: where they are available for other uses.
1115:
1116: These local variables are sometimes convenient for use with the
1117: extended `asm' feature (*note Extended Asm::.), if you want to
1118: write one output of the assembler instruction directly into a
1119: particular register. (This will work provided the register you
1120: specify fits the constraints specified for that operand in the
1121: `asm'.)
1122:
1123: * Menu:
1124:
1125: * Global Reg Vars::
1126: * Local Reg Vars::
1127:
1128:
1129: File: gcc.info, Node: Global Reg Vars, Next: Local Reg Vars, Up: Explicit Reg Vars
1130:
1131: Defining Global Register Variables
1132: ----------------------------------
1133:
1134: You can define a global register variable in GNU C like this:
1135:
1136: register int *foo asm ("a5");
1137:
1138: Here `a5' is the name of the register which should be used. Choose a
1139: register which is normally saved and restored by function calls on your
1140: machine, so that library routines will not clobber it.
1141:
1142: Naturally the register name is cpu-dependent, so you would need to
1143: conditionalize your program according to cpu type. The register `a5'
1144: would be a good choice on a 68000 for a variable of pointer type. On
1145: machines with register windows, be sure to choose a "global" register
1146: that is not affected magically by the function call mechanism.
1147:
1148: In addition, operating systems on one type of cpu may differ in how
1149: they name the registers; then you would need additional conditionals.
1150: For example, some 68000 operating systems call this register `%a5'.
1151:
1152: Eventually there may be a way of asking the compiler to choose a
1153: register automatically, but first we need to figure out how it should
1154: choose and how to enable you to guide the choice. No solution is
1155: evident.
1156:
1157: Defining a global register variable in a certain register reserves
1158: that register entirely for this use, at least within the current
1159: compilation. The register will not be allocated for any other purpose
1160: in the functions in the current compilation. The register will not be
1161: saved and restored by these functions. Stores into this register are
1162: never deleted even if they would appear to be dead, but references may
1163: be deleted or moved or simplified.
1164:
1165: It is not safe to access the global register variables from signal
1166: handlers, or from more than one thread of control, because the system
1167: library routines may temporarily use the register for other things
1168: (unless you recompile them specially for the task at hand).
1169:
1170: It is not safe for one function that uses a global register variable
1171: to call another such function `foo' by way of a third function `lose'
1172: that was compiled without knowledge of this variable (i.e. in a
1173: different source file in which the variable wasn't declared). This is
1174: because `lose' might save the register and put some other value there.
1175: For example, you can't expect a global register variable to be
1176: available in the comparison-function that you pass to `qsort', since
1177: `qsort' might have put something else in that register. (If you are
1178: prepared to recompile `qsort' with the same global register variable,
1179: you can solve this problem.)
1180:
1181: If you want to recompile `qsort' or other source files which do not
1182: actually use your global register variable, so that they will not use
1183: that register for any other purpose, then it suffices to specify the
1184: compiler option `-ffixed-REG'. You need not actually add a global
1185: register declaration to their source code.
1186:
1187: A function which can alter the value of a global register variable
1188: cannot safely be called from a function compiled without this variable,
1189: because it could clobber the value the caller expects to find there on
1190: return. Therefore, the function which is the entry point into the part
1191: of the program that uses the global register variable must explicitly
1192: save and restore the value which belongs to its caller.
1193:
1194: On most machines, `longjmp' will restore to each global register
1195: variable the value it had at the time of the `setjmp'. On some
1196: machines, however, `longjmp' will not change the value of global
1197: register variables. To be portable, the function that called `setjmp'
1198: should make other arrangements to save the values of the global register
1199: variables, and to restore them in a `longjmp'. This way, the same
1200: thing will happen regardless of what `longjmp' does.
1201:
1202: All global register variable declarations must precede all function
1203: definitions. If such a declaration could appear after function
1204: definitions, the declaration would be too late to prevent the register
1205: from being used for other purposes in the preceding functions.
1206:
1207: Global register variables may not have initial values, because an
1208: executable file has no means to supply initial contents for a register.
1209:
1210: On the Sparc, there are reports that g3 ... g7 are suitable
1211: registers, but certain library functions, such as `getwd', as well as
1212: the subroutines for division and remainder, modify g3 and g4. g1 and
1213: g2 are local temporaries.
1214:
1215: On the 68000, a2 ... a5 should be suitable, as should d2 ... d7. Of
1216: course, it will not do to use more than a few of those.
1.1 root 1217:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.