![[BACK]](/cvsweb/icons/back.gif){kind=icon}
Return to gcc.info-7 CVS log ![[TXT]](/cvsweb/icons/text.gif){kind=icon}
![[DIR]](/cvsweb/icons/dir.gif){kind=icon}
Up to [GCC 1.x] / gcc|
Return to gcc.info-7 CVS log | Up to [GCC 1.x] / gcc |
1.1 root 1: Info file gcc.info, produced by Makeinfo, -*- Text -*- from input
2: file gcc.texinfo.
3:
4: This file documents the use and the internals of the GNU compiler.
5:
6: Copyright (C) 1988 Free Software Foundation, Inc.
7:
8: Permission is granted to make and distribute verbatim copies of this
9: manual provided the copyright notice and this permission notice are
10: preserved on all copies.
11:
12: Permission is granted to copy and distribute modified versions of
13: this manual under the conditions for verbatim copying, provided also
14: that the section entitled ``GNU CC General Public License'' is
15: included exactly as in the original, and provided that the entire
16: resulting derived work is distributed under the terms of a permission
17: notice identical to this one.
18:
19: Permission is granted to copy and distribute translations of this
20: manual into another language, under the above conditions for modified
21: versions, except that the section entitled ``GNU CC General Public
22: License'' and this permission notice may be included in translations
23: approved by the Free Software Foundation instead of in the original
24: English.
25:
26:
27:
28: File: gcc.info, Node: Stack Layout, Next: Library Names, Prev: Register Classes, Up: Machine Macros
29:
30: Describing Stack Layout
31: =======================
32:
33: `STACK_GROWS_DOWNWARD'
34: Define this macro if pushing a word onto the stack moves the
35: stack pointer to a smaller address.
36:
37: When we say, ``define this macro if ...,'' it means that the
38: compiler checks this macro only with `#ifdef' so the precise
39: definition used does not matter.
40:
41: `FRAME_GROWS_DOWNWARD'
42: Define this macro if the addresses of local variable slots are
43: at negative offsets from the frame pointer.
44:
45: `STARTING_FRAME_OFFSET'
46: Offset from the frame pointer to the first local variable slot
47: to be allocated.
48:
49: If `FRAME_GROWS_DOWNWARD', the next slot's offset is found by
50: subtracting the length of the first slot from
51: `STARTING_FRAME_OFFSET'. Otherwise, it is found by adding the
52: length of the first slot to the value `STARTING_FRAME_OFFSET'.
53:
54: `PUSH_ROUNDING (NPUSHED)'
55: A C expression that is the number of bytes actually pushed onto
56: the stack when an instruction attempts to push NPUSHED bytes.
57:
58: If the target machine does not have a push instruction, do not
59: define this macro. That directs GNU CC to use an alternate
60: strategy: to allocate the entire argument block and then store
61: the arguments into it.
62:
63: On some machines, the definition
64:
65: #define PUSH_ROUNDING(BYTES) (BYTES)
66:
67: will suffice. But on other machines, instructions that appear
68: to push one byte actually push two bytes in an attempt to
69: maintain alignment. Then the definition should be
70:
71: #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
72:
73: `FIRST_PARM_OFFSET (FUNDECL)'
74: Offset from the argument pointer register to the first
75: argument's address. On some machines it may depend on the data
76: type of the function. (In the next version of GNU CC, the
77: argument will be changed to the function data type rather than
78: its declaration.)
79:
80: `FIRST_PARM_CALLER_OFFSET (FUNDECL)'
81: Define this macro on machines where register parameters have
82: shadow locations on the stack, at addresses below the nominal
83: parameter. This matters because certain arguments cannot be
84: passed on the stack. On these machines, such arguments must be
85: stored into the shadow locations.
86:
87: This macro should expand into a C expression whose value is the
88: offset of the first parameter's shadow location from the nominal
89: stack pointer value. (That value is itself computed by adding
90: the value of `STACK_POINTER_OFFSET' to the stack pointer
91: register.)
92:
93: `RETURN_POPS_ARGS (FUNTYPE)'
94: A C expression that should be 1 if a function pops its own
95: arguments on returning, or 0 if the function pops no arguments
96: and the caller must therefore pop them all after the function
97: returns.
98:
99: FUNTYPE is a C variable whose value is a tree node that
100: describes the function in question. Normally it is a node of
101: type `FUNCTION_TYPE' that describes the data type of the function.
102: From this it is possible to obtain the data types of the value
103: and arguments (if known).
104:
105: When a call to a library function is being considered, FUNTYPE
106: will contain an identifier node for the library function. Thus,
107: if you need to distinguish among various library functions, you
108: can do so by their names. Note that ``library function'' in
109: this context means a function used to perform arithmetic, whose
110: name is known specially in the compiler and was not mentioned in
111: the C code being compiled.
112:
113: On the Vax, all functions always pop their arguments, so the
114: definition of this macro is 1. On the 68000, using the standard
115: calling convention, no functions pop their arguments, so the
116: value of the macro is always 0 in this case. But an alternative
117: calling convention is available in which functions that take a
118: fixed number of arguments pop them but other functions (such as
119: `printf') pop nothing (the caller pops all). When this
120: convention is in use, FUNTYPE is examined to determine whether a
121: function takes a fixed number of arguments.
122:
123: `FUNCTION_VALUE (VALTYPE, FUNC)'
124: A C expression to create an RTX representing the place where a
125: function returns a value of data type VALTYPE. VALTYPE is a
126: tree node representing a data type. Write `TYPE_MODE (VALTYPE)'
127: to get the machine mode used to represent that type. On many
128: machines, only the mode is relevant. (Actually, on most
129: machines, scalar values are returned in the same place
130: regardless of mode).
131:
132: If the precise function being called is known, FUNC is a tree
133: node (`FUNCTION_DECL') for it; otherwise, FUNC is a null
134: pointer. This makes it possible to use a different
135: value-returning convention for specific functions when all their
136: calls are known.
137:
138: `FUNCTION_OUTGOING_VALUE (VALTYPE, FUNC)'
139: Define this macro if the target machine has ``register windows''
140: so that the register in which a function returns its value is
141: not the same as the one in which the caller sees the value.
142:
143: For such machines, `FUNCTION_VALUE' computes the register in
144: which the caller will see the value, and
145: `FUNCTION_OUTGOING_VALUE' should be defined in a similar fashion
146: to tell the function where to put the value.
147:
148: If `FUNCTION_OUTGOING_VALUE' is not defined, `FUNCTION_VALUE'
149: serves both purposes.
150:
151: `LIBCALL_VALUE (MODE)'
152: A C expression to create an RTX representing the place where a
153: library function returns a value of mode MODE. If the precise
154: function being called is known, FUNC is a tree node
155: (`FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.
156: This makes it possible to use a different value-returning
157: convention for specific functions when all their calls are known.
158:
159: Note that ``library function'' in this context means a compiler
160: support routine, used to perform arithmetic, whose name is known
161: specially by the compiler and was not mentioned in the C code
162: being compiled.
163:
164: `FUNCTION_VALUE_REGNO_P (REGNO)'
165: A C expression that is nonzero if REGNO is the number of a hard
166: register in which the values of called function may come back.
167:
168: A register whose use for returning values is limited to serving
169: as the second of a pair (for a value of type `double', say) need
170: not be recognized by this macro. So for most machines, this
171: definition suffices:
172:
173: #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
174:
175: If the machine has register windows, so that the caller and the
176: called function use different registers for the return value,
177: this macro should recognize only the caller's register numbers.
178:
179: `FUNCTION_ARG (CUM, MODE, TYPE, NAMED)'
180: A C expression that controls whether a function argument is
181: passed in a register, and which register.
182:
183: The arguments are CUM, which summarizes all the previous
184: arguments; MODE, the machine mode of the argument; TYPE, the
185: data type of the argument as a tree node or 0 if that is not
186: known (which happens for C support library functions); and
187: NAMED, which is 1 for an ordinary argument and 0 for nameless
188: arguments that correspond to `...' in the called function's
189: prototype.
190:
191: The value of the expression should either be a `reg' RTX for the
192: hard register in which to pass the argument, or zero to pass the
193: argument on the stack.
194:
195: For the Vax and 68000, where normally all arguments are pushed,
196: zero suffices as a definition.
197:
198: `FUNCTION_INCOMING_ARG (CUM, MODE, TYPE, NAMED)'
199: Define this macro if the target machine has ``register
200: windows'', so that the register in which a function sees an
201: arguments is not necessarily the same as the one in which the
202: caller passed the argument.
203:
204: For such machines, `FUNCTION_ARG' computes the register in which
205: the caller passes the value, and `FUNCTION_INCOMING_ARG' should
206: be defined in a similar fashion to tell the function being
207: called where the arguments will arrive.
208:
209: If `FUNCTION_INCOMING_ARG' is not defined, `FUNCTION_ARG' serves
210: both purposes.
211:
212: `FUNCTION_ARG_PARTIAL_NREGS (CUM, MODE, TYPE, NAMED)'
213: A C expression for the number of words, at the beginning of an
214: argument, must be put in registers. The value must be zero for
215: arguments that are passed entirely in registers or that are
216: entirely pushed on the stack.
217:
218: On some machines, certain arguments must be passed partially in
219: registers and partially in memory. On these machines, typically
220: the first N words of arguments are passed in registers, and the
221: rest on the stack. If a multi-word argument (a `double' or a
222: structure) crosses that boundary, its first few words must be
223: passed in registers and the rest must be pushed. This macro
224: tells the compiler when this occurs, and how many of the words
225: should go in registers.
226:
227: `FUNCTION_ARG' for these arguments should return the first
228: register to be used by the caller for this argument; likewise
229: `FUNCTION_INCOMING_ARG', for the called function.
230:
231: `CUMULATIVE_ARGS'
232: A C type for declaring a variable that is used as the first
233: argument of `FUNCTION_ARG' and other related values. For some
234: target machines, the type `int' suffices and can hold the number
235: of bytes of argument so far.
236:
237: `INIT_CUMULATIVE_ARGS (CUM, FNTYPE)'
238: A C statement (sans semicolon) for initializing the variable CUM
239: for the state at the beginning of the argument list. The
240: variable has type `CUMULATIVE_ARGS'. The value of FNTYPE is the
241: tree node for the data type of the function which will receive
242: the args, or 0 if the args are to a compiler support library
243: function.
244:
245: `FUNCTION_ARG_ADVANCE (CUM, MODE, TYPE, NAMED)'
246: Update the summarizer variable CUM to advance past an argument
247: in the argument list. The values MODE, TYPE and NAMED describe
248: that argument. Once this is done, the variable CUM is suitable
249: for analyzing the *following* argument with `FUNCTION_ARG', etc.
250:
251: `FUNCTION_ARG_REGNO_P (REGNO)'
252: A C expression that is nonzero if REGNO is the number of a hard
253: register in which function arguments are sometimes passed. This
254: does *not* include implicit arguments such as the static chain
255: and the structure-value address. On many machines, no registers
256: can be used for this purpose since all function arguments are
257: pushed on the stack.
258:
259: `FUNCTION_ARG_PADDING (MODE, SIZE)'
260: If defined, a C expression which determines whether, and in
261: which direction, to pad out an argument with extra space. The
262: value should be of type `enum direction': either `upward' to pad
263: above the argument, `downward' to pad below, or `none' to
264: inhibit padding.
265:
266: The argument SIZE is an RTX which describes the size of the
267: argument, in bytes. It should be used only if MODE is
268: `BLKmode'. Otherwise, SIZE is 0.
269:
270: This macro does not control the *amount* of padding; that is
271: always just enough to reach the next multiple of `PARM_BOUNDARY'.
272:
273: This macro has a default definition which is right for most
274: systems. For little-endian machines, the default is to pad
275: upward. For big-endian machines, the default is to pad downward
276: for an argument of constant size shorter than an `int', and
277: upward otherwise.
278:
279: `FUNCTION_PROLOGUE (FILE, SIZE)'
280: A C compound statement that outputs the assembler code for entry
281: to a function. The prologue is responsible for setting up the
282: stack frame, initializing the frame pointer register, saving
283: registers that must be saved, and allocating SIZE additional
284: bytes of storage for the local variables. SIZE is an integer.
285: FILE is a stdio stream to which the assembler code should be
286: output.
287:
288: The label for the beginning of the function need not be output
289: by this macro. That has already been done when the macro is run.
290:
291: To determine which registers to save, the macro can refer to the
292: array `regs_ever_live': element R is nonzero if hard register R
293: is used anywhere within the function. This implies the function
294: prologue should save register R, but not if it is one of the
295: call-used registers.
296:
297: On machines where functions may or may not have frame-pointers,
298: the function entry code must vary accordingly; it must set up
299: the frame pointer if one is wanted, and not otherwise. To
300: determine whether a frame pointer is in wanted, the macro can
301: refer to the variable `frame_pointer_needed'. The variable's
302: value will be 1 at run time in a function that needs a frame
303: pointer.
304:
305: `FUNCTION_PROFILER (FILE, LABELNO)'
306: A C statement or compound statement to output to FILE some
307: assembler code to call the profiling subroutine `mcount'.
308: Before calling, the assembler code must load the address of a
309: counter variable into a register where `mcount' expects to find
310: the address. The name of this variable is `LP' followed by the
311: number LABELNO, so you would generate the name using `LP%d' in a
312: `fprintf'.
313:
314: The details of how the address should be passed to `mcount' are
315: determined by your operating system environment, not by GNU CC.
316: To figure them out, compile a small program for profiling using
317: the system's installed C compiler and look at the assembler code
318: that results.
319:
320: `EXIT_IGNORES_STACK'
321: Define this macro as a C expression that is nonzero if the
322: return instruction or the function epilogue ignores the value of
323: the stack pointer; in other words, if it is safe to delete an
324: instruction to adjust the stack pointer before a return from the
325: function.
326:
327: Note that this macro's value is relevant only for for which
328: frame pointers are maintained. It is never possible to delete a
329: final stack adjustment in a function that has no frame pointer,
330: and the compiler knows this regardless of `EXIT_IGNORES_STACK'.
331:
332: `FUNCTION_EPILOGUE (FILE, SIZE)'
333: A C compound statement that outputs the assembler code for exit
334: from a function. The epilogue is responsible for restoring the
335: saved registers and stack pointer to their values when the
336: function was called, and returning control to the caller. This
337: macro takes the same arguments as the macro `FUNCTION_PROLOGUE',
338: and the registers to restore are determined from
339: `regs_ever_live' and `CALL_USED_REGISTERS' in the same way.
340:
341: On some machines, there is a single instruction that does all
342: the work of returning from the function. On these machines,
343: give that instruction the name `return' and do not define the
344: macro `FUNCTION_EPILOGUE' at all.
345:
346: Do not define a pattern named `return' if you want the
347: `FUNCTION_EPILOGUE' to be used. If you want the target switches
348: to control whether return instructions or epilogues are used,
349: define a `return' pattern with a validity condition that tests
350: the target switches appropriately. If the `return' pattern's
351: validity condition is false, epilogues will be used.
352:
353: On machines where functions may or may not have frame-pointers,
354: the function exit code must vary accordingly. Sometimes the
355: code for these two cases is completely different. To determine
356: whether a frame pointer is in wanted, the macro can refer to the
357: variable `frame_pointer_needed'. The variable's value will be 1
358: at run time in a function that needs a frame pointer.
359:
360: On some machines, some functions pop their arguments on exit
361: while others leave that for the caller to do. For example, the
362: 68020 when given `-mrtd' pops arguments in functions that take a
363: fixed number of arguments.
364:
365: Your definition of the macro `RETURN_POPS_ARGS' decides which
366: functions pop their own arguments. `FUNCTION_EPILOGUE' needs to
367: know what was decided. The variable
368: `current_function_pops_args' is nonzero if the function should
369: pop its own arguments. If so, use the variable
370: `current_function_args_size' as the number of bytes to pop.
371:
372: `FIX_FRAME_POINTER_ADDRESS (ADDR, DEPTH)'
373: A C compound statement to alter a memory address that uses the
374: frame pointer register so that it uses the stack pointer
375: register instead. This must be done in the instructions that
376: load parameter values into registers, when the reload pass
377: determines that a frame pointer is not necessary for the
378: function. ADDR will be a C variable name, and the updated
379: address should be stored in that variable. DEPTH will be the
380: current depth of stack temporaries (number of bytes of arguments
381: currently pushed). The change in offset between a
382: frame-pointer-relative address and a stack-pointer-relative
383: address must include DEPTH.
384:
385: Even if your machine description specifies there will always be
386: a frame pointer in the frame pointer register, you must still
387: define `FIX_FRAME_POINTER_ADDRESS', but the definition will
388: never be executed at run time, so it may be empty.
389:
390:
391:
392: File: gcc.info, Node: Library Names, Next: Addressing Modes, Prev: Stack Layout, Up: Machine Macros
393:
394: Library Subroutine Names
395: ========================
396:
397: `UDIVSI3_LIBCALL'
398: A C string constant giving the name of the function to call for
399: division of a full-word by a full-word. If you do not define
400: this macro, the default name is used, which is `_udivsi3', a
401: function defined in `gnulib'.
402:
403: `UMODSI3_LIBCALL'
404: A C string constant giving the name of the function to call for
405: the remainder in division of a full-word by a full-word. If you
406: do not define this macro, the default name is used, which is
407: `_umodsi3', a function defined in `gnulib'.
408:
409: `TARGET_MEM_FUNCTIONS'
410: Define this macro if GNU CC should generate calls to the System
411: V (and ANSI C) library functions `memcpy' and `memset' rather
412: than the BSD functions `bcopy' and `bzero'.
413:
414:
415:
416: File: gcc.info, Node: Addressing Modes, Next: Misc, Prev: Library Names, Up: Machine Macros
417:
418: Addressing Modes
419: ================
420:
421: `HAVE_POST_INCREMENT'
422: Define this macro if the machine supports post-increment
423: addressing.
424:
425: `HAVE_PRE_INCREMENT'
426: `HAVE_POST_DECREMENT'
427: `HAVE_PRE_DECREMENT'
428: Similar for other kinds of addressing.
429:
430: `CONSTANT_ADDRESS_P (X)'
431: A C expression that is 1 if the RTX X is a constant whose value
432: is an integer. This includes integers whose values are not
433: explicitly known, such as `symbol_ref' and `label_ref'
434: expressions and `const' arithmetic expressions.
435:
436: On most machines, this can be defined as `CONSTANT_P (X)', but a
437: few machines are more restrictive in which constant addresses
438: are supported.
439:
440: `MAX_REGS_PER_ADDRESS'
441: A number, the maximum number of registers that can appear in a
442: valid memory address.
443:
444: `GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)'
445: A C compound statement with a conditional `goto LABEL;' executed
446: if X (an RTX) is a legitimate memory address on the target
447: machine for a memory operand of mode MODE.
448:
449: It usually pays to define several simpler macros to serve as
450: subroutines for this one. Otherwise it may be too complicated
451: to understand.
452:
453: This macro must exist in two variants: a strict variant and a
454: non-strict one. The strict variant is used in the reload pass.
455: It must be defined so that any pseudo-register that has not been
456: allocated a hard register is considered a memory reference. In
457: contexts where some kind of register is required, a
458: pseudo-register with no hard register must be rejected.
459:
460: The non-strict variant is used in other passes. It must be
461: defined to accept all pseudo-registers in every context where
462: some kind of register is required.
463:
464: Compiler source files that want to use the strict variant of
465: this macro define the macro `REG_OK_STRICT'. You should use an
466: `#ifdef REG_OK_STRICT' conditional to define the strict variant
467: in that case and the non-strict variant otherwise.
468:
469: Typically among the subroutines used to define
470: `GO_IF_LEGITIMATE_ADDRESS' are subroutines to check for
471: acceptable registers for various purposes (one for base
472: registers, one for index registers, and so on). Then only these
473: subroutine macros need have two variants; the higher levels of
474: macros may be the same whether strict or not.
475:
476: `REG_OK_FOR_BASE_P (X)'
477: A C expression that is nonzero if X (asumed to be a `reg' RTX)
478: is valid for use as a base register. For hard registers, it
479: should always accept those which the hardware permits and reject
480: the others. Whether the macro accepts or rejects pseudo
481: registers must be controlled by `REG_OK_STRICT' as described
482: above. This usually requires two variant definitions, of which
483: `REG_OK_STRICT' controls the one actually used.
484:
485: `REG_OK_FOR_INDEX_P (X)'
486: A C expression that is nonzero if X (asumed to be a `reg' RTX)
487: is valid for use as an index register.
488:
489: The difference between an index register and a base register is
490: that the index register may be scaled. If an address involves
491: the sum of two registers, neither one of them scaled, then
492: either one may be labeled the ``base'' and the other the
493: ``index''; but whichever labeling is used must fit the machine's
494: constraints of which registers may serve in each capacity. The
495: compiler will try both labelings, looking for one that is valid,
496: and will reload one or both registers only if neither labeling
497: works.
498:
499: `LEGITIMIZE_ADDRESS (X, OLDX, MODE, WIN)'
500: A C compound statement that attempts to replace X with a valid
501: memory address for an operand of mode MODE. WIN will be a C
502: statement label elsewhere in the code; the macro definition may
503: use
504:
505: GO_IF_LEGITIMATE_ADDRESS (MODE, X, WIN);
506:
507: to avoid further processing if the address has become legitimate.
508:
509: X will always be the result of a call to
510: `break_out_memory_refs', and OLDX will be the operand that was
511: given to that function to produce X.
512:
513: The code generated by this macro should not alter the
514: substructure of X. If it transforms X into a more legitimate
515: form, it should assign X (which will always be a C variable) a
516: new value.
517:
518: It is not necessary for this macro to come up with a legitimate
519: address. The compiler has standard ways of doing so in all
520: cases. In fact, it is safe for this macro to do nothing. But
521: often a machine-dependent strategy can generate better code.
522:
523: `GO_IF_MODE_DEPENDENT_ADDRESS (ADDR, LABEL)'
524: A C statement or compound statement with a conditional `goto
525: LABEL;' executed if memory address X (an RTX) can have different
526: meanings depending on the machine mode of the memory reference
527: it is used for.
528:
529: Autoincrement and autodecrement addresses typically have
530: mode-dependent effects because the amount of the increment or
531: decrement is the size of the operand being addressed. Some
532: machines have other mode-dependent addresses. Many RISC
533: machines have no mode-dependent addresses.
534:
535: You may assume that ADDR is a valid address for the machine.
536:
537: `LEGITIMATE_CONSTANT_P (X)'
538: A C expression that is nonzero if X is a legitimate constant for
539: an immediate operand on the target machine. You can assume that
540: either X is a `const_double' or it satisfies `CONSTANT_P', so
541: you need not check these things. In fact, `1' is a suitable
542: definition for this macro on machines where any `const_double'
543: is valid and anything `CONSTANT_P' is valid.
544:
545:
546:
547: File: gcc.info, Node: Misc, Next: Condition Code, Prev: Addressing Modes, Up: Machine Macros
548:
549: Miscellaneous Parameters
550: ========================
551:
552: `CASE_VECTOR_MODE'
553: An alias for a machine mode name. This is the machine mode that
554: elements of a jump-table should have.
555:
556: `CASE_VECTOR_PC_RELATIVE'
557: Define this macro if jump-tables should contain relative
558: addresses.
559:
560: `CASE_DROPS_THROUGH'
561: Define this if control falls through a `case' insn when the
562: index value is out of range. This means the specified
563: default-label is actually ignored by the `case' insn proper.
564:
565: `IMPLICIT_FIX_EXPR'
566: An alias for a tree code that should be used by default for
567: conversion of floating point values to fixed point. Normally,
568: `FIX_ROUND_EXPR' is used.
569:
570: `FIXUNS_TRUNC_LIKE_FIX_TRUNC'
571: Define this macro if the same instructions that convert a
572: floating point number to a signed fixed point number also
573: convert validly to an unsigned one.
574:
575: `EASY_DIV_EXPR'
576: An alias for a tree code that is the easiest kind of division to
577: compile code for in the general case. It may be
578: `TRUNC_DIV_EXPR', `FLOOR_DIV_EXPR', `CEIL_DIV_EXPR' or
579: `ROUND_DIV_EXPR'. These four division operators differ in how
580: they round the result to an integer. `EASY_DIV_EXPR' is used
581: when it is permissible to use any of those kinds of division and
582: the choice should be made on the basis of efficiency.
583:
584: `DEFAULT_SIGNED_CHAR'
585: An expression whose value is 1 or 0, according to whether the
586: type `char' should be signed or unsigned by default. The user
587: can always override this default with the options
588: `-fsigned-char' and `-funsigned-char'.
589:
590: `SCCS_DIRECTIVE'
591: Define this if the preprocessor should ignore `#sccs' directives
592: and print no error message.
593:
594: `IDENT_DIRECTIVE'
595: Define this if the preprocessor should ignore `#ident'
596: directives and print no error message.
597:
598: `MOVE_MAX'
599: The maximum number of bytes that a single instruction can move
600: quickly from memory to memory.
601:
602: `INT_TYPE_SIZE'
603: A C expression for the size in bits of the type `int' on the
604: target machine.
605:
606: `SLOW_BYTE_ACCESS'
607: Define this macro as a C expression which is nonzero if
608: accessing less than a word of memory (i.e. a `char' or a
609: `short') is slow (requires more than one instruction).
610:
611: `SLOW_ZERO_EXTEND'
612: Define this macro if zero-extension (of a `char' or `short' to
613: an `int') can be done faster if the destination is a register
614: that is known to be zero.
615:
616: If you define this macro, you must have instruction patterns
617: that recognize RTL structures like this:
618:
619: (set (strict-low-part (subreg:QI (reg:SI ...) 0)) ...)
620:
621: and likewise for `HImode'.
622:
623: `SHIFT_COUNT_TRUNCATED'
624: Define this macro if shift instructions ignore all but the
625: lowest few bits of the shift count. It implies that a
626: sign-extend or zero-extend instruction for the shift count can
627: be omitted.
628:
629: `TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)'
630: A C expression which is nonzero if on this machine it is safe to
631: ``convert'' an integer of INPREC bits to one of OUTPREC bits
632: (where OUTPREC is smaller than INPREC) by merely operating on it
633: as if it had only OUTPREC bits.
634:
635: On many machines, this expression can be 1.
636:
637: `NO_FUNCTION_CSE'
638: Define this macro if it is as good or better to call a constant
639: function address than to call an address kept in a register.
640:
641: `PROMOTE_PROTOTYPES'
642: Define this macro if an argument declared as `char' or `short'
643: in a prototype should actually be passed as an `int'. In
644: addition to avoiding errors in certain cases of mismatch, it
645: also makes for better code on certain machines.
646:
647: `STORE_FLAG_VALUE'
648: A C expression for the value stored by a store-flag instruction
649: (`sCOND') when the condition is true. This is usually 1 or -1;
650: it is required to be an odd number.
651:
652: Do not define `STORE_FLAG_VALUE' if the machine has no
653: store-flag instructions.
654:
655: `Pmode'
656: An alias for the machine mode for pointers. Normally the
657: definition can be
658:
659: #define Pmode SImode
660:
661: `FUNCTION_MODE'
662: An alias for the machine mode used for memory references to
663: functions being called, in `call' RTL expressions. On most
664: machines this should be `QImode'.
665:
666: `INSN_MACHINE_INFO'
667: This macro should expand into a C structure type to use for the
668: machine-dependent info field specified with the optional last
669: argument in `define_insn' and `define_peephole' patterns. For
670: example, it might expand into `struct machine_info'; then it
671: would be up to you to define this structure in the `tm.h' file.
672:
673: You do not need to define this macro if you do not write the
674: optional last argument in any of the patterns in the machine
675: description.
676:
677: `CONST_COSTS (X, CODE)'
678: A part of a C `switch' statement that describes the relative
679: costs of constant RTL expressions. It must contain `case'
680: labels for expression codes `const_int', `const', `symbol_ref',
681: `label_ref' and `const_double'. Each case must ultimately reach
682: a `return' statement to return the relative cost of the use of
683: that kind of constant value in an expression. The cost may
684: depend on the precise value of the constant, which is available
685: for examination in X.
686:
687: CODE is the expression code--redundant, since it can be obtained
688: with `GET_CODE (X)'.
689:
690: `DOLLARS_IN_IDENTIFIERS'
691: Define this to be nonzero if the character `$' should be allowed
692: by default in identifier names.
693:
694:
695:
696: File: gcc.info, Node: Condition Code, Next: Assembler Format, Prev: Misc, Up: Machine Macros
697:
698: Condition Code Information
699: ==========================
700:
701: The file `conditions.h' defines a variable `cc_status' to describe
702: how the condition code was computed (in case the interpretation of
703: the condition code depends on the instruction that it was set by).
704: This variable contains the RTL expressions on which the condition
705: code is currently based, and several standard flags.
706:
707: Sometimes additional machine-specific flags must be defined in the
708: machine description header file. It can also add additional
709: machine-specific information by defining `CC_STATUS_MDEP'.
710:
711: `CC_STATUS_MDEP'
712: C code for a data type which is used for declaring the `mdep'
713: component of `cc_status'. It defaults to `int'.
714:
715: `CC_STATUS_MDEP_INIT'
716: A C expression for the initial value of the `mdep' field. It
717: defaults to 0.
718:
719: `NOTICE_UPDATE_CC (EXP, INSN)'
720: A C compound statement to set the components of `cc_status'
721: appropriately for an insn INSN whose body is EXP. It is this
722: macro's responsibility to recognize insns that set the condition
723: code as a byproduct of other activity as well as those that
724: explicitly set `(cc0)'.
725:
726: If there are insn that do not set the condition code but do
727: alter other machine registers, this macro must check to see
728: whether they invalidate the expressions that the condition code
729: is recorded as reflecting. For example, on the 68000, insns
730: that store in address registers do not set the condition code,
731: which means that usually `NOTICE_UPDATE_CC' can leave
732: `cc_status' unaltered for such insns. But suppose that the
733: previous insn set the condition code based on location
734: `a4@(102)' and the current insn stores a new value in `a4'.
735: Although the condition code is not changed by this, it will no
736: longer be true that it reflects the contents of `a4@(102)'.
737: Therefore, `NOTICE_UPDATE_CC' must alter `cc_status' in this
738: case to say that nothing is known about the condition code value.
739:
740: The definition of `NOTICE_UPDATE_CC' must be prepared to deal
741: with the results of peephole optimization: insns whose patterns
742: are `parallel' RTXs containing various `reg', `mem' or constants
743: which are just the operands. The RTL structure of these insns
744: is not sufficient to indicate what the insns actually do. What
745: `NOTICE_UPDATE_CC' should do when it sees one is just to run
746: `CC_STATUS_INIT'.
747:
748:
This archive runs on limited infrastructure. Preserving old code on modern bandwidth. Automated agents are requested to crawl responsibly.