![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-17 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [Apple XNU] / GNUtools / cc|
Return to gcc.info-17 CVS log | Up to [Apple XNU] / GNUtools / cc |
1.1 root 1: This is Info file gcc.info, produced by Makeinfo-1.54 from the input
2: file gcc.texi.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
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.
10:
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.
14:
15: Permission is granted to copy and distribute modified versions of
16: this manual under the conditions for verbatim copying, provided also
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.
22:
23: Permission is granted to copy and distribute translations of this
24: manual into another language, under the above conditions for modified
25: versions, except that the sections entitled "GNU General Public
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.
29:
30:
31: File: gcc.info, Node: Driver, Next: Run-time Target, Up: Target Macros
32:
33: Controlling the Compilation Driver, `gcc'
34: =========================================
35:
36: `SWITCH_TAKES_ARG (CHAR)'
37: A C expression which determines whether the option `-CHAR' takes
38: arguments. The value should be the number of arguments that
39: option takes-zero, for many options.
40:
41: By default, this macro is defined to handle the standard options
42: properly. You need not define it unless you wish to add additional
43: options which take arguments.
44:
45: `WORD_SWITCH_TAKES_ARG (NAME)'
46: A C expression which determines whether the option `-NAME' takes
47: arguments. The value should be the number of arguments that
48: option takes-zero, for many options. This macro rather than
49: `SWITCH_TAKES_ARG' is used for multi-character option names.
50:
51: By default, this macro is defined as
52: `DEFAULT_WORD_SWITCH_TAKES_ARG', which handles the standard options
53: properly. You need not define `WORD_SWITCH_TAKES_ARG' unless you
54: wish to add additional options which take arguments. Any
55: redefinition should call `DEFAULT_WORD_SWITCH_TAKES_ARG' and then
56: check for additional options.
57:
58: `SWITCHES_NEED_SPACES'
59: A string-valued C expression which is nonempty if the linker needs
60: a space between the `-L' or `-o' option and its argument.
61:
62: If this macro is not defined, the default value is 0.
63:
64: `CPP_SPEC'
65: A C string constant that tells the GNU CC driver program options to
66: pass to CPP. It can also specify how to translate options you
67: give to GNU CC into options for GNU CC to pass to the CPP.
68:
69: Do not define this macro if it does not need to do anything.
70:
71: `NO_BUILTIN_SIZE_TYPE'
72: If this macro is defined, the preprocessor will not define the
73: builtin macro `__SIZE_TYPE__'. The macro `__SIZE_TYPE__' must
74: then be defined by `CPP_SPEC' instead.
75:
76: This should be defined if `SIZE_TYPE' depends on target dependent
77: flags which are not accessible to the preprocessor. Otherwise, it
78: should not be defined.
79:
80: `NO_BUILTIN_PTRDIFF_TYPE'
81: If this macro is defined, the preprocessor will not define the
82: builtin macro `__PTRDIFF_TYPE__'. The macro `__PTRDIFF_TYPE__'
83: must then be defined by `CPP_SPEC' instead.
84:
85: This should be defined if `PTRDIFF_TYPE' depends on target
86: dependent flags which are not accessible to the preprocessor.
87: Otherwise, it should not be defined.
88:
89: `SIGNED_CHAR_SPEC'
90: A C string constant that tells the GNU CC driver program options to
91: pass to CPP. By default, this macro is defined to pass the option
92: `-D__CHAR_UNSIGNED__' to CPP if `char' will be treated as
93: `unsigned char' by `cc1'.
94:
95: Do not define this macro unless you need to override the default
96: definition.
97:
98: `CC1_SPEC'
99: A C string constant that tells the GNU CC driver program options to
100: pass to `cc1'. It can also specify how to translate options you
101: give to GNU CC into options for GNU CC to pass to the `cc1'.
102:
103: Do not define this macro if it does not need to do anything.
104:
105: `CC1PLUS_SPEC'
106: A C string constant that tells the GNU CC driver program options to
107: pass to `cc1plus'. It can also specify how to translate options
108: you give to GNU CC into options for GNU CC to pass to the
109: `cc1plus'.
110:
111: Do not define this macro if it does not need to do anything.
112:
113: `ASM_SPEC'
114: A C string constant that tells the GNU CC driver program options to
115: pass to the assembler. It can also specify how to translate
116: options you give to GNU CC into options for GNU CC to pass to the
117: assembler. See the file `sun3.h' for an example of this.
118:
119: Do not define this macro if it does not need to do anything.
120:
121: `ASM_FINAL_SPEC'
122: A C string constant that tells the GNU CC driver program how to
123: run any programs which cleanup after the normal assembler.
124: Normally, this is not needed. See the file `mips.h' for an
125: example of this.
126:
127: Do not define this macro if it does not need to do anything.
128:
129: `LINK_SPEC'
130: A C string constant that tells the GNU CC driver program options to
131: pass to the linker. It can also specify how to translate options
132: you give to GNU CC into options for GNU CC to pass to the linker.
133:
134: Do not define this macro if it does not need to do anything.
135:
136: `LIB_SPEC'
137: Another C string constant used much like `LINK_SPEC'. The
138: difference between the two is that `LIB_SPEC' is used at the end
139: of the command given to the linker.
140:
141: If this macro is not defined, a default is provided that loads the
142: standard C library from the usual place. See `gcc.c'.
143:
144: `STARTFILE_SPEC'
145: Another C string constant used much like `LINK_SPEC'. The
146: difference between the two is that `STARTFILE_SPEC' is used at the
147: very beginning of the command given to the linker.
148:
149: If this macro is not defined, a default is provided that loads the
150: standard C startup file from the usual place. See `gcc.c'.
151:
152: `ENDFILE_SPEC'
153: Another C string constant used much like `LINK_SPEC'. The
154: difference between the two is that `ENDFILE_SPEC' is used at the
155: very end of the command given to the linker.
156:
157: Do not define this macro if it does not need to do anything.
158:
159: `LINK_LIBGCC_SPECIAL'
160: Define this macro meaning that `gcc' should find the library
161: `libgcc.a' by hand, rather than passing the argument `-lgcc' to
162: tell the linker to do the search; also, `gcc' should not generate
163: `-L' options to pass to the linker (as it normally does).
164:
165: `LINK_LIBGCC_SPECIAL_1'
166: Define this macro meaning that `gcc' should find the library
167: `libgcc.a' by hand, rather than passing the argument `-lgcc' to
168: tell the linker to do the search.
169:
170: `RELATIVE_PREFIX_NOT_LINKDIR'
171: Define this macro to tell `gcc' that it should only translate a
172: `-B' prefix into a `-L' linker option if the prefix indicates an
173: absolute file name.
174:
175: `STANDARD_EXEC_PREFIX'
176: Define this macro as a C string constant if you wish to override
177: the standard choice of `/usr/local/lib/gcc-lib/' as the default
178: prefix to try when searching for the executable files of the
179: compiler.
180:
181: `MD_EXEC_PREFIX'
182: If defined, this macro is an additional prefix to try after
183: `STANDARD_EXEC_PREFIX'. `MD_EXEC_PREFIX' is not searched when the
184: `-b' option is used, or the compiler is built as a cross compiler.
185:
186: `STANDARD_STARTFILE_PREFIX'
187: Define this macro as a C string constant if you wish to override
188: the standard choice of `/usr/local/lib/' as the default prefix to
189: try when searching for startup files such as `crt0.o'.
190:
191: `MD_STARTFILE_PREFIX'
192: If defined, this macro supplies an additional prefix to try after
193: the standard prefixes. `MD_EXEC_PREFIX' is not searched when the
194: `-b' option is used, or when the compiler is built as a cross
195: compiler.
196:
197: `MD_STARTFILE_PREFIX_1'
198: If defined, this macro supplies yet another prefix to try after the
199: standard prefixes. It is not searched when the `-b' option is
200: used, or when the compiler is built as a cross compiler.
201:
202: `LOCAL_INCLUDE_DIR'
203: Define this macro as a C string constant if you wish to override
204: the standard choice of `/usr/local/include' as the default prefix
205: to try when searching for local header files. `LOCAL_INCLUDE_DIR'
206: comes before `SYSTEM_INCLUDE_DIR' in the search order.
207:
208: Cross compilers do not use this macro and do not search either
209: `/usr/local/include' or its replacement.
210:
211: `SYSTEM_INCLUDE_DIR'
212: Define this macro as a C string constant if you wish to specify a
213: system-specific directory to search for header files before the
214: standard directory. `SYSTEM_INCLUDE_DIR' comes before
215: `STANDARD_INCLUDE_DIR' in the search order.
216:
217: Cross compilers do not use this macro and do not search the
218: directory specified.
219:
220: `STANDARD_INCLUDE_DIR'
221: Define this macro as a C string constant if you wish to override
222: the standard choice of `/usr/include' as the default prefix to try
223: when searching for header files.
224:
225: Cross compilers do not use this macro and do not search either
226: `/usr/include' or its replacement.
227:
228: `INCLUDE_DEFAULTS'
229: Define this macro if you wish to override the entire default
230: search path for include files. The default search path includes
231: `GCC_INCLUDE_DIR', `LOCAL_INCLUDE_DIR', `SYSTEM_INCLUDE_DIR',
232: `GPLUSPLUS_INCLUDE_DIR', and `STANDARD_INCLUDE_DIR'. In addition,
233: `GPLUSPLUS_INCLUDE_DIR' and `GCC_INCLUDE_DIR' are defined
234: automatically by `Makefile', and specify private search areas for
235: GCC. The directory `GPLUSPLUS_INCLUDE_DIR' is used only for C++
236: programs.
237:
238: The definition should be an initializer for an array of structures.
239: Each array element should have two elements: the directory name (a
240: string constant) and a flag for C++-only directories. Mark the
241: end of the array with a null element. For example, here is the
242: definition used for VMS:
243:
244: #define INCLUDE_DEFAULTS \
245: { \
246: { "GNU_GXX_INCLUDE:", 1}, \
247: { "GNU_CC_INCLUDE:", 0}, \
248: { "SYS$SYSROOT:[SYSLIB.]", 0}, \
249: { ".", 0}, \
250: { 0, 0} \
251: }
252:
253: Here is the order of prefixes tried for exec files:
254:
255: 1. Any prefixes specified by the user with `-B'.
256:
257: 2. The environment variable `GCC_EXEC_PREFIX', if any.
258:
259: 3. The directories specified by the environment variable
260: `COMPILER_PATH'.
261:
262: 4. The macro `STANDARD_EXEC_PREFIX'.
263:
264: 5. `/usr/lib/gcc/'.
265:
266: 6. The macro `MD_EXEC_PREFIX', if any.
267:
268: Here is the order of prefixes tried for startfiles:
269:
270: 1. Any prefixes specified by the user with `-B'.
271:
272: 2. The environment variable `GCC_EXEC_PREFIX', if any.
273:
274: 3. The directories specified by the environment variable
275: `LIBRARY_PATH'.
276:
277: 4. The macro `STANDARD_EXEC_PREFIX'.
278:
279: 5. `/usr/lib/gcc/'.
280:
281: 6. The macro `MD_EXEC_PREFIX', if any.
282:
283: 7. The macro `MD_STARTFILE_PREFIX', if any.
284:
285: 8. The macro `STANDARD_STARTFILE_PREFIX'.
286:
287: 9. `/lib/'.
288:
289: 10. `/usr/lib/'.
290:
291:
292: File: gcc.info, Node: Run-time Target, Next: Storage Layout, Prev: Driver, Up: Target Macros
293:
294: Run-time Target Specification
295: =============================
296:
297: `CPP_PREDEFINES'
298: Define this to be a string constant containing `-D' options to
299: define the predefined macros that identify this machine and system.
300: These macros will be predefined unless the `-ansi' option is
301: specified.
302:
303: In addition, a parallel set of macros are predefined, whose names
304: are made by appending `__' at the beginning and at the end. These
305: `__' macros are permitted by the ANSI standard, so they are
306: predefined regardless of whether `-ansi' is specified.
307:
308: For example, on the Sun, one can use the following value:
309:
310: "-Dmc68000 -Dsun -Dunix"
311:
312: The result is to define the macros `__mc68000__', `__sun__' and
313: `__unix__' unconditionally, and the macros `mc68000', `sun' and
314: `unix' provided `-ansi' is not specified.
315:
316: `STDC_VALUE'
317: Define the value to be assigned to the built-in macro `__STDC__'.
318: The default is the value `1'.
319:
320: `extern int target_flags;'
321: This declaration should be present.
322:
323: `TARGET_...'
324: This series of macros is to allow compiler command arguments to
325: enable or disable the use of optional features of the target
326: machine. For example, one machine description serves both the
327: 68000 and the 68020; a command argument tells the compiler whether
328: it should use 68020-only instructions or not. This command
329: argument works by means of a macro `TARGET_68020' that tests a bit
330: in `target_flags'.
331:
332: Define a macro `TARGET_FEATURENAME' for each such option. Its
333: definition should test a bit in `target_flags'; for example:
334:
335: #define TARGET_68020 (target_flags & 1)
336:
337: One place where these macros are used is in the
338: condition-expressions of instruction patterns. Note how
339: `TARGET_68020' appears frequently in the 68000 machine description
340: file, `m68k.md'. Another place they are used is in the
341: definitions of the other macros in the `MACHINE.h' file.
342:
343: `TARGET_SWITCHES'
344: This macro defines names of command options to set and clear bits
345: in `target_flags'. Its definition is an initializer with a
346: subgrouping for each command option.
347:
348: Each subgrouping contains a string constant, that defines the
349: option name, and a number, which contains the bits to set in
350: `target_flags'. A negative number says to clear bits instead; the
351: negative of the number is which bits to clear. The actual option
352: name is made by appending `-m' to the specified name.
353:
354: One of the subgroupings should have a null string. The number in
355: this grouping is the default value for `target_flags'. Any target
356: options act starting with that value.
357:
358: Here is an example which defines `-m68000' and `-m68020' with
359: opposite meanings, and picks the latter as the default:
360:
361: #define TARGET_SWITCHES \
362: { { "68020", 1}, \
363: { "68000", -1}, \
364: { "", 1}}
365:
366: `TARGET_OPTIONS'
367: This macro is similar to `TARGET_SWITCHES' but defines names of
368: command options that have values. Its definition is an
369: initializer with a subgrouping for each command option.
370:
371: Each subgrouping contains a string constant, that defines the
372: fixed part of the option name, and the address of a variable. The
373: variable, type `char *', is set to the variable part of the given
374: option if the fixed part matches. The actual option name is made
375: by appending `-m' to the specified name.
376:
377: Here is an example which defines `-mshort-data-NUMBER'. If the
378: given option is `-mshort-data-512', the variable `m88k_short_data'
379: will be set to the string `"512"'.
380:
381: extern char *m88k_short_data;
382: #define TARGET_OPTIONS \
383: { { "short-data-", &m88k_short_data } }
384:
385: `TARGET_VERSION'
386: This macro is a C statement to print on `stderr' a string
387: describing the particular machine description choice. Every
388: machine description should define `TARGET_VERSION'. For example:
389:
390: #ifdef MOTOROLA
391: #define TARGET_VERSION \
392: fprintf (stderr, " (68k, Motorola syntax)");
393: #else
394: #define TARGET_VERSION \
395: fprintf (stderr, " (68k, MIT syntax)");
396: #endif
397:
398: `OVERRIDE_OPTIONS'
399: Sometimes certain combinations of command options do not make
400: sense on a particular target machine. You can define a macro
401: `OVERRIDE_OPTIONS' to take account of this. This macro, if
402: defined, is executed once just after all the command options have
403: been parsed.
404:
405: Don't use this macro to turn on various extra optimizations for
406: `-O'. That is what `OPTIMIZATION_OPTIONS' is for.
407:
408: `OPTIMIZATION_OPTIONS (LEVEL)'
409: Some machines may desire to change what optimizations are
410: performed for various optimization levels. This macro, if
411: defined, is executed once just after the optimization level is
412: determined and before the remainder of the command options have
413: been parsed. Values set in this macro are used as the default
414: values for the other command line options.
415:
416: LEVEL is the optimization level specified; 2 if -O2 is specified,
417: 1 if -O is specified, and 0 if neither is specified.
418:
419: *Do not examine `write_symbols' in this macro!* The debugging
420: options are not supposed to alter the generated code.
421:
422:
423: File: gcc.info, Node: Storage Layout, Next: Type Layout, Prev: Run-time Target, Up: Target Macros
424:
425: Storage Layout
426: ==============
427:
428: Note that the definitions of the macros in this table which are
429: sizes or alignments measured in bits do not need to be constant. They
430: can be C expressions that refer to static variables, such as the
431: `target_flags'. *Note Run-time Target::.
432:
433: `BITS_BIG_ENDIAN'
434: Define this macro to be the value 1 if the most significant bit in
435: a byte has the lowest number; otherwise define it to be the value
436: zero. This means that bit-field instructions count from the most
437: significant bit. If the machine has no bit-field instructions,
438: then this must still be defined, but it doesn't matter which value
439: it is defined to.
440:
441: This macro does not affect the way structure fields are packed into
442: bytes or words; that is controlled by `BYTES_BIG_ENDIAN'.
443:
444: `BYTES_BIG_ENDIAN'
445: Define this macro to be 1 if the most significant byte in a word
446: has the lowest number.
447:
448: `WORDS_BIG_ENDIAN'
449: Define this macro to be 1 if, in a multiword object, the most
450: significant word has the lowest number. This applies to both
451: memory locations and registers; GNU CC fundamentally assumes that
452: the order of words in memory is the same as the order in registers.
453:
454: `FLOAT_WORDS_BIG_ENDIAN'
455: Define this macro to be 1 if `DFmode', `XFmode' or `TFmode'
456: floating point numbers are stored in memory with the word
457: containing the sign bit at the lowest address; otherwise define it
458: to be 0.
459:
460: You need not define this macro if the ordering is the same as for
461: multi-word integers.
462:
463: `BITS_PER_UNIT'
464: Define this macro to be the number of bits in an addressable
465: storage unit (byte); normally 8.
466:
467: `BITS_PER_WORD'
468: Number of bits in a word; normally 32.
469:
470: `MAX_BITS_PER_WORD'
471: Maximum number of bits in a word. If this is undefined, the
472: default is `BITS_PER_WORD'. Otherwise, it is the constant value
473: that is the largest value that `BITS_PER_WORD' can have at
474: run-time.
475:
476: `UNITS_PER_WORD'
477: Number of storage units in a word; normally 4.
478:
479: `MAX_UNITS_PER_WORD'
480: Maximum number of units in a word. If this is undefined, the
481: default is `UNITS_PER_WORD'. Otherwise, it is the constant value
482: that is the largest value that `UNITS_PER_WORD' can have at
483: run-time.
484:
485: `POINTER_SIZE'
486: Width of a pointer, in bits.
487:
488: `PROMOTE_MODE (M, UNSIGNEDP, TYPE)'
489: A macro to update M and UNSIGNEDP when an object whose type is
490: TYPE and which has the specified mode and signedness is to be
491: stored in a register. This macro is only called when TYPE is a
492: scalar type.
493:
494: On most RISC machines, which only have operations that operate on
495: a full register, define this macro to set M to `word_mode' if M is
496: an integer mode narrower than `BITS_PER_WORD'. In most cases,
497: only integer modes should be widened because wider-precision
498: floating-point operations are usually more expensive than their
499: narrower counterparts.
500:
501: For most machines, the macro definition does not change UNSIGNEDP.
502: However, some machines, have instructions that preferentially
503: handle either signed or unsigned quantities of certain modes. For
504: example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
505: instructions sign-extend the result to 64 bits. On such machines,
506: set UNSIGNEDP according to which kind of extension is more
507: efficient.
508:
509: Do not define this macro if it would never modify M.
510:
511: `PROMOTE_FUNCTION_ARGS'
512: Define this macro if the promotion described by `PROMOTE_MODE'
513: should also be done for outgoing function arguments.
514:
515: `PROMOTE_FUNCTION_RETURN'
516: Define this macro if the promotion described by `PROMOTE_MODE'
517: should also be done for the return value of functions.
518:
519: If this macro is defined, `FUNCTION_VALUE' must perform the same
520: promotions done by `PROMOTE_MODE'.
521:
522: `PARM_BOUNDARY'
523: Normal alignment required for function parameters on the stack, in
524: bits. All stack parameters receive at least this much alignment
525: regardless of data type. On most machines, this is the same as the
526: size of an integer.
527:
528: `STACK_BOUNDARY'
529: Define this macro if you wish to preserve a certain alignment for
530: the stack pointer. The definition is a C expression for the
531: desired alignment (measured in bits).
532:
533: If `PUSH_ROUNDING' is not defined, the stack will always be aligned
534: to the specified boundary. If `PUSH_ROUNDING' is defined and
535: specifies a less strict alignment than `STACK_BOUNDARY', the stack
536: may be momentarily unaligned while pushing arguments.
537:
538: `FUNCTION_BOUNDARY'
539: Alignment required for a function entry point, in bits.
540:
541: `BIGGEST_ALIGNMENT'
542: Biggest alignment that any data type can require on this machine,
543: in bits.
544:
545: `BIGGEST_FIELD_ALIGNMENT'
546: Biggest alignment that any structure field can require on this
547: machine, in bits. If defined, this overrides `BIGGEST_ALIGNMENT'
548: for structure fields only.
549:
550: `MAX_OFILE_ALIGNMENT'
551: Biggest alignment supported by the object file format of this
552: machine. Use this macro to limit the alignment which can be
553: specified using the `__attribute__ ((aligned (N)))' construct. If
554: not defined, the default value is `BIGGEST_ALIGNMENT'.
555:
556: `DATA_ALIGNMENT (TYPE, BASIC-ALIGN)'
557: If defined, a C expression to compute the alignment for a static
558: variable. TYPE is the data type, and BASIC-ALIGN is the alignment
559: that the object would ordinarily have. The value of this macro is
560: used instead of that alignment to align the object.
561:
562: If this macro is not defined, then BASIC-ALIGN is used.
563:
564: One use of this macro is to increase alignment of medium-size data
565: to make it all fit in fewer cache lines. Another is to cause
566: character arrays to be word-aligned so that `strcpy' calls that
567: copy constants to character arrays can be done inline.
568:
569: `CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)'
570: If defined, a C expression to compute the alignment given to a
571: constant that is being placed in memory. CONSTANT is the constant
572: and BASIC-ALIGN is the alignment that the object would ordinarily
573: have. The value of this macro is used instead of that alignment to
574: align the object.
575:
576: If this macro is not defined, then BASIC-ALIGN is used.
577:
578: The typical use of this macro is to increase alignment for string
579: constants to be word aligned so that `strcpy' calls that copy
580: constants can be done inline.
581:
582: `EMPTY_FIELD_BOUNDARY'
583: Alignment in bits to be given to a structure bit field that
584: follows an empty field such as `int : 0;'.
585:
586: Note that `PCC_BITFIELD_TYPE_MATTERS' also affects the alignment
587: that results from an empty field.
588:
589: `STRUCTURE_SIZE_BOUNDARY'
590: Number of bits which any structure or union's size must be a
591: multiple of. Each structure or union's size is rounded up to a
592: multiple of this.
593:
594: If you do not define this macro, the default is the same as
595: `BITS_PER_UNIT'.
596:
597: `STRICT_ALIGNMENT'
598: Define this macro to be the value 1 if instructions will fail to
599: work if given data not on the nominal alignment. If instructions
600: will merely go slower in that case, define this macro as 0.
601:
602: `PCC_BITFIELD_TYPE_MATTERS'
603: Define this if you wish to imitate the way many other C compilers
604: handle alignment of bitfields and the structures that contain them.
605:
606: The behavior is that the type written for a bitfield (`int',
607: `short', or other integer type) imposes an alignment for the
608: entire structure, as if the structure really did contain an
609: ordinary field of that type. In addition, the bitfield is placed
610: within the structure so that it would fit within such a field, not
611: crossing a boundary for it.
612:
613: Thus, on most machines, a bitfield whose type is written as `int'
614: would not cross a four-byte boundary, and would force four-byte
615: alignment for the whole structure. (The alignment used may not be
616: four bytes; it is controlled by the other alignment parameters.)
617:
618: If the macro is defined, its definition should be a C expression;
619: a nonzero value for the expression enables this behavior.
620:
621: Note that if this macro is not defined, or its value is zero, some
622: bitfields may cross more than one alignment boundary. The
623: compiler can support such references if there are `insv', `extv',
624: and `extzv' insns that can directly reference memory.
625:
626: The other known way of making bitfields work is to define
627: `STRUCTURE_SIZE_BOUNDARY' as large as `BIGGEST_ALIGNMENT'. Then
628: every structure can be accessed with fullwords.
629:
630: Unless the machine has bitfield instructions or you define
631: `STRUCTURE_SIZE_BOUNDARY' that way, you must define
632: `PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
633:
634: If your aim is to make GNU CC use the same conventions for laying
635: out bitfields as are used by another compiler, here is how to
636: investigate what the other compiler does. Compile and run this
637: program:
638:
639: struct foo1
640: {
641: char x;
642: char :0;
643: char y;
644: };
645:
646: struct foo2
647: {
648: char x;
649: int :0;
650: char y;
651: };
652:
653: main ()
654: {
655: printf ("Size of foo1 is %d\n",
656: sizeof (struct foo1));
657: printf ("Size of foo2 is %d\n",
658: sizeof (struct foo2));
659: exit (0);
660: }
661:
662: If this prints 2 and 5, then the compiler's behavior is what you
663: would get from `PCC_BITFIELD_TYPE_MATTERS'.
664:
665: `BITFIELD_NBYTES_LIMITED'
666: Like PCC_BITFIELD_TYPE_MATTERS except that its effect is limited to
667: aligning a bitfield within the structure.
668:
669: `ROUND_TYPE_SIZE (STRUCT, SIZE, ALIGN)'
670: Define this macro as an expression for the overall size of a
671: structure (given by STRUCT as a tree node) when the size computed
672: from the fields is SIZE and the alignment is ALIGN.
673:
674: The default is to round SIZE up to a multiple of ALIGN.
675:
676: `ROUND_TYPE_ALIGN (STRUCT, COMPUTED, SPECIFIED)'
677: Define this macro as an expression for the alignment of a structure
678: (given by STRUCT as a tree node) if the alignment computed in the
679: usual way is COMPUTED and the alignment explicitly specified was
680: SPECIFIED.
681:
682: The default is to use SPECIFIED if it is larger; otherwise, use
683: the smaller of COMPUTED and `BIGGEST_ALIGNMENT'
684:
685: `MAX_FIXED_MODE_SIZE'
686: An integer expression for the size in bits of the largest integer
687: machine mode that should actually be used. All integer machine
688: modes of this size or smaller can be used for structures and
689: unions with the appropriate sizes. If this macro is undefined,
690: `GET_MODE_BITSIZE (DImode)' is assumed.
691:
692: `CHECK_FLOAT_VALUE (MODE, VALUE)'
693: A C statement to validate the value VALUE (of type `double') for
694: mode MODE. This means that you check whether VALUE fits within
695: the possible range of values for mode MODE on this target machine.
696: The mode MODE is always `SFmode' or `DFmode'.
697:
698: If VALUE is not valid, you should call `error' to print an error
699: message and then assign some valid value to VALUE. Allowing an
700: invalid value to go through the compiler can produce incorrect
701: assembler code which may even cause Unix assemblers to crash.
702:
703: This macro need not be defined if there is no work for it to do.
704:
705: `TARGET_FLOAT_FORMAT'
706: A code distinguishing the floating point format of the target
707: machine. There are three defined values:
708:
709: `IEEE_FLOAT_FORMAT'
710: This code indicates IEEE floating point. It is the default;
711: there is no need to define this macro when the format is IEEE.
712:
713: `VAX_FLOAT_FORMAT'
714: This code indicates the peculiar format used on the Vax.
715:
716: `UNKNOWN_FLOAT_FORMAT'
717: This code indicates any other format.
718:
719: The value of this macro is compared with `HOST_FLOAT_FORMAT'
720: (*note Config::.) to determine whether the target machine has the
721: same format as the host machine. If any other formats are
722: actually in use on supported machines, new codes should be defined
723: for them.
724:
725: The ordering of the component words of floating point values
726: stored in memory is controlled by `FLOAT_WORDS_BIG_ENDIAN' for the
727: target machine and `HOST_FLOAT_WORDS_BIG_ENDIAN' for the host.
728:
729:
730: File: gcc.info, Node: Type Layout, Next: Registers, Prev: Storage Layout, Up: Target Macros
731:
732: Layout of Source Language Data Types
733: ====================================
734:
735: These macros define the sizes and other characteristics of the
736: standard basic data types used in programs being compiled. Unlike the
737: macros in the previous section, these apply to specific features of C
738: and related languages, rather than to fundamental aspects of storage
739: layout.
740:
741: `INT_TYPE_SIZE'
742: A C expression for the size in bits of the type `int' on the
743: target machine. If you don't define this, the default is one word.
744:
745: `MAX_INT_TYPE_SIZE'
746: Maximum number for the size in bits of the type `int' on the target
747: machine. If this is undefined, the default is `INT_TYPE_SIZE'.
748: Otherwise, it is the constant value that is the largest value that
749: `INT_TYPE_SIZE' can have at run-time. This is used in `cpp'.
750:
751: `SHORT_TYPE_SIZE'
752: A C expression for the size in bits of the type `short' on the
753: target machine. If you don't define this, the default is half a
754: word. (If this would be less than one storage unit, it is rounded
755: up to one unit.)
756:
757: `LONG_TYPE_SIZE'
758: A C expression for the size in bits of the type `long' on the
759: target machine. If you don't define this, the default is one word.
760:
761: `MAX_LONG_TYPE_SIZE'
762: Maximum number for the size in bits of the type `long' on the
763: target machine. If this is undefined, the default is
764: `LONG_TYPE_SIZE'. Otherwise, it is the constant value that is the
765: largest value that `LONG_TYPE_SIZE' can have at run-time. This is
766: used in `cpp'.
767:
768: `LONG_LONG_TYPE_SIZE'
769: A C expression for the size in bits of the type `long long' on the
770: target machine. If you don't define this, the default is two
771: words.
772:
773: `CHAR_TYPE_SIZE'
774: A C expression for the size in bits of the type `char' on the
775: target machine. If you don't define this, the default is one
776: quarter of a word. (If this would be less than one storage unit,
777: it is rounded up to one unit.)
778:
779: `MAX_CHAR_TYPE_SIZE'
780: Maximum number for the size in bits of the type `char' on the
781: target machine. If this is undefined, the default is
782: `CHAR_TYPE_SIZE'. Otherwise, it is the constant value that is the
783: largest value that `CHAR_TYPE_SIZE' can have at run-time. This is
784: used in `cpp'.
785:
786: `FLOAT_TYPE_SIZE'
787: A C expression for the size in bits of the type `float' on the
788: target machine. If you don't define this, the default is one word.
789:
790: `DOUBLE_TYPE_SIZE'
791: A C expression for the size in bits of the type `double' on the
792: target machine. If you don't define this, the default is two
793: words.
794:
795: `LONG_DOUBLE_TYPE_SIZE'
796: A C expression for the size in bits of the type `long double' on
797: the target machine. If you don't define this, the default is two
798: words.
799:
800: `DEFAULT_SIGNED_CHAR'
801: An expression whose value is 1 or 0, according to whether the type
802: `char' should be signed or unsigned by default. The user can
803: always override this default with the options `-fsigned-char' and
804: `-funsigned-char'.
805:
806: `DEFAULT_SHORT_ENUMS'
807: A C expression to determine whether to give an `enum' type only as
808: many bytes as it takes to represent the range of possible values
809: of that type. A nonzero value means to do that; a zero value
810: means all `enum' types should be allocated like `int'.
811:
812: If you don't define the macro, the default is 0.
813:
814: `SIZE_TYPE'
815: A C expression for a string describing the name of the data type
816: to use for size values. The typedef name `size_t' is defined
817: using the contents of the string.
818:
819: The string can contain more than one keyword. If so, separate
820: them with spaces, and write first any length keyword, then
821: `unsigned' if appropriate, and finally `int'. The string must
822: exactly match one of the data type names defined in the function
823: `init_decl_processing' in the file `c-decl.c'. You may not omit
824: `int' or change the order--that would cause the compiler to crash
825: on startup.
826:
827: If you don't define this macro, the default is `"long unsigned
828: int"'.
829:
830: `PTRDIFF_TYPE'
831: A C expression for a string describing the name of the data type
832: to use for the result of subtracting two pointers. The typedef
833: name `ptrdiff_t' is defined using the contents of the string. See
834: `SIZE_TYPE' above for more information.
835:
836: If you don't define this macro, the default is `"long int"'.
837:
838: `WCHAR_TYPE'
839: A C expression for a string describing the name of the data type
840: to use for wide characters. The typedef name `wchar_t' is defined
841: using the contents of the string. See `SIZE_TYPE' above for more
842: information.
843:
844: If you don't define this macro, the default is `"int"'.
845:
846: `WCHAR_TYPE_SIZE'
847: A C expression for the size in bits of the data type for wide
848: characters. This is used in `cpp', which cannot make use of
849: `WCHAR_TYPE'.
850:
851: `MAX_WCHAR_TYPE_SIZE'
852: Maximum number for the size in bits of the data type for wide
853: characters. If this is undefined, the default is
854: `WCHAR_TYPE_SIZE'. Otherwise, it is the constant value that is the
855: largest value that `WCHAR_TYPE_SIZE' can have at run-time. This is
856: used in `cpp'.
857:
858: `OBJC_INT_SELECTORS'
859: Define this macro if the type of Objective C selectors should be
860: `int'.
861:
862: If this macro is not defined, then selectors should have the type
863: `struct objc_selector *'.
864:
865: `OBJC_SELECTORS_WITHOUT_LABELS'
866: Define this macro if the compiler can group all the selectors
867: together into a vector and use just one label at the beginning of
868: the vector. Otherwise, the compiler must give each selector its
869: own assembler label.
870:
871: On certain machines, it is important to have a separate label for
872: each selector because this enables the linker to eliminate
873: duplicate selectors.
874:
875: `TARGET_BELL'
876: A C constant expression for the integer value for escape sequence
877: `\a'.
878:
879: `TARGET_BS'
880: `TARGET_TAB'
881: `TARGET_NEWLINE'
882: C constant expressions for the integer values for escape sequences
883: `\b', `\t' and `\n'.
884:
885: `TARGET_VT'
886: `TARGET_FF'
887: `TARGET_CR'
888: C constant expressions for the integer values for escape sequences
889: `\v', `\f' and `\r'.
890:
891:
892: File: gcc.info, Node: Registers, Next: Register Classes, Prev: Type Layout, Up: Target Macros
893:
894: Register Usage
895: ==============
896:
897: This section explains how to describe what registers the target
898: machine has, and how (in general) they can be used.
899:
900: The description of which registers a specific instruction can use is
901: done with register classes; see *Note Register Classes::. For
902: information on using registers to access a stack frame, see *Note Frame
903: Registers::. For passing values in registers, see *Note Register
904: Arguments::. For returning values in registers, see *Note Scalar
905: Return::.
906:
907: * Menu:
908:
909: * Register Basics:: Number and kinds of registers.
910: * Allocation Order:: Order in which registers are allocated.
911: * Values in Registers:: What kinds of values each reg can hold.
912: * Leaf Functions:: Renumbering registers for leaf functions.
913: * Stack Registers:: Handling a register stack such as 80387.
914: * Obsolete Register Macros:: Macros formerly used for the 80387.
915:
916:
917: File: gcc.info, Node: Register Basics, Next: Allocation Order, Up: Registers
918:
919: Basic Characteristics of Registers
920: ----------------------------------
921:
922: `FIRST_PSEUDO_REGISTER'
923: Number of hardware registers known to the compiler. They receive
924: numbers 0 through `FIRST_PSEUDO_REGISTER-1'; thus, the first
925: pseudo register's number really is assigned the number
926: `FIRST_PSEUDO_REGISTER'.
927:
928: `FIXED_REGISTERS'
929: An initializer that says which registers are used for fixed
930: purposes all throughout the compiled code and are therefore not
931: available for general allocation. These would include the stack
932: pointer, the frame pointer (except on machines where that can be
933: used as a general register when no frame pointer is needed), the
934: program counter on machines where that is considered one of the
935: addressable registers, and any other numbered register with a
936: standard use.
937:
938: This information is expressed as a sequence of numbers, separated
939: by commas and surrounded by braces. The Nth number is 1 if
940: register N is fixed, 0 otherwise.
941:
942: The table initialized from this macro, and the table initialized by
943: the following one, may be overridden at run time either
944: automatically, by the actions of the macro
945: `CONDITIONAL_REGISTER_USAGE', or by the user with the command
946: options `-ffixed-REG', `-fcall-used-REG' and `-fcall-saved-REG'.
947:
948: `CALL_USED_REGISTERS'
949: Like `FIXED_REGISTERS' but has 1 for each register that is
950: clobbered (in general) by function calls as well as for fixed
951: registers. This macro therefore identifies the registers that are
952: not available for general allocation of values that must live
953: across function calls.
954:
955: If a register has 0 in `CALL_USED_REGISTERS', the compiler
956: automatically saves it on function entry and restores it on
957: function exit, if the register is used within the function.
958:
959: `CONDITIONAL_REGISTER_USAGE'
960: Zero or more C statements that may conditionally modify two
961: variables `fixed_regs' and `call_used_regs' (both of type `char
962: []') after they have been initialized from the two preceding
963: macros.
964:
965: This is necessary in case the fixed or call-clobbered registers
966: depend on target flags.
967:
968: You need not define this macro if it has no work to do.
969:
970: If the usage of an entire class of registers depends on the target
971: flags, you may indicate this to GCC by using this macro to modify
972: `fixed_regs' and `call_used_regs' to 1 for each of the registers
973: in the classes which should not be used by GCC. Also define the
974: macro `REG_CLASS_FROM_LETTER' to return `NO_REGS' if it is called
975: with a letter for a class that shouldn't be used.
976:
977: (However, if this class is not included in `GENERAL_REGS' and all
978: of the insn patterns whose constraints permit this class are
979: controlled by target switches, then GCC will automatically avoid
980: using these registers when the target switches are opposed to
981: them.)
982:
983: `NON_SAVING_SETJMP'
984: If this macro is defined and has a nonzero value, it means that
985: `setjmp' and related functions fail to save the registers, or that
986: `longjmp' fails to restore them. To compensate, the compiler
987: avoids putting variables in registers in functions that use
988: `setjmp'.
989:
990: `INCOMING_REGNO (OUT)'
991: Define this macro if the target machine has register windows.
992: This C expression returns the register number as seen by the
993: called function corresponding to the register number OUT as seen
994: by the calling function. Return OUT if register number OUT is not
995: an outbound register.
996:
997: `OUTGOING_REGNO (IN)'
998: Define this macro if the target machine has register windows.
999: This C expression returns the register number as seen by the
1000: calling function corresponding to the register number IN as seen
1001: by the called function. Return IN if register number IN is not an
1002: inbound register.
1003:
1004:
1005: File: gcc.info, Node: Allocation Order, Next: Values in Registers, Prev: Register Basics, Up: Registers
1006:
1007: Order of Allocation of Registers
1008: --------------------------------
1009:
1010: `REG_ALLOC_ORDER'
1011: If defined, an initializer for a vector of integers, containing the
1012: numbers of hard registers in the order in which GNU CC should
1013: prefer to use them (from most preferred to least).
1014:
1015: If this macro is not defined, registers are used lowest numbered
1016: first (all else being equal).
1017:
1018: One use of this macro is on machines where the highest numbered
1019: registers must always be saved and the save-multiple-registers
1020: instruction supports only sequences of consecutive registers. On
1021: such machines, define `REG_ALLOC_ORDER' to be an initializer that
1022: lists the highest numbered allocatable register first.
1023:
1024: `ORDER_REGS_FOR_LOCAL_ALLOC'
1025: A C statement (sans semicolon) to choose the order in which to
1026: allocate hard registers for pseudo-registers local to a basic
1027: block.
1028:
1029: Store the desired register order in the array `reg_alloc_order'.
1030: Element 0 should be the register to allocate first; element 1, the
1031: next register; and so on.
1032:
1033: The macro body should not assume anything about the contents of
1034: `reg_alloc_order' before execution of the macro.
1035:
1036: On most machines, it is not necessary to define this macro.
1037:
1038:
1039: File: gcc.info, Node: Values in Registers, Next: Leaf Functions, Prev: Allocation Order, Up: Registers
1040:
1041: How Values Fit in Registers
1042: ---------------------------
1043:
1044: This section discusses the macros that describe which kinds of values
1045: (specifically, which machine modes) each register can hold, and how many
1046: consecutive registers are needed for a given mode.
1047:
1048: `HARD_REGNO_NREGS (REGNO, MODE)'
1049: A C expression for the number of consecutive hard registers,
1050: starting at register number REGNO, required to hold a value of mode
1051: MODE.
1052:
1053: On a machine where all registers are exactly one word, a suitable
1054: definition of this macro is
1055:
1056: #define HARD_REGNO_NREGS(REGNO, MODE) \
1057: ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
1058: / UNITS_PER_WORD))
1059:
1060: `HARD_REGNO_MODE_OK (REGNO, MODE)'
1061: A C expression that is nonzero if it is permissible to store a
1062: value of mode MODE in hard register number REGNO (or in several
1063: registers starting with that one). For a machine where all
1064: registers are equivalent, a suitable definition is
1065:
1066: #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
1067:
1068: It is not necessary for this macro to check for the numbers of
1069: fixed registers, because the allocation mechanism considers them
1070: to be always occupied.
1071:
1072: On some machines, double-precision values must be kept in even/odd
1073: register pairs. The way to implement that is to define this macro
1074: to reject odd register numbers for such modes.
1075:
1076: The minimum requirement for a mode to be OK in a register is that
1077: the `movMODE' instruction pattern support moves between the
1078: register and any other hard register for which the mode is OK; and
1079: that moving a value into the register and back out not alter it.
1080:
1081: Since the same instruction used to move `SImode' will work for all
1082: narrower integer modes, it is not necessary on any machine for
1083: `HARD_REGNO_MODE_OK' to distinguish between these modes, provided
1084: you define patterns `movhi', etc., to take advantage of this. This
1085: is useful because of the interaction between `HARD_REGNO_MODE_OK'
1086: and `MODES_TIEABLE_P'; it is very desirable for all integer modes
1087: to be tieable.
1088:
1089: Many machines have special registers for floating point arithmetic.
1090: Often people assume that floating point machine modes are allowed
1091: only in floating point registers. This is not true. Any
1092: registers that can hold integers can safely *hold* a floating
1093: point machine mode, whether or not floating arithmetic can be done
1094: on it in those registers. Integer move instructions can be used
1095: to move the values.
1096:
1097: On some machines, though, the converse is true: fixed-point machine
1098: modes may not go in floating registers. This is true if the
1099: floating registers normalize any value stored in them, because
1100: storing a non-floating value there would garble it. In this case,
1101: `HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
1102: floating registers. But if the floating registers do not
1103: automatically normalize, if you can store any bit pattern in one
1104: and retrieve it unchanged without a trap, then any machine mode
1105: may go in a floating register, so you can define this macro to say
1106: so.
1107:
1108: On some machines, such as the Sparc and the Mips, we get better
1109: code by defining `HARD_REGNO_MODE_OK' to forbid integers in
1110: floating registers, even though the hardware is capable of
1111: handling them. This is because transferring values between
1112: floating registers and general registers is so slow that it is
1113: better to keep the integer in memory.
1114:
1115: The primary significance of special floating registers is rather
1116: that they are the registers acceptable in floating point arithmetic
1117: instructions. However, this is of no concern to
1118: `HARD_REGNO_MODE_OK'. You handle it by writing the proper
1119: constraints for those instructions.
1120:
1121: On some machines, the floating registers are especially slow to
1122: access, so that it is better to store a value in a stack frame
1123: than in such a register if floating point arithmetic is not being
1124: done. As long as the floating registers are not in class
1125: `GENERAL_REGS', they will not be used unless some pattern's
1126: constraint asks for one.
1127:
1128: `MODES_TIEABLE_P (MODE1, MODE2)'
1129: A C expression that is nonzero if it is desirable to choose
1130: register allocation so as to avoid move instructions between a
1131: value of mode MODE1 and a value of mode MODE2.
1132:
1133: If `HARD_REGNO_MODE_OK (R, MODE1)' and `HARD_REGNO_MODE_OK (R,
1134: MODE2)' are ever different for any R, then `MODES_TIEABLE_P (MODE1,
1135: MODE2)' must be zero.
1136:
1137:
1138: File: gcc.info, Node: Leaf Functions, Next: Stack Registers, Prev: Values in Registers, Up: Registers
1139:
1140: Handling Leaf Functions
1141: -----------------------
1142:
1143: On some machines, a leaf function (i.e., one which makes no calls)
1144: can run more efficiently if it does not make its own register window.
1145: Often this means it is required to receive its arguments in the
1146: registers where they are passed by the caller, instead of the registers
1147: where they would normally arrive.
1148:
1149: The special treatment for leaf functions generally applies only when
1150: other conditions are met; for example, often they may use only those
1151: registers for its own variables and temporaries. We use the term "leaf
1152: function" to mean a function that is suitable for this special
1153: handling, so that functions with no calls are not necessarily "leaf
1154: functions".
1155:
1156: GNU CC assigns register numbers before it knows whether the function
1157: is suitable for leaf function treatment. So it needs to renumber the
1158: registers in order to output a leaf function. The following macros
1159: accomplish this.
1160:
1161: `LEAF_REGISTERS'
1162: A C initializer for a vector, indexed by hard register number,
1163: which contains 1 for a register that is allowable in a candidate
1164: for leaf function treatment.
1165:
1166: If leaf function treatment involves renumbering the registers,
1167: then the registers marked here should be the ones before
1168: renumbering--those that GNU CC would ordinarily allocate. The
1169: registers which will actually be used in the assembler code, after
1170: renumbering, should not be marked with 1 in this vector.
1171:
1172: Define this macro only if the target machine offers a way to
1173: optimize the treatment of leaf functions.
1174:
1175: `LEAF_REG_REMAP (REGNO)'
1176: A C expression whose value is the register number to which REGNO
1177: should be renumbered, when a function is treated as a leaf
1178: function.
1179:
1180: If REGNO is a register number which should not appear in a leaf
1181: function before renumbering, then the expression should yield -1,
1182: which will cause the compiler to abort.
1183:
1184: Define this macro only if the target machine offers a way to
1185: optimize the treatment of leaf functions, and registers need to be
1186: renumbered to do this.
1187:
1188: `REG_LEAF_ALLOC_ORDER'
1189: If defined, an initializer for a vector of integers, containing the
1190: numbers of hard registers in the order in which the GNU CC should
1191: prefer to use them (from most preferred to least) in a leaf
1192: function. If this macro is not defined, REG_ALLOC_ORDER is used
1193: for both non-leaf and leaf-functions.
1194:
1195: Normally, `FUNCTION_PROLOGUE' and `FUNCTION_EPILOGUE' must treat
1196: leaf functions specially. It can test the C variable `leaf_function'
1197: which is nonzero for leaf functions. (The variable `leaf_function' is
1198: defined only if `LEAF_REGISTERS' is defined.)
1199:
1200:
1201: File: gcc.info, Node: Stack Registers, Next: Obsolete Register Macros, Prev: Leaf Functions, Up: Registers
1202:
1203: Registers That Form a Stack
1204: ---------------------------
1205:
1206: There are special features to handle computers where some of the
1207: "registers" form a stack, as in the 80387 coprocessor for the 80386.
1208: Stack registers are normally written by pushing onto the stack, and are
1209: numbered relative to the top of the stack.
1210:
1211: Currently, GNU CC can only handle one group of stack-like registers,
1212: and they must be consecutively numbered.
1213:
1214: `STACK_REGS'
1215: Define this if the machine has any stack-like registers.
1216:
1217: `FIRST_STACK_REG'
1218: The number of the first stack-like register. This one is the top
1219: of the stack.
1220:
1221: `LAST_STACK_REG'
1222: The number of the last stack-like register. This one is the
1223: bottom of the stack.
1224:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.