|
|
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: Instruction Output, Next: Dispatch Tables, Prev: Macros for Initialization, Up: Assembler Format
32:
33: Output of Assembler Instructions
34: --------------------------------
35:
36: `REGISTER_NAMES'
37: A C initializer containing the assembler's names for the machine
38: registers, each one as a C string constant. This is what
39: translates register numbers in the compiler into assembler
40: language.
41:
42: `ADDITIONAL_REGISTER_NAMES'
43: If defined, a C initializer for an array of structures containing
44: a name and a register number. This macro defines additional names
45: for hard registers, thus allowing the `asm' option in declarations
46: to refer to registers using alternate names.
47:
48: `ASM_OUTPUT_OPCODE (STREAM, PTR)'
49: Define this macro if you are using an unusual assembler that
50: requires different names for the machine instructions.
51:
52: The definition is a C statement or statements which output an
53: assembler instruction opcode to the stdio stream STREAM. The
54: macro-operand PTR is a variable of type `char *' which points to
55: the opcode name in its "internal" form--the form that is written
56: in the machine description. The definition should output the
57: opcode name to STREAM, performing any translation you desire, and
58: increment the variable PTR to point at the end of the opcode so
59: that it will not be output twice.
60:
61: In fact, your macro definition may process less than the entire
62: opcode name, or more than the opcode name; but if you want to
63: process text that includes `%'-sequences to substitute operands,
64: you must take care of the substitution yourself. Just be sure to
65: increment PTR over whatever text should not be output normally.
66:
67: If you need to look at the operand values, they can be found as the
68: elements of `recog_operand'.
69:
70: If the macro definition does nothing, the instruction is output in
71: the usual way.
72:
73: `FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)'
74: If defined, a C statement to be executed just prior to the output
75: of assembler code for INSN, to modify the extracted operands so
76: they will be output differently.
77:
78: Here the argument OPVEC is the vector containing the operands
79: extracted from INSN, and NOPERANDS is the number of elements of
80: the vector which contain meaningful data for this insn. The
81: contents of this vector are what will be used to convert the insn
82: template into assembler code, so you can change the assembler
83: output by changing the contents of the vector.
84:
85: This macro is useful when various assembler syntaxes share a single
86: file of instruction patterns; by defining this macro differently,
87: you can cause a large class of instructions to be output
88: differently (such as with rearranged operands). Naturally,
89: variations in assembler syntax affecting individual insn patterns
90: ought to be handled by writing conditional output routines in
91: those patterns.
92:
93: If this macro is not defined, it is equivalent to a null statement.
94:
95: `PRINT_OPERAND (STREAM, X, CODE)'
96: A C compound statement to output to stdio stream STREAM the
97: assembler syntax for an instruction operand X. X is an RTL
98: expression.
99:
100: CODE is a value that can be used to specify one of several ways of
101: printing the operand. It is used when identical operands must be
102: printed differently depending on the context. CODE comes from the
103: `%' specification that was used to request printing of the
104: operand. If the specification was just `%DIGIT' then CODE is 0;
105: if the specification was `%LTR DIGIT' then CODE is the ASCII code
106: for LTR.
107:
108: If X is a register, this macro should print the register's name.
109: The names can be found in an array `reg_names' whose type is `char
110: *[]'. `reg_names' is initialized from `REGISTER_NAMES'.
111:
112: When the machine description has a specification `%PUNCT' (a `%'
113: followed by a punctuation character), this macro is called with a
114: null pointer for X and the punctuation character for CODE.
115:
116: `PRINT_OPERAND_PUNCT_VALID_P (CODE)'
117: A C expression which evaluates to true if CODE is a valid
118: punctuation character for use in the `PRINT_OPERAND' macro. If
119: `PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
120: punctuation characters (except for the standard one, `%') are used
121: in this way.
122:
123: `PRINT_OPERAND_ADDRESS (STREAM, X)'
124: A C compound statement to output to stdio stream STREAM the
125: assembler syntax for an instruction operand that is a memory
126: reference whose address is X. X is an RTL expression.
127:
128: On some machines, the syntax for a symbolic address depends on the
129: section that the address refers to. On these machines, define the
130: macro `ENCODE_SECTION_INFO' to store the information into the
131: `symbol_ref', and then check for it here. *Note Assembler
132: Format::.
133:
134: `DBR_OUTPUT_SEQEND(FILE)'
135: A C statement, to be executed after all slot-filler instructions
136: have been output. If necessary, call `dbr_sequence_length' to
137: determine the number of slots filled in a sequence (zero if not
138: currently outputting a sequence), to decide how many no-ops to
139: output, or whatever.
140:
141: Don't define this macro if it has nothing to do, but it is helpful
142: in reading assembly output if the extent of the delay sequence is
143: made explicit (e.g. with white space).
144:
145: Note that output routines for instructions with delay slots must be
146: prepared to deal with not being output as part of a sequence (i.e.
147: when the scheduling pass is not run, or when no slot fillers could
148: be found.) The variable `final_sequence' is null when not
149: processing a sequence, otherwise it contains the `sequence' rtx
150: being output.
151:
152: `REGISTER_PREFIX'
153: `LOCAL_LABEL_PREFIX'
154: `USER_LABEL_PREFIX'
155: `IMMEDIATE_PREFIX'
156: If defined, C string expressions to be used for the `%R', `%L',
157: `%U', and `%I' options of `asm_fprintf' (see `final.c'). These
158: are useful when a single `md' file must support multiple assembler
159: formats. In that case, the various `tm.h' files can define these
160: macros differently.
161:
162: `ASM_OUTPUT_REG_PUSH (STREAM, REGNO)'
163: A C expression to output to STREAM some assembler code which will
164: push hard register number REGNO onto the stack. The code need not
165: be optimal, since this macro is used only when profiling.
166:
167: `ASM_OUTPUT_REG_POP (STREAM, REGNO)'
168: A C expression to output to STREAM some assembler code which will
169: pop hard register number REGNO off of the stack. The code need
170: not be optimal, since this macro is used only when profiling.
171:
172:
173: File: gcc.info, Node: Dispatch Tables, Next: Alignment Output, Prev: Instruction Output, Up: Assembler Format
174:
175: Output of Dispatch Tables
176: -------------------------
177:
178: `ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, VALUE, REL)'
179: This macro should be provided on machines where the addresses in a
180: dispatch table are relative to the table's own address.
181:
182: The definition should be a C statement to output to the stdio
183: stream STREAM an assembler pseudo-instruction to generate a
184: difference between two labels. VALUE and REL are the numbers of
185: two internal labels. The definitions of these labels are output
186: using `ASM_OUTPUT_INTERNAL_LABEL', and they must be printed in the
187: same way here. For example,
188:
189: fprintf (STREAM, "\t.word L%d-L%d\n",
190: VALUE, REL)
191:
192: `ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)'
193: This macro should be provided on machines where the addresses in a
194: dispatch table are absolute.
195:
196: The definition should be a C statement to output to the stdio
197: stream STREAM an assembler pseudo-instruction to generate a
198: reference to a label. VALUE is the number of an internal label
199: whose definition is output using `ASM_OUTPUT_INTERNAL_LABEL'. For
200: example,
201:
202: fprintf (STREAM, "\t.word L%d\n", VALUE)
203:
204: `ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)'
205: Define this if the label before a jump-table needs to be output
206: specially. The first three arguments are the same as for
207: `ASM_OUTPUT_INTERNAL_LABEL'; the fourth argument is the jump-table
208: which follows (a `jump_insn' containing an `addr_vec' or
209: `addr_diff_vec').
210:
211: This feature is used on system V to output a `swbeg' statement for
212: the table.
213:
214: If this macro is not defined, these labels are output with
215: `ASM_OUTPUT_INTERNAL_LABEL'.
216:
217: `ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)'
218: Define this if something special must be output at the end of a
219: jump-table. The definition should be a C statement to be executed
220: after the assembler code for the table is written. It should write
221: the appropriate code to stdio stream STREAM. The argument TABLE
222: is the jump-table insn, and NUM is the label-number of the
223: preceding label.
224:
225: If this macro is not defined, nothing special is output at the end
226: of the jump-table.
227:
228:
229: File: gcc.info, Node: Alignment Output, Prev: Dispatch Tables, Up: Assembler Format
230:
231: Assembler Commands for Alignment
232: --------------------------------
233:
234: `ASM_OUTPUT_ALIGN_CODE (FILE)'
235: A C expression to output text to align the location counter in the
236: way that is desirable at a point in the code that is reached only
237: by jumping.
238:
239: This macro need not be defined if you don't want any special
240: alignment to be done at such a time. Most machine descriptions do
241: not currently define the macro.
242:
243: `ASM_OUTPUT_LOOP_ALIGN (FILE)'
244: A C expression to output text to align the location counter in the
245: way that is desirable at the beginning of a loop.
246:
247: This macro need not be defined if you don't want any special
248: alignment to be done at such a time. Most machine descriptions do
249: not currently define the macro.
250:
251: `ASM_OUTPUT_SKIP (STREAM, NBYTES)'
252: A C statement to output to the stdio stream STREAM an assembler
253: instruction to advance the location counter by NBYTES bytes.
254: Those bytes should be zero when loaded. NBYTES will be a C
255: expression of type `int'.
256:
257: `ASM_NO_SKIP_IN_TEXT'
258: Define this macro if `ASM_OUTPUT_SKIP' should not be used in the
259: text section because it fails put zeros in the bytes that are
260: skipped. This is true on many Unix systems, where the pseudo-op
261: to skip bytes produces no-op instructions rather than zeros when
262: used in the text section.
263:
264: `ASM_OUTPUT_ALIGN (STREAM, POWER)'
265: A C statement to output to the stdio stream STREAM an assembler
266: command to advance the location counter to a multiple of 2 to the
267: POWER bytes. POWER will be a C expression of type `int'.
268:
269:
270: File: gcc.info, Node: Debugging Info, Next: Cross-compilation, Prev: Assembler Format, Up: Target Macros
271:
272: Controlling Debugging Information Format
273: ========================================
274:
275: * Menu:
276:
277: * All Debuggers:: Macros that affect all debugging formats uniformly.
278: * DBX Options:: Macros enabling specific options in DBX format.
279: * DBX Hooks:: Hook macros for varying DBX format.
280: * File Names and DBX:: Macros controlling output of file names in DBX format.
281: * SDB and DWARF:: Macros for SDB (COFF) and DWARF formats.
282:
283:
284: File: gcc.info, Node: All Debuggers, Next: DBX Options, Up: Debugging Info
285:
286: Macros Affecting All Debugging Formats
287: --------------------------------------
288:
289: `DBX_REGISTER_NUMBER (REGNO)'
290: A C expression that returns the DBX register number for the
291: compiler register number REGNO. In simple cases, the value of this
292: expression may be REGNO itself. But sometimes there are some
293: registers that the compiler knows about and DBX does not, or vice
294: versa. In such cases, some register may need to have one number in
295: the compiler and another for DBX.
296:
297: If two registers have consecutive numbers inside GNU CC, and they
298: can be used as a pair to hold a multiword value, then they *must*
299: have consecutive numbers after renumbering with
300: `DBX_REGISTER_NUMBER'. Otherwise, debuggers will be unable to
301: access such a pair, because they expect register pairs to be
302: consecutive in their own numbering scheme.
303:
304: If you find yourself defining `DBX_REGISTER_NUMBER' in way that
305: does not preserve register pairs, then what you must do instead is
306: redefine the actual register numbering scheme.
307:
308: `DEBUGGER_AUTO_OFFSET (X)'
309: A C expression that returns the integer offset value for an
310: automatic variable having address X (an RTL expression). The
311: default computation assumes that X is based on the frame-pointer
312: and gives the offset from the frame-pointer. This is required for
313: targets that produce debugging output for DBX or COFF-style
314: debugging output for SDB and allow the frame-pointer to be
315: eliminated when the `-g' options is used.
316:
317: `DEBUGGER_ARG_OFFSET (OFFSET, X)'
318: A C expression that returns the integer offset value for an
319: argument having address X (an RTL expression). The nominal offset
320: is OFFSET.
321:
322:
323: File: gcc.info, Node: DBX Options, Next: DBX Hooks, Prev: All Debuggers, Up: Debugging Info
324:
325: Specific Options for DBX Output
326: -------------------------------
327:
328: `DBX_DEBUGGING_INFO'
329: Define this macro if GNU CC should produce debugging output for DBX
330: in response to the `-g' option.
331:
332: `XCOFF_DEBUGGING_INFO'
333: Define this macro if GNU CC should produce XCOFF format debugging
334: output in response to the `-g' option. This is a variant of DBX
335: format.
336:
337: `DEFAULT_GDB_EXTENSIONS'
338: Define this macro to control whether GNU CC should by default
339: generate GDB's extended version of DBX debugging information
340: (assuming DBX-format debugging information is enabled at all). If
341: you don't define the macro, the default is 1: always generate the
342: extended information if there is any occasion to.
343:
344: `DEBUG_SYMS_TEXT'
345: Define this macro if all `.stabs' commands should be output while
346: in the text section.
347:
348: `ASM_STABS_OP'
349: A C string constant naming the assembler pseudo op to use instead
350: of `.stabs' to define an ordinary debugging symbol. If you don't
351: define this macro, `.stabs' is used. This macro applies only to
352: DBX debugging information format.
353:
354: `ASM_STABD_OP'
355: A C string constant naming the assembler pseudo op to use instead
356: of `.stabd' to define a debugging symbol whose value is the current
357: location. If you don't define this macro, `.stabd' is used. This
358: macro applies only to DBX debugging information format.
359:
360: `ASM_STABN_OP'
361: A C string constant naming the assembler pseudo op to use instead
362: of `.stabn' to define a debugging symbol with no name. If you
363: don't define this macro, `.stabn' is used. This macro applies
364: only to DBX debugging information format.
365:
366: `DBX_NO_XREFS'
367: Define this macro if DBX on your system does not support the
368: construct `xsTAGNAME'. On some systems, this construct is used to
369: describe a forward reference to a structure named TAGNAME. On
370: other systems, this construct is not supported at all.
371:
372: `DBX_CONTIN_LENGTH'
373: A symbol name in DBX-format debugging information is normally
374: continued (split into two separate `.stabs' directives) when it
375: exceeds a certain length (by default, 80 characters). On some
376: operating systems, DBX requires this splitting; on others,
377: splitting must not be done. You can inhibit splitting by defining
378: this macro with the value zero. You can override the default
379: splitting-length by defining this macro as an expression for the
380: length you desire.
381:
382: `DBX_CONTIN_CHAR'
383: Normally continuation is indicated by adding a `\' character to
384: the end of a `.stabs' string when a continuation follows. To use
385: a different character instead, define this macro as a character
386: constant for the character you want to use. Do not define this
387: macro if backslash is correct for your system.
388:
389: `DBX_STATIC_STAB_DATA_SECTION'
390: Define this macro if it is necessary to go to the data section
391: before outputting the `.stabs' pseudo-op for a non-global static
392: variable.
393:
394: `DBX_TYPE_DECL_STABS_CODE'
395: The value to use in the "code" field of the `.stabs' directive for
396: a typedef. The default is `N_LSYM'.
397:
398: `DBX_STATIC_CONST_VAR_CODE'
399: The value to use in the "code" field of the `.stabs' directive for
400: a static variable located in the text section. DBX format does not
401: provide any "right" way to do this. The default is `N_FUN'.
402:
403: `DBX_REGPARM_STABS_CODE'
404: The value to use in the "code" field of the `.stabs' directive for
405: a parameter passed in registers. DBX format does not provide any
406: "right" way to do this. The default is `N_RSYM'.
407:
408: `DBX_REGPARM_STABS_LETTER'
409: The letter to use in DBX symbol data to identify a symbol as a
410: parameter passed in registers. DBX format does not customarily
411: provide any way to do this. The default is `'P''.
412:
413: `DBX_MEMPARM_STABS_LETTER'
414: The letter to use in DBX symbol data to identify a symbol as a
415: stack parameter. The default is `'p''.
416:
417: `DBX_FUNCTION_FIRST'
418: Define this macro if the DBX information for a function and its
419: arguments should precede the assembler code for the function.
420: Normally, in DBX format, the debugging information entirely
421: follows the assembler code.
422:
423: `DBX_LBRAC_FIRST'
424: Define this macro if the `N_LBRAC' symbol for a block should
425: precede the debugging information for variables and functions
426: defined in that block. Normally, in DBX format, the `N_LBRAC'
427: symbol comes first.
428:
429:
430: File: gcc.info, Node: DBX Hooks, Next: File Names and DBX, Prev: DBX Options, Up: Debugging Info
431:
432: Open-Ended Hooks for DBX Format
433: -------------------------------
434:
435: `DBX_OUTPUT_LBRAC (STREAM, NAME)'
436: Define this macro to say how to output to STREAM the debugging
437: information for the start of a scope level for variable names. The
438: argument NAME is the name of an assembler symbol (for use with
439: `assemble_name') whose value is the address where the scope begins.
440:
441: `DBX_OUTPUT_RBRAC (STREAM, NAME)'
442: Like `DBX_OUTPUT_LBRAC', but for the end of a scope level.
443:
444: `DBX_OUTPUT_ENUM (STREAM, TYPE)'
445: Define this macro if the target machine requires special handling
446: to output an enumeration type. The definition should be a C
447: statement (sans semicolon) to output the appropriate information
448: to STREAM for the type TYPE.
449:
450: `DBX_OUTPUT_FUNCTION_END (STREAM, FUNCTION)'
451: Define this macro if the target machine requires special output at
452: the end of the debugging information for a function. The
453: definition should be a C statement (sans semicolon) to output the
454: appropriate information to STREAM. FUNCTION is the
455: `FUNCTION_DECL' node for the function.
456:
457: `DBX_OUTPUT_STANDARD_TYPES (SYMS)'
458: Define this macro if you need to control the order of output of the
459: standard data types at the beginning of compilation. The argument
460: SYMS is a `tree' which is a chain of all the predefined global
461: symbols, including names of data types.
462:
463: Normally, DBX output starts with definitions of the types for
464: integers and characters, followed by all the other predefined
465: types of the particular language in no particular order.
466:
467: On some machines, it is necessary to output different particular
468: types first. To do this, define `DBX_OUTPUT_STANDARD_TYPES' to
469: output those symbols in the necessary order. Any predefined types
470: that you don't explicitly output will be output afterward in no
471: particular order.
472:
473: Be careful not to define this macro so that it works only for C.
474: There are no global variables to access most of the built-in
475: types, because another language may have another set of types.
476: The way to output a particular type is to look through SYMS to see
477: if you can find it. Here is an example:
478:
479: {
480: tree decl;
481: for (decl = syms; decl; decl = TREE_CHAIN (decl))
482: if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)),
483: "long int"))
484: dbxout_symbol (decl);
485: ...
486: }
487:
488: This does nothing if the expected type does not exist.
489:
490: See the function `init_decl_processing' in `c-decl.c' to find the
491: names to use for all the built-in C types.
492:
493: Here is another way of finding a particular type:
494:
495: {
496: tree decl;
497: for (decl = syms; decl; decl = TREE_CHAIN (decl))
498: if (TREE_CODE (decl) == TYPE_DECL
499: && (TREE_CODE (TREE_TYPE (decl))
500: == INTEGER_CST)
501: && TYPE_PRECISION (TREE_TYPE (decl)) == 16
502: && TYPE_UNSIGNED (TREE_TYPE (decl)))
503: /* This must be `unsigned short'. */
504: dbxout_symbol (decl);
505: ...
506: }
507:
508:
509: File: gcc.info, Node: File Names and DBX, Next: SDB and DWARF, Prev: DBX Hooks, Up: Debugging Info
510:
511: File Names in DBX Format
512: ------------------------
513:
514: `DBX_WORKING_DIRECTORY'
515: Define this if DBX wants to have the current directory recorded in
516: each object file.
517:
518: Note that the working directory is always recorded if GDB
519: extensions are enabled.
520:
521: `DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)'
522: A C statement to output DBX debugging information to the stdio
523: stream STREAM which indicates that file NAME is the main source
524: file--the file specified as the input file for compilation. This
525: macro is called only once, at the beginning of compilation.
526:
527: This macro need not be defined if the standard form of output for
528: DBX debugging information is appropriate.
529:
530: `DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (STREAM, NAME)'
531: A C statement to output DBX debugging information to the stdio
532: stream STREAM which indicates that the current directory during
533: compilation is named NAME.
534:
535: This macro need not be defined if the standard form of output for
536: DBX debugging information is appropriate.
537:
538: `DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)'
539: A C statement to output DBX debugging information at the end of
540: compilation of the main source file NAME.
541:
542: If you don't define this macro, nothing special is output at the
543: end of compilation, which is correct for most machines.
544:
545: `DBX_OUTPUT_SOURCE_FILENAME (STREAM, NAME)'
546: A C statement to output DBX debugging information to the stdio
547: stream STREAM which indicates that file NAME is the current source
548: file. This output is generated each time input shifts to a
549: different source file as a result of `#include', the end of an
550: included file, or a `#line' command.
551:
552: This macro need not be defined if the standard form of output for
553: DBX debugging information is appropriate.
554:
555:
556: File: gcc.info, Node: SDB and DWARF, Prev: File Names and DBX, Up: Debugging Info
557:
558: Macros for SDB and DWARF Output
559: -------------------------------
560:
561: `SDB_DEBUGGING_INFO'
562: Define this macro if GNU CC should produce COFF-style debugging
563: output for SDB in response to the `-g' option.
564:
565: `DWARF_DEBUGGING_INFO'
566: Define this macro if GNU CC should produce dwarf format debugging
567: output in response to the `-g' option.
568:
569: `PUT_SDB_...'
570: Define these macros to override the assembler syntax for the
571: special SDB assembler directives. See `sdbout.c' for a list of
572: these macros and their arguments. If the standard syntax is used,
573: you need not define them yourself.
574:
575: `SDB_DELIM'
576: Some assemblers do not support a semicolon as a delimiter, even
577: between SDB assembler directives. In that case, define this macro
578: to be the delimiter to use (usually `\n'). It is not necessary to
579: define a new set of `PUT_SDB_OP' macros if this is the only change
580: required.
581:
582: `SDB_GENERATE_FAKE'
583: Define this macro to override the usual method of constructing a
584: dummy name for anonymous structure and union types. See
585: `sdbout.c' for more information.
586:
587: `SDB_ALLOW_UNKNOWN_REFERENCES'
588: Define this macro to allow references to unknown structure, union,
589: or enumeration tags to be emitted. Standard COFF does not allow
590: handling of unknown references, MIPS ECOFF has support for it.
591:
592: `SDB_ALLOW_FORWARD_REFERENCES'
593: Define this macro to allow references to structure, union, or
594: enumeration tags that have not yet been seen to be handled. Some
595: assemblers choke if forward tags are used, while some require it.
596:
597:
598: File: gcc.info, Node: Cross-compilation, Next: Misc, Prev: Debugging Info, Up: Target Macros
599:
600: Cross Compilation and Floating Point
601: ====================================
602:
603: While all modern machines use 2's complement representation for
604: integers, there are a variety of representations for floating point
605: numbers. This means that in a cross-compiler the representation of
606: floating point numbers in the compiled program may be different from
607: that used in the machine doing the compilation.
608:
609: Because different representation systems may offer different amounts
610: of range and precision, the cross compiler cannot safely use the host
611: machine's floating point arithmetic. Therefore, floating point
612: constants must be represented in the target machine's format. This
613: means that the cross compiler cannot use `atof' to parse a floating
614: point constant; it must have its own special routine to use instead.
615: Also, constant folding must emulate the target machine's arithmetic (or
616: must not be done at all).
617:
618: The macros in the following table should be defined only if you are
619: cross compiling between different floating point formats.
620:
621: Otherwise, don't define them. Then default definitions will be set
622: up which use `double' as the data type, `==' to test for equality, etc.
623:
624: You don't need to worry about how many times you use an operand of
625: any of these macros. The compiler never uses operands which have side
626: effects.
627:
628: `REAL_VALUE_TYPE'
629: A macro for the C data type to be used to hold a floating point
630: value in the target machine's format. Typically this would be a
631: `struct' containing an array of `int'.
632:
633: `REAL_VALUES_EQUAL (X, Y)'
634: A macro for a C expression which compares for equality the two
635: values, X and Y, both of type `REAL_VALUE_TYPE'.
636:
637: `REAL_VALUES_LESS (X, Y)'
638: A macro for a C expression which tests whether X is less than Y,
639: both values being of type `REAL_VALUE_TYPE' and interpreted as
640: floating point numbers in the target machine's representation.
641:
642: `REAL_VALUE_LDEXP (X, SCALE)'
643: A macro for a C expression which performs the standard library
644: function `ldexp', but using the target machine's floating point
645: representation. Both X and the value of the expression have type
646: `REAL_VALUE_TYPE'. The second argument, SCALE, is an integer.
647:
648: `REAL_VALUE_FIX (X)'
649: A macro whose definition is a C expression to convert the
650: target-machine floating point value X to a signed integer. X has
651: type `REAL_VALUE_TYPE'.
652:
653: `REAL_VALUE_UNSIGNED_FIX (X)'
654: A macro whose definition is a C expression to convert the
655: target-machine floating point value X to an unsigned integer. X
656: has type `REAL_VALUE_TYPE'.
657:
658: `REAL_VALUE_RNDZINT (X)'
659: A macro whose definition is a C expression to round the
660: target-machine floating point value X towards zero to an integer
661: value (but still as a floating point number). X has type
662: `REAL_VALUE_TYPE', and so does the value.
663:
664: `REAL_VALUE_UNSIGNED_RNDZINT (X)'
665: A macro whose definition is a C expression to round the
666: target-machine floating point value X towards zero to an unsigned
667: integer value (but still represented as a floating point number).
668: x has type `REAL_VALUE_TYPE', and so does the value.
669:
670: `REAL_VALUE_ATOF (STRING, MODE)'
671: A macro for a C expression which converts STRING, an expression of
672: type `char *', into a floating point number in the target machine's
673: representation for mode MODE. The value has type
674: `REAL_VALUE_TYPE'.
675:
676: `REAL_INFINITY'
677: Define this macro if infinity is a possible floating point value,
678: and therefore division by 0 is legitimate.
679:
680: `REAL_VALUE_ISINF (X)'
681: A macro for a C expression which determines whether X, a floating
682: point value, is infinity. The value has type `int'. By default,
683: this is defined to call `isinf'.
684:
685: `REAL_VALUE_ISNAN (X)'
686: A macro for a C expression which determines whether X, a floating
687: point value, is a "nan" (not-a-number). The value has type `int'.
688: By default, this is defined to call `isnan'.
689:
690: Define the following additional macros if you want to make floating
691: point constant folding work while cross compiling. If you don't define
692: them, cross compilation is still possible, but constant folding will
693: not happen for floating point values.
694:
695: `REAL_ARITHMETIC (OUTPUT, CODE, X, Y)'
696: A macro for a C statement which calculates an arithmetic operation
697: of the two floating point values X and Y, both of type
698: `REAL_VALUE_TYPE' in the target machine's representation, to
699: produce a result of the same type and representation which is
700: stored in OUTPUT (which will be a variable).
701:
702: The operation to be performed is specified by CODE, a tree code
703: which will always be one of the following: `PLUS_EXPR',
704: `MINUS_EXPR', `MULT_EXPR', `RDIV_EXPR', `MAX_EXPR', `MIN_EXPR'.
705:
706: The expansion of this macro is responsible for checking for
707: overflow. If overflow happens, the macro expansion should execute
708: the statement `return 0;', which indicates the inability to
709: perform the arithmetic operation requested.
710:
711: `REAL_VALUE_NEGATE (X)'
712: A macro for a C expression which returns the negative of the
713: floating point value X. Both X and the value of the expression
714: have type `REAL_VALUE_TYPE' and are in the target machine's
715: floating point representation.
716:
717: There is no way for this macro to report overflow, since overflow
718: can't happen in the negation operation.
719:
720: `REAL_VALUE_TRUNCATE (MODE, X)'
721: A macro for a C expression which converts the floating point value
722: X to mode MODE.
723:
724: Both X and the value of the expression are in the target machine's
725: floating point representation and have type `REAL_VALUE_TYPE'.
726: However, the value should have an appropriate bit pattern to be
727: output properly as a floating constant whose precision accords
728: with mode MODE.
729:
730: There is no way for this macro to report overflow.
731:
732: `REAL_VALUE_TO_INT (LOW, HIGH, X)'
733: A macro for a C expression which converts a floating point value X
734: into a double-precision integer which is then stored into LOW and
735: HIGH, two variables of type INT.
736:
737: `REAL_VALUE_FROM_INT (X, LOW, HIGH)'
738: A macro for a C expression which converts a double-precision
739: integer found in LOW and HIGH, two variables of type INT, into a
740: floating point value which is then stored into X.
741:
742:
743: File: gcc.info, Node: Misc, Prev: Cross-compilation, Up: Target Macros
744:
745: Miscellaneous Parameters
746: ========================
747:
748: `PREDICATE_CODES'
749: Define this if you have defined special-purpose predicates in the
750: file `MACHINE.c'. This macro is called within an initializer of an
751: array of structures. The first field in the structure is the name
752: of a predicate and the second field is an array of rtl codes. For
753: each predicate, list all rtl codes that can be in expressions
754: matched by the predicate. The list should have a trailing comma.
755: Here is an example of two entries in the list for a typical RISC
756: machine:
757:
758: #define PREDICATE_CODES \
759: {"gen_reg_rtx_operand", {SUBREG, REG}}, \
760: {"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}},
761:
762: Defining this macro does not affect the generated code (however,
763: incorrect definitions that omit an rtl code that may be matched by
764: the predicate can cause the compiler to malfunction). Instead, it
765: allows the table built by `genrecog' to be more compact and
766: efficient, thus speeding up the compiler. The most important
767: predicates to include in the list specified by this macro are
768: thoses used in the most insn patterns.
769:
770: `CASE_VECTOR_MODE'
771: An alias for a machine mode name. This is the machine mode that
772: elements of a jump-table should have.
773:
774: `CASE_VECTOR_PC_RELATIVE'
775: Define this macro if jump-tables should contain relative addresses.
776:
777: `CASE_DROPS_THROUGH'
778: Define this if control falls through a `case' insn when the index
779: value is out of range. This means the specified default-label is
780: actually ignored by the `case' insn proper.
781:
782: `CASE_VALUES_THRESHOLD'
783: Define this to be the smallest number of different values for
784: which it is best to use a jump-table instead of a tree of
785: conditional branches. The default is four for machines with a
786: `casesi' instruction and five otherwise. This is best for most
787: machines.
788:
789: `BYTE_LOADS_ZERO_EXTEND'
790: Define this macro if an instruction to load a value narrower than a
791: word from memory into a register also zero-extends the value to
792: the whole register.
793:
794: `BYTE_LOADS_SIGN_EXTEND'
795: Define this macro if an instruction to load a value narrower than a
796: word from memory into a register also sign-extends the value to
797: the whole register.
798:
799: `IMPLICIT_FIX_EXPR'
800: An alias for a tree code that should be used by default for
801: conversion of floating point values to fixed point. Normally,
802: `FIX_ROUND_EXPR' is used.
803:
804: `FIXUNS_TRUNC_LIKE_FIX_TRUNC'
805: Define this macro if the same instructions that convert a floating
806: point number to a signed fixed point number also convert validly
807: to an unsigned one.
808:
809: `EASY_DIV_EXPR'
810: An alias for a tree code that is the easiest kind of division to
811: compile code for in the general case. It may be `TRUNC_DIV_EXPR',
812: `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or `ROUND_DIV_EXPR'. These four
813: division operators differ in how they round the result to an
814: integer. `EASY_DIV_EXPR' is used when it is permissible to use
815: any of those kinds of division and the choice should be made on
816: the basis of efficiency.
817:
818: `MOVE_MAX'
819: The maximum number of bytes that a single instruction can move
820: quickly from memory to memory.
821:
822: `SHIFT_COUNT_TRUNCATED'
823: Defining this macro causes the compiler to omit a sign-extend,
824: zero-extend, or bitwise `and' instruction that truncates the count
825: of a shift operation to a width equal to the number of bits needed
826: to represent the size of the object being shifted. On machines
827: that have instructions that act on bitfields at variable
828: positions, which may include `bit test' instructions, defining
829: `SHIFT_COUNT_TRUNCATED' also enables deletion of truncations of
830: the values that serve as arguments to bitfield instructions.
831:
832: If both types of instructions truncate the count (for shifts) and
833: position (for bitfield operations), or if no variable-position
834: bitfield instructions exist, you should define this macro.
835:
836: However, on some machines, such as the 80386 and the 680x0,
837: truncation only applies to shift operations and not the (real or
838: pretended) bitfield operations. Do not define
839: `SHIFT_COUNT_TRUNCATED' on such machines. Instead, add patterns
840: to the `md' file that include the implied truncation of the shift
841: instructions.
842:
843: `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
844: A C expression which is nonzero if on this machine it is safe to
845: "convert" an integer of INPREC bits to one of OUTPREC bits (where
846: OUTPREC is smaller than INPREC) by merely operating on it as if it
847: had only OUTPREC bits.
848:
849: On many machines, this expression can be 1.
850:
851: When `TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
852: modes for which `MODES_TIEABLE_P' is 0, suboptimal code can result.
853: If this is the case, making `TRULY_NOOP_TRUNCATION' return 0 in
854: such cases may improve things.
855:
856: `STORE_FLAG_VALUE'
857: A C expression describing the value returned by a comparison
858: operator with an integral mode and stored by a store-flag
859: instruction (`sCOND') when the condition is true. This
860: description must apply to *all* the `sCOND' patterns and all the
861: comparison operators whose results have a `MODE_INT' mode.
862:
863: A value of 1 or -1 means that the instruction implementing the
864: comparison operator returns exactly 1 or -1 when the comparison is
865: true and 0 when the comparison is false. Otherwise, the value
866: indicates which bits of the result are guaranteed to be 1 when the
867: comparison is true. This value is interpreted in the mode of the
868: comparison operation, which is given by the mode of the first
869: operand in the `sCOND' pattern. Either the low bit or the sign
870: bit of `STORE_FLAG_VALUE' be on. Presently, only those bits are
871: used by the compiler.
872:
873: If `STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
874: generate code that depends only on the specified bits. It can also
875: replace comparison operators with equivalent operations if they
876: cause the required bits to be set, even if the remaining bits are
877: undefined. For example, on a machine whose comparison operators
878: return an `SImode' value and where `STORE_FLAG_VALUE' is defined as
879: `0x80000000', saying that just the sign bit is relevant, the
880: expression
881:
882: (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
883:
884: can be converted to
885:
886: (ashift:SI X (const_int N))
887:
888: where N is the appropriate shift count to move the bit being
889: tested into the sign bit.
890:
891: There is no way to describe a machine that always sets the
892: low-order bit for a true value, but does not guarantee the value
893: of any other bits, but we do not know of any machine that has such
894: an instruction. If you are trying to port GNU CC to such a
895: machine, include an instruction to perform a logical-and of the
896: result with 1 in the pattern for the comparison operators and let
897: us know (*note How to Report Bugs: Bug Reporting.).
898:
899: Often, a machine will have multiple instructions that obtain a
900: value from a comparison (or the condition codes). Here are rules
901: to guide the choice of value for `STORE_FLAG_VALUE', and hence the
902: instructions to be used:
903:
904: * Use the shortest sequence that yields a valid definition for
905: `STORE_FLAG_VALUE'. It is more efficient for the compiler to
906: "normalize" the value (convert it to, e.g., 1 or 0) than for
907: the comparison operators to do so because there may be
908: opportunities to combine the normalization with other
909: operations.
910:
911: * For equal-length sequences, use a value of 1 or -1, with -1
912: being slightly preferred on machines with expensive jumps and
913: 1 preferred on other machines.
914:
915: * As a second choice, choose a value of `0x80000001' if
916: instructions exist that set both the sign and low-order bits
917: but do not define the others.
918:
919: * Otherwise, use a value of `0x80000000'.
920:
921: Many machines can produce both the value chosen for
922: `STORE_FLAG_VALUE' and its negation in the same number of
923: instructions. On those machines, you should also define a pattern
924: for those cases, e.g., one matching
925:
926: (set A (neg:M (ne:M B C)))
927:
928: Some machines can also perform `and' or `plus' operations on
929: condition code values with less instructions than the corresponding
930: `sCOND' insn followed by `and' or `plus'. On those machines,
931: define the appropriate patterns. Use the names `incscc' and
932: `decscc', respectively, for the the patterns which perform `plus'
933: or `minus' operations on condition code values. See `rs6000.md'
934: for some examples. The GNU Superoptizer can be used to find such
935: instruction sequences on other machines.
936:
937: You need not define `STORE_FLAG_VALUE' if the machine has no
938: store-flag instructions.
939:
940: `FLOAT_STORE_FLAG_VALUE'
941: A C expression that gives a non-zero floating point value that is
942: returned when comparison operators with floating-point results are
943: true. Define this macro on machine that have comparison
944: operations that return floating-point values. If there are no
945: such operations, do not define this macro.
946:
947: `Pmode'
948: An alias for the machine mode for pointers. Normally the
949: definition can be
950:
951: #define Pmode SImode
952:
953: `FUNCTION_MODE'
954: An alias for the machine mode used for memory references to
955: functions being called, in `call' RTL expressions. On most
956: machines this should be `QImode'.
957:
958: `INTEGRATE_THRESHOLD (DECL)'
959: A C expression for the maximum number of instructions above which
960: the function DECL should not be inlined. DECL is a
961: `FUNCTION_DECL' node.
962:
963: The default definition of this macro is 64 plus 8 times the number
964: of arguments that the function accepts. Some people think a larger
965: threshold should be used on RISC machines.
966:
967: `SCCS_DIRECTIVE'
968: Define this if the preprocessor should ignore `#sccs' directives
969: and print no error message.
970:
971: `HANDLE_PRAGMA (STREAM)'
972: Define this macro if you want to implement any pragmas. If
973: defined, it should be a C statement to be executed when `#pragma'
974: is seen. The argument STREAM is the stdio input stream from which
975: the source text can be read.
976:
977: It is generally a bad idea to implement new uses of `#pragma'. The
978: only reason to define this macro is for compatibility with other
979: compilers that do support `#pragma' for the sake of any user
980: programs which already use it.
981:
982: `DOLLARS_IN_IDENTIFIERS'
983: Define this macro to control use of the character `$' in identifier
984: names. The value should be 0, 1, or 2. 0 means `$' is not allowed
985: by default; 1 means it is allowed by default if `-traditional' is
986: used; 2 means it is allowed by default provided `-ansi' is not
987: used. 1 is the default; there is no need to define this macro in
988: that case.
989:
990: `NO_DOLLAR_IN_LABEL'
991: Define this macro if the assembler does not accept the character
992: `$' in label names. By default constructors and destructors in
993: G++ have `$' in the identifiers. If this macro is defined, `.' is
994: used instead.
995:
996: `DEFAULT_MAIN_RETURN'
997: Define this macro if the target system expects every program's
998: `main' function to return a standard "success" value by default
999: (if no other value is explicitly returned).
1000:
1001: The definition should be a C statement (sans semicolon) to
1002: generate the appropriate rtl instructions. It is used only when
1003: compiling the end of `main'.
1004:
1005: `HAVE_ATEXIT'
1006: Define this if the target system supports the function `atexit'
1007: from the ANSI C standard. If this is not defined, and
1008: `INIT_SECTION_ASM_OP' is not defined, a default `exit' function
1009: will be provided to support C++.
1010:
1011: `EXIT_BODY'
1012: Define this if your `exit' function needs to do something besides
1013: calling an external function `_cleanup' before terminating with
1014: `_exit'. The `EXIT_BODY' macro is only needed if netiher
1015: `HAVE_ATEXIT' nor `INIT_SECTION_ASM_OP' are defined.
1016:
1017: `INSN_SETS_ARE_DELAYED (INSN)'
1018: Define this macro as a C expression that is nonzero if it is safe
1019: for the delay slot scheduler to place instructions in the delay
1020: slot of INSN, even if they appear to use a resource set or
1021: clobbered in INSN. INSN is always a `jump_insn' or an `insn'; GNU
1022: CC knows that every `call_insn' has this behavior. On machines
1023: where some `insn' or `jump_insn' is really a function call and
1024: hence has this behavior, you should define this macro.
1025:
1026: You need not define this macro if it would always return zero.
1027:
1028: `INSN_REFERENCES_ARE_DELAYED (INSN)'
1029: Define this macro as a C expression that is nonzero if it is safe
1030: for the delay slot scheduler to place instructions in the delay
1031: slot of INSN, even if they appear to set or clobber a resource
1032: referenced in INSN. INSN is always a `jump_insn' or an `insn'.
1033: On machines where some `insn' or `jump_insn' is really a function
1034: call and its operands are registers whose use is actually in the
1035: subroutine it calls, you should define this macro. Doing so
1036: allows the delay slot scheduler to move instructions which copy
1037: arguments into the argument registers into the delay slot of INSN.
1038:
1039: You need not define this macro if it would always return zero.
1040:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.