Category : C Source Code
Archive   : GCCTXT.ZIP
Filename : TM.TXT

INTERNALS

































































1. Machine Description Macros

In addition to the file `machine.md', a machine
description includes a C header file conventionally given
the name `machine.h'. This header file defines numerous
macros that convey the information about the target machine
that does not fit into the scheme of the `.md' file. The
file `tm.h' should be a link to `machine.h'. The header
file `config.h' includes `tm.h' and most compiler source
files include `config.h'.



1.1. Controlling the Compilation Driver, `gcc'

SWITCH_TAKES_ARG (char)
A C expression which determines whether the option
`-char' takes arguments. The value should be the
number of arguments that option takes--zero, for
many options.

By default, this macro is defined to handle the
standard options properly. You need not define it
unless you wish to add additional options which
take arguments.

WORD_SWITCH_TAKES_ARG (name)
A C expression which determines whether the option
`-name' takes arguments. The value should be the
number of arguments that option takes--zero, for
many options. This macro rather than
SWITCH_TAKES_ARG is used for multi-character op-
tion names.

By default, this macro is defined to handle the
standard options properly. You need not define it
unless you wish to add additional options which
take arguments.

SWITCHES_NEED_SPACES
A string-valued C expression which is nonempty if
the linker needs a space between the `-L' or `-o'
option and its argument.

If this macro is not defined, the default value is
0.

CPP_SPEC
A C string constant that tells the GNU CC driver
program options to pass to CPP. It can also
specify how to translate options you give to GNU
CC into options for GNU CC to pass to the CPP.














Do not define this macro if it does not need to do
anything.

SIGNED_CHAR_SPEC
A C string constant that tells the GNU CC driver
program options to pass to CPP. By default, this
macro is defined to pass the option `-
D__CHAR_UNSIGNED__' to CPP if char will be treated
as unsigned char by cc1.

Do not define this macro unless you need to over-
ride the default definition.

CC1_SPEC
A C string constant that tells the GNU CC driver
program options to pass to cc1. It can also
specify how to translate options you give to GNU
CC into options for GNU CC to pass to the cc1.

Do not define this macro if it does not need to do
anything.

CC1PLUS_SPEC
A C string constant that tells the GNU CC driver
program options to pass to cc1plus. It can also
specify how to translate options you give to GNU
CC into options for GNU CC to pass to the cc1plus.

Do not define this macro if it does not need to do
anything.

ASM_SPEC
A C string constant that tells the GNU CC driver
program options to pass to the assembler. It can
also specify how to translate options you give to
GNU CC into options for GNU CC to pass to the as-
sembler. See the file `sun3.h' for an example of
this.

Do not define this macro if it does not need to do
anything.

ASM_FINAL_SPEC
A C string constant that tells the GNU CC driver
program how to run any programs which cleanup
after the normal assembler. Normally, this is not
needed. See the file `mips.h' for an example of
this.

Do not define this macro if it does not need to do
anything.















LINK_SPEC
A C string constant that tells the GNU CC driver
program options to pass to the linker. It can
also specify how to translate options you give to
GNU CC into options for GNU CC to pass to the
linker.

Do not define this macro if it does not need to do
anything.

LIB_SPEC
Another C string constant used much like
LINK_SPEC. The difference between the two is that
LIB_SPEC is used at the end of the command given
to the linker.

If this macro is not defined, a default is provid-
ed that loads the standard C library from the usu-
al place. See `gcc.c'.

STARTFILE_SPEC
Another C string constant used much like
LINK_SPEC. The difference between the two is that
STARTFILE_SPEC is used at the very beginning of
the command given to the linker.

If this macro is not defined, a default is provid-
ed that loads the standard C startup file from the
usual place. See `gcc.c'.

ENDFILE_SPEC
Another C string constant used much like
LINK_SPEC. The difference between the two is that
ENDFILE_SPEC is used at the very end of the com-
mand given to the linker.

Do not define this macro if it does not need to do
anything.

LINK_LIBGCC_SPECIAL
Define this macro meaning that gcc should find the
library `libgcc.a' by hand, rather than passing
the argument `-lgcc' to tell the linker to do the
search.

RELATIVE_PREFIX_NOT_LINKDIR
Define this macro to tell gcc that it should only
translate a `-B' prefix into a `-L' linker option
if the prefix indicates an absolute file name.

STANDARD_EXEC_PREFIX
Define this macro as a C string constant if you
wish to override the standard choice of













`/usr/local/lib/gcc/' as the default prefix to try
when searching for the executable files of the
compiler.

MD_EXEC_PREFIX
If defined, this macro is an additional prefix to
try after STANDARD_EXEC_PREFIX. MD_EXEC_PREFIX is
not searched when the `-b' option is used, or the
compiler is built as a cross compiler.

STANDARD_STARTFILE_PREFIX
Define this macro as a C string constant if you
wish to override the standard choice of
`/usr/local/lib/gcc/' as the default prefix to try
when searching for startup files such as `crt0.o'.

MD_STARTFILE_PREFIX
If defined, this macro supplies an additional pre-
fix to try after the standard prefixes.
MD_EXEC_PREFIX is not searched when the `-b' op-
tion is used, or the compiler is built as a cross
compiler.

LOCAL_INCLUDE_DIR
Define this macro as a C string constant if you
wish to override the standard choice of
`/usr/local/include' as the default prefix to try
when searching for local header files.
LOCAL_INCLUDE_DIR comes before SYSTEM_INCLUDE_DIR
in the search order.

Cross compilers do not use this macro and do not
search either `/usr/local/include' or its replace-
ment.

SYSTEM_INCLUDE_DIR
Define this macro as a C string constant if you
wish to specify a system-specific directory to
search for header files before the standard direc-
tory. SYSTEM_INCLUDE_DIR comes before
STANDARD_INCLUDE_DIR in the search order.

Cross compilers do not use this macro and do not
search the directory specified.

STANDARD_INCLUDE_DIR
Define this macro as a C string constant if you
wish to override the standard choice of
`/usr/include' as the default prefix to try when
searching for header files.

Cross compilers do not use this macro and do not
search either `/usr/include' or its replacement.













INCLUDE_DEFAULTS
Define this macro if you wish to override the en-
tire default search path for include files. The
default search path includes
GPLUSPLUS_INCLUDE_DIR, GCC_INCLUDE_DIR,
LOCAL_INCLUDE_DIR, SYSTEM_INCLUDE_DIR, and
STANDARD_INCLUDE_DIR. In addition, the macros
GPLUSPLUS_INCLUDE_DIR and GCC_INCLUDE_DIR are de-
fined automatically by `Makefile', and specify
private search areas for GCC. The directory
GPLUSPLUS_INCLUDE_DIR is used only for C++ pro-
grams.

The definition should be an initializer for an ar-
ray of structures. Each array element should have
two elements: the directory name (a string con-
stant) and a flag for C++-only directories. Mark
the end of the array with a null element. For ex-
ample, here is the definition used for VMS:


#define INCLUDE_DEFAULTS \
{ \
{ "GNU_GXX_INCLUDE:", 1}, \
{ "GNU_CC_INCLUDE:", 0}, \
{ "SYS$SYSROOT:[SYSLIB.]", 0}, \
{ ".", 0}, \
{ 0, 0} \
}




Here is the order of prefixes tried for exec files:

1. Any prefixes specified by the user with `-B'.

2. The environment variable GCC_EXEC_PREFIX, if any.

3. The directories specified by the environment vari-
able COMPILER_PATH.

4. The macro STANDARD_EXEC_PREFIX.

5. `/usr/lib/gcc/'.

6. The macro MD_EXEC_PREFIX, if any.


Here is the order of prefixes tried for startfiles:

1. Any prefixes specified by the user with `-B'.














2. The environment variable GCC_EXEC_PREFIX, if any.

3. The directories specified by the environment vari-
able LIBRARY_PATH.

4. The macro STANDARD_EXEC_PREFIX.

5. `/usr/lib/gcc/'.

6. The macro MD_EXEC_PREFIX, if any.

7. The macro MD_STARTFILE_PREFIX, if any.

8. The macro STANDARD_STARTFILE_PREFIX.

9. `/lib/'.

10. `/usr/lib/'.


1.2. Run-time Target Specification

CPP_PREDEFINES
Define this to be a string constant containing `-
D' options to define the predefined macros that
identify this machine and system. These macros
will be predefined unless the `-ansi' option is
specified.

In addition, a parallel set of macros are prede-
fined, whose names are made by appending `__' at
the beginning and at the end. These `__' macros
are permitted by the ANSI standard, so they are
predefined regardless of whether `-ansi' is speci-
fied.

For example, on the Sun, one can use the following
value:


"-Dmc68000 -Dsun -Dunix"



The result is to define the macros
__mc68000__, __sun__ and __unix__ uncondition-
ally, and the macros mc68000, sun and unix
provided `-ansi' is not specified.

STDC_VALUE
Define the value to be assigned to the built-
in macro __STDC__. The default is the value
`1'.













extern int target_flags;
This declaration should be present.

TARGET_...
This series of macros is to allow compiler
command arguments to enable or disable the use
of optional features of the target machine.
For example, one machine description serves
both the 68000 and the 68020; a command argu-
ment tells the compiler whether it should use
68020-only instructions or not. This command
argument works by means of a macro TAR-
GET_68020 that tests a bit in target_flags.

Define a macro TARGET_featurename for each
such option. Its definition should test a bit
in target_flags; for example:


#define TARGET_68020 (target_flags & 1)



One place where these macros are used is in
the condition-expressions of instruction pat-
terns. Note how TARGET_68020 appears fre-
quently in the 68000 machine description file,
`m68k.md'. Another place they are used is in
the definitions of the other macros in the
`machine.h' file.

TARGET_SWITCHES
This macro defines names of command options to
set and clear bits in target_flags. Its de-
finition is an initializer with a subgrouping
for each command option.

Each subgrouping contains a string constant,
that defines the option name, and a number,
which contains the bits to set in
target_flags. A negative number says to clear
bits instead; the negative of the number is
which bits to clear. The actual option name
is made by appending `-m' to the specified
name.

One of the subgroupings should have a null
string. The number in this grouping is the
default value for target_flags. Any target
options act starting with that value.

Here is an example which defines `-m68000' and
`-m68020' with opposite meanings, and picks













the latter as the default:


#define TARGET_SWITCHES \
{ { "68020", 1}, \
{ "68000", -1}, \
{ "", 1}}



TARGET_OPTIONS
This macro is similar to TARGET_SWITCHES but
defines names of command options that have
values. Its definition is an initializer with
a subgrouping for each command option.

Each subgrouping contains a string constant,
that defines the fixed part of the option
name, and the address of a variable. The
variable, type char *, is set to the variable
part of the given option if the fixed part
matches. The actual option name is made by
appending `-m' to the specified name.

Here is an example which defines `-mshort-
data-number'. If the given option is `-
mshort-data-512', the variable m88k_short_data
will be set to the string "512".


extern char *m88k_short_data;
#define TARGET_OPTIONS { { "short-data-", &m88k_short_data } }



TARGET_VERSION
This macro is a C statement to print on stderr
a string describing the particular machine
description choice. Every machine description
should define TARGET_VERSION. For example:


#ifdef MOTOROLA
#define TARGET_VERSION fprintf (stderr, " (68k, Motorola syntax)");
#else
#define TARGET_VERSION fprintf (stderr, " (68k, MIT syntax)");
#endif



OVERRIDE_OPTIONS
Sometimes certain combinations of command op-
tions do not make sense on a particular target













machine. You can define a macro
OVERRIDE_OPTIONS to take account of this.
This macro, if defined, is executed once just
after all the command options have been
parsed.

Don't use this macro to turn on various extra
optimizations for `-O'. That is what
OPTIMIZATION_OPTIONS is for.

OPTIMIZATION_OPTIONS (level)
Some machines may desire to change what optim-
izations are performed for various optimiza-
tion levels. This macro, if defined, is exe-
cuted once just after the optimization level
is determined and before the remainder of the
command options have been parsed. Values set
in this macro are used as the default values
for the other command line options.

level is the optimization level specified; 2
if -O2 is specified, 1 if -O is specified, and
0 if neither is specified.

Do not examine write_symbols in this macro!
The debugging options are not supposed to
alter the generated code.


1.3. Storage Layout

Note that the definitions of the macros in this table
which are sizes or alignments measured in bits do not need
to be constant. They can be C expressions that refer to
static variables, such as the target_flags. See section
Run-time Target.

BITS_BIG_ENDIAN
Define this macro to be the value 1 if the most
significant bit in a byte has the lowest number;
otherwise define it to be the value zero. This
means that bit-field instructions count from the
most significant bit. If the machine has no bit-
field instructions, this macro is irrelevant.

This macro does not affect the way structure
fields are packed into bytes or words; that is
controlled by BYTES_BIG_ENDIAN.

BYTES_BIG_ENDIAN
Define this macro to be 1 if the most significant
byte in a word has the lowest number.














WORDS_BIG_ENDIAN
Define this macro to be 1 if, in a multiword ob-
ject, the most significant word has the lowest
number.

BITS_PER_UNIT
Number of bits in an addressable storage unit
(byte); normally 8.

BITS_PER_WORD
Number of bits in a word; normally 32.

MAX_BITS_PER_WORD
Maximum number of bits in a word. If this is un-
defined, the default is BITS_PER_WORD. Otherwise,
it is the constant value that is the largest value
that BITS_PER_WORD can have at run-time.

UNITS_PER_WORD
Number of storage units in a word; normally 4.

POINTER_SIZE
Width of a pointer, in bits.

PARM_BOUNDARY
Normal alignment required for function parameters
on the stack, in bits. All stack parameters re-
ceive least this much alignment regardless of data
type. On most machines, this is the same as the
size of an integer.

STACK_BOUNDARY
Define this macro if you wish to preserve a cer-
tain alignment for the stack pointer. The defini-
tion is a C expression for the desired alignment
(measured in bits).

If PUSH_ROUNDING is not defined, the stack will
always be aligned to the specified boundary. If
PUSH_ROUNDING is defined and specifies a less
strict alignment than STACK_BOUNDARY, the stack
may be momentarily unaligned while pushing argu-
ments.

FUNCTION_BOUNDARY
Alignment required for a function entry point, in
bits.

BIGGEST_ALIGNMENT
Biggest alignment that any data type can require
on this machine, in bits.















BIGGEST_FIELD_ALIGNMENT
Biggest alignment that any structure field can re-
quire on this machine, in bits.

MAX_OFILE_ALIGNMENT
Biggest alignment supported by the object file
format of this machine. Use this macro to limit
the alignment which can be specified using the
__attribute__ ((aligned (n))) construct. If not
defined, the default value is BIGGEST_ALIGNMENT.

DATA_ALIGNMENT (type, basic-align)
If defined, a C expression to compute the align-
ment for a static variable. type is the data
type, and basic-align is the alignment that the
object would ordinarily have. The value of this
macro is used instead of that alignment to align
the object.

If this macro is not defined, then basic-align is
used.

One use of this macro is to increase alignment of
medium-size data to make it all fit in fewer cache
lines. Another is to cause character arrays to be
word-aligned so that strcpy calls that copy con-
stants to character arrays can be done inline.

CONSTANT_ALIGNMENT (constant, basic-align)
If defined, a C expression to compute the align-
ment given to a constant that is being placed in
memory. constant is the constant and basic-align
is the alignment that the object would ordinarily
have. The value of this macro is used instead of
that alignment to align the object.

If this macro is not defined, then basic-align is
used.

The typical use of this macro is to increase
alignment for string constants to be word aligned
so that strcpy calls that copy constants can be
done inline.

EMPTY_FIELD_BOUNDARY
Alignment in bits to be given to a structure bit
field that follows an empty field such as int :
0;.

STRUCTURE_SIZE_BOUNDARY
Number of bits which any structure or union's size
must be a multiple of. Each structure or union's
size is rounded up to a multiple of this.













If you do not define this macro, the default is
the same as BITS_PER_UNIT.

STRICT_ALIGNMENT
Define this if instructions will fail to work if
given data not on the nominal alignment. If in-
structions will merely go slower in that case, do
not define this macro.

PCC_BITFIELD_TYPE_MATTERS
Define this if you wish to imitate the way many
other C compilers handle alignment of bitfields
and the structures that contain them.

The behavior is that the type written for a bit-
field (int, short, or other integer type) imposes
an alignment for the entire structure, as if the
structure really did contain an ordinary field of
that type. In addition, the bitfield is placed
within the structure so that it would fit within
such a field, not crossing a boundary for it.

Thus, on most machines, a bitfield whose type is
written as int would not cross a four-byte boun-
dary, and would force four-byte alignment for the
whole structure. (The alignment used may not be
four bytes; it is controlled by the other align-
ment parameters.)

If the macro is defined, its definition should be
a C expression; a nonzero value for the expression
enables this behavior.

Note that if this macro is not defined, or its
value is zero, some bitfields may cross more than
one alignment boundary. The compiler can support
such references if there are `insv', `extv', and
`extzv' insns that can directly reference memory.

The other known way of making bitfields work is to
define STRUCTURE_SIZE_BOUNDARY as large as
BIGGEST_ALIGNMENT. Then every structure can be
accessed with fullwords.

Unless the machine has bitfield instructions or
you define STRUCTURE_SIZE_BOUNDARY that way, you
must define PCC_BITFIELD_TYPE_MATTERS to have a
nonzero value.

BITFIELD_NBYTES_LIMITED
Like PCC_BITFIELD_TYPE_MATTERS except that its ef-
fect is limited to aligning a bitfield within the
structure.













ROUND_TYPE_SIZE (struct, size, align)
Define this macro as an expression for the overall
size of a structure (given by struct as a tree
node) when the size computed from the fields is
size and the alignment is align.

The default is to round size up to a multiple of
align.

ROUND_TYPE_ALIGN (struct, computed, specified)
Define this macro as an expression for the align-
ment of a structure (given by struct as a tree
node) if the alignment computed in the usual way
is computed and the alignment explicitly specified
was specified.

The default is to use specified if it is larger;
otherwise, use the smaller of computed and
BIGGEST_ALIGNMENT

MAX_FIXED_MODE_SIZE
An integer expression for the size in bits of the
largest integer machine mode that should actually
be used. All integer machine modes of this size
or smaller can be used for structures and unions
with the appropriate sizes. If this macro is un-
defined, GET_MODE_BITSIZE (DImode) is assumed.

CHECK_FLOAT_VALUE (mode, value)
A C statement to validate the value value (of type
double) for mode mode. This means that you check
whether value fits within the possible range of
values for mode mode on this target machine. The
mode mode is always SFmode or DFmode.

If value is not valid, you should call error to
print an error message and then assign some valid
value to value. Allowing an invalid value to go
through the compiler can produce incorrect assem-
bler code which may even cause Unix assemblers to
crash.

This macro need not be defined if there is no work
for it to do.

TARGET_FLOAT_FORMAT
A code distinguishing the floating point format of
the target machine. There are three defined
values:

IEEE_FLOAT_FORMAT
This code indicates IEEE floating point. It
is the default; there is no need to define













this macro when the format is IEEE.

VAX_FLOAT_FORMAT
This code indicates the peculiar format used
on the Vax.

UNKNOWN_FLOAT_FORMAT
This code indicates any other format.


The value of this macro is compared with
HOST_FLOAT_FORMAT (see section Config) to deter-
mine whether the target machine has the same for-
mat as the host machine. If any other formats are
actually in use on supported machines, new codes
should be defined for them.


1.4. Layout of Source Language Data Types

These macros define the sizes and other characteristics
of the standard basic data types used in programs being com-
piled. Unlike the macros in the previous section, these
apply to specific features of C and related languages,
rather than to fundamental aspects of storage layout.

INT_TYPE_SIZE
A C expression for the size in bits of the type
int on the target machine. If you don't define
this, the default is one word.

SHORT_TYPE_SIZE
A C expression for the size in bits of the type
short on the target machine. If you don't define
this, the default is half a word. (If this would
be less than one storage unit, it is rounded up to
one unit.)

LONG_TYPE_SIZE
A C expression for the size in bits of the type
long on the target machine. If you don't define
this, the default is one word.

LONG_LONG_TYPE_SIZE
A C expression for the size in bits of the type
long long on the target machine. If you don't de-
fine this, the default is two words.

CHAR_TYPE_SIZE
A C expression for the size in bits of the type
char on the target machine. If you don't define
this, the default is one quarter of a word. (If
this would be less than one storage unit, it is













rounded up to one unit.)

FLOAT_TYPE_SIZE
A C expression for the size in bits of the type
float on the target machine. If you don't define
this, the default is one word.

DOUBLE_TYPE_SIZE
A C expression for the size in bits of the type
double on the target machine. If you don't define
this, the default is two words.

LONG_DOUBLE_TYPE_SIZE
A C expression for the size in bits of the type
long double on the target machine. If you don't
define this, the default is two words.

DEFAULT_SIGNED_CHAR
An expression whose value is 1 or 0, according to
whether the type char should be signed or unsigned
by default. The user can always override this de-
fault with the options `-fsigned-char' and `-
funsigned-char'.

DEFAULT_SHORT_ENUMS
A C expression to determine whether to give an
enum type only as many bytes as it takes to
represent the range of possible values of that
type. A nonzero value means to do that; a zero
value means all enum types should be allocated
like int.

If you don't define the macro, the default is 0.

SIZE_TYPE
A C expression for a string describing the name of
the data type to use for size values. The typedef
name size_t is defined using the contents of the
string.

The string can contain more than one keyword. If
so, separate them with spaces, and write first any
length keyword, then unsigned if appropriate, and
finally int. The string must exactly match one of
the data type names defined in the function
init_decl_processing in the file `c-decl.c'. You
may not omit int or change the order---that would
cause the compiler to crash on startup.

If you don't define this macro, the default is
"long unsigned int".















PTRDIFF_TYPE
A C expression for a string describing the name of
the data type to use for the result of subtracting
two pointers. The typedef name ptrdiff_t is de-
fined using the contents of the string. See
SIZE_TYPE above for more information.

If you don't define this macro, the default is
"long int".

WCHAR_TYPE
A C expression for a string describing the name of
the data type to use for wide characters. The
typedef name wchar_t is defined using the contents
of the string. See SIZE_TYPE above for more in-
formation.

If you don't define this macro, the default is
"int".

WCHAR_TYPE_SIZE
A C expression for the size in bits of the data
type for wide characters. This is used in cpp,
which cannot make use of WCHAR_TYPE.

OBJC_INT_SELECTORS
Define this macro if the type of Objective C
selectors should be int.

If this macro is not defined, then selectors
should have the type struct objc_selector *.

OBJC_NONUNIQUE_SELECTORS
Define this macro if Objective C selector-
references will be made unique by the linker (this
is the default). In this case, each selector-
reference will be given a separate assembler la-
bel. Otherwise, the selector-references will be
gathered into an array with a single assembler la-
bel.

MULTIBYTE_CHARS
Define this macro to enable support for multibyte
characters in the input to GNU CC. This requires
that the host system support the ANSI C library
functions for converting multibyte characters to
wide characters.

TARGET_BELL
A C constant expression for the integer value for
escape sequence `\a'.















TARGET_BS

TARGET_TAB

TARGET_NEWLINE
C constant expressions for the integer values for
escape sequences `\b', `\t' and `\n'.

TARGET_VT

TARGET_FF

TARGET_CR
C constant expressions for the integer values for
escape sequences `\v', `\f' and `\r'.


1.5. Register Usage

This section explains how to describe what registers
the target machine has, and how (in general) they can be
used.

The description of which registers a specific instruc-
tion can use is done with register classes; see `Register
Classes'. For information on using registers to access a
stack frame, see `Frame Registers'. For passing values in
registers, see `Register Arguments'. For returning values
in registers, see `Scalar Return'.

1.5.1. Basic Characteristics of Registers

FIRST_PSEUDO_REGISTER
Number of hardware registers known to the com-
piler. They receive numbers 0 through
FIRST_PSEUDO_REGISTER-1; thus, the first pseudo
register's number really is assigned the number
FIRST_PSEUDO_REGISTER.

FIXED_REGISTERS
An initializer that says which registers are used
for fixed purposes all throughout the compiled
code and are therefore not available for general
allocation. These would include the stack
pointer, the frame pointer (except on machines
where that can be used as a general register when
no frame pointer is needed), the program counter
on machines where that is considered one of the
addressable registers, and any other numbered re-
gister with a standard use.

This information is expressed as a sequence of
numbers, separated by commas and surrounded by













braces. The nth number is 1 if register n is
fixed, 0 otherwise.

The table initialized from this macro, and the
table initialized by the following one, may be
overridden at run time either automatically, by
the actions of the macro
CONDITIONAL_REGISTER_USAGE, or by the user with
the command options `-ffixed-reg', `-fcall-used-
reg' and `-fcall-saved-reg'.

CALL_USED_REGISTERS
Like FIXED_REGISTERS but has 1 for each register
that is clobbered (in general) by function calls
as well as for fixed registers. This macro there-
fore identifies the registers that are not avail-
able for general allocation of values that must
live across function calls.

If a register has 0 in CALL_USED_REGISTERS, the
compiler automatically saves it on function entry
and restores it on function exit, if the register
is used within the function.

CONDITIONAL_REGISTER_USAGE
Zero or more C statements that may conditionally
modify two variables fixed_regs and call_used_regs
(both of type char []) after they have been ini-
tialized from the two preceding macros.

This is necessary in case the fixed or call-
clobbered registers depend on target flags.

You need not define this macro if it has no work
to do.

If the usage of an entire class of registers
depends on the target flags, you may indicate this
to GCC by using this macro to modify fixed_regs
and call_used_regs to 1 for each of the registers
in the classes which should not be used by GCC.
Also define the macro REG_CLASS_FROM_LETTER to re-
turn NO_REGS if it is called with a letter for a
class that shouldn't be used.

(However, if this class is not included in
GENERAL_REGS and all of the insn patterns whose
constraints permit this class are controlled by
target switches, then GCC will automatically avoid
using these registers when the target switches are
opposed to them.)















NON_SAVING_SETJMP
If this macro is defined and has a nonzero value,
it means that setjmp and related functions fail to
save the registers, or that longjmp fails to re-
store them. To compensate, the compiler avoids
putting variables in registers in functions that
use setjmp.

1.5.2. Order of Allocation of Registers

REG_ALLOC_ORDER
If defined, an initializer for a vector of in-
tegers, containing the numbers of hard registers
in the order in which GNU CC should prefer to use
them (from most preferred to least).

If this macro is not defined, registers are used
lowest numbered first (all else being equal).

One use of this macro is on machines where the
highest numbered registers must always be saved
and the save-multiple-registers instruction sup-
ports only sequences of consecutive registers. On
such machines, define REG_ALLOC_ORDER to be an in-
itializer that lists the highest numbered allocat-
able register first.

ORDER_REGS_FOR_LOCAL_ALLOC
A C statement (sans semicolon) to choose the order
in which to allocate hard registers for pseudo-
registers local to a basic block.

Store the desired order of registers in the array
reg_alloc_order. Element 0 should be the register
to allocate first; element 1, the next register;
and so on.

The macro body should not assume anything about
the contents of reg_alloc_order before execution
of the macro.

On most machines, it is not necessary to define
this macro.


1.5.3. How Values Fit in Registers

This section discusses the macros that describe which
kinds of values (specifically, which machine modes) each
register can hold, and how many consecutive registers are
needed for a given mode.















HARD_REGNO_NREGS (regno, mode)
A C expression for the number of consecutive hard
registers, starting at register number regno, re-
quired to hold a value of mode mode.

On a machine where all registers are exactly one
word, a suitable definition of this macro is


#define HARD_REGNO_NREGS(REGNO, MODE) \
((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1) \
/ UNITS_PER_WORD))



HARD_REGNO_MODE_OK (regno, mode)
A C expression that is nonzero if it is per-
missible to store a value of mode mode in hard
register number regno (or in several registers
starting with that one). For a machine where
all registers are equivalent, a suitable de-
finition is


#define HARD_REGNO_MODE_OK(REGNO, MODE) 1



It is not necessary for this macro to check
for the numbers of fixed registers, because
the allocation mechanism considers them to be
always occupied.

On some machines, double-precision values must
be kept in even/odd register pairs. The way
to implement that is to define this macro to
reject odd register numbers for such modes.



The minimum requirement for a mode to be OK in
a register is that the `movmode' instruction
pattern support moves between the register and
any other hard register for which the mode is
OK; and that moving a value into the register
and back out not alter it.

Since the same instruction used to move SImode
will work for all narrower integer modes, it
is not necessary on any machine for
HARD_REGNO_MODE_OK to distinguish between
these modes, provided you define patterns
`movhi', etc., to take advantage of this.













This is useful because of the interaction
between HARD_REGNO_MODE_OK and
MODES_TIEABLE_P; it is very desirable for all
integer modes to be tieable.

Many machines have special registers for
floating point arithmetic. Often people as-
sume that floating point machine modes are al-
lowed only in floating point registers. This
is not true. Any registers that can hold in-
tegers can safely hold a floating point
machine mode, whether or not floating arith-
metic can be done on it in those registers.
Integer move instructions can be used to move
the values.

On some machines, though, the converse is
true: fixed-point machine modes may not go in
floating registers. This is true if the
floating registers normalize any value stored
in them, because storing a non-floating value
there would garble it. In this case,
HARD_REGNO_MODE_OK should reject fixed-point
machine modes in floating registers. But if
the floating registers do not automatically
normalize, if you can store any bit pattern in
one and retrieve it unchanged without a trap,
then any machine mode may go in a floating re-
gister and this macro should say so.

The primary significance of special floating
registers is rather that they are the regis-
ters acceptable in floating point arithmetic
instructions. However, this is of no concern
to HARD_REGNO_MODE_OK. You handle it by writ-
ing the proper constraints for those instruc-
tions.

On some machines, the floating registers are
especially slow to access, so that it is
better to store a value in a stack frame than
in such a register if floating point arithmet-
ic is not being done. As long as the floating
registers are not in class GENERAL_REGS, they
will not be used unless some pattern's con-
straint asks for one.

MODES_TIEABLE_P (mode1, mode2)
A C expression that is nonzero if it is desir-
able to choose register allocation so as to
avoid move instructions between a value of
mode mode1 and a value of mode mode2.














If HARD_REGNO_MODE_OK (r, mode1) and
HARD_REGNO_MODE_OK (r, mode2) are ever dif-
ferent for any r, then MODES_TIEABLE_P (mode1,
mode2) must be zero.


1.5.4. Handling Leaf Functions

On some machines, a leaf function (i.e., one which make
no calls) can run more efficiently if it does not make its
own register window. Often this means it is required to
receive its arguments in the registers where they are passed
by the caller, instead of the registers where they would
normally arrive. Also, the leaf function may use only those
registers for its own variables and temporaries.

GNU CC assigns register numbers before it knows whether
the function is suitable for leaf function treatment. So it
needs to renumber the registers in order to output a leaf
function. The following macros accomplish this.

LEAF_REGISTERS
A C initializer for a vector, indexed by hard re-
gister number, which contains 1 for a register
that is allowable in a candidate for leaf function
treatment.

If leaf function treatment involves renumbering
the registers, then the registers marked here
should be the ones before renumbering---those that
GNU CC would ordinarily allocate. The registers
which will actually be used in the assembler code,
after renumbering, should not be marked with 1 in
this vector.

Define this macro only if the target machine
offers a way to optimize the treatment of leaf
functions.

LEAF_REG_REMAP (regno)
A C expression whose value is the register number
to which regno should be renumbered, when a func-
tion is treated as a leaf function.

If regno is a register number which should not ap-
pear in a leaf function before renumbering, then
the expression should yield -1, which will cause
the compiler to abort.

Define this macro only if the target machine
offers a way to optimize the treatment of leaf
functions, and registers need to be renumbered to
do this.













REG_LEAF_ALLOC_ORDER
If defined, an initializer for a vector of in-
tegers, containing the numbers of hard registers
in the order in which the GNU CC should prefer to
use them (from most preferred to least) in a leaf
function. If this macro is not defined,
REG_ALLOC_ORDER is used for both non-leaf and
leaf-functions.


Normally, it is necessary for FUNCTION_PROLOGUE and
FUNCTION_EPILOGUE to treat leaf functions specially. The C
variable leaf_function is nonzero for such a function.

1.5.5. Registers That Form a Stack

There are special features to handle computers where
some of the ``registers'' form a stack, as in the 80387
coprocessor for the 80386. Stack registers are normally
written by pushing onto the stack, and are numbered relative
to the top of the stack.

Currently, GNU CC can only handle one group of stack-
like registers, and they must be consecutively numbered.

STACK_REGS
Define this if the machine has any stack-like re-
gisters.

FIRST_STACK_REG
The number of the first stack-like register. This
one is the top of the stack.

LAST_STACK_REG
The number of the last stack-like register. This
one is the bottom of the stack.


1.5.6. Obsolete Macros for Controlling Register Usage

These features do not work very well. They exist
because they used to be required to generate correct code
for the 80387 coprocessor of the 80386. They are no longer
used by that machine description and may be removed in a
later version of the compiler. Don't use them!

OVERLAPPING_REGNO_P (regno)
If defined, this is a C expression whose value is
nonzero if hard register number regno is an over-
lapping register. This means a hard register
which overlaps a hard register with a different
number. (Such overlap is undesirable, but occa-
sionally it allows a machine to be supported which













otherwise could not be.) This macro must return
nonzero for all the registers which overlap each
other. GNU CC can use an overlapping register
only in certain limited ways. It can be used for
allocation within a basic block, and may be
spilled for reloading; that is all.

If this macro is not defined, it means that none
of the hard registers overlap each other. This is
the usual situation.

INSN_CLOBBERS_REGNO_P (insn, regno)
If defined, this is a C expression whose value
should be nonzero if the insn insn has the effect
of mysteriously clobbering the contents of hard
register number regno. By ``mysterious'' we mean
that the insn's RTL expression doesn't describe
such an effect.

If this macro is not defined, it means that no
insn clobbers registers mysteriously. This is the
usual situation; all else being equal, it is best
for the RTL expression to show all the activity.

PRESERVE_DEATH_INFO_REGNO_P (regno)
If defined, this is a C expression whose value is
nonzero if accurate REG_DEAD notes are needed for
hard register number regno at the time of output-
ting the assembler code. When this is so, a few
optimizations that take place after register allo-
cation and could invalidate the death notes are
not done when this register is involved.

You would arrange to preserve death info for a re-
gister when some of the code in the machine
description which is executed to write the assem-
bler code looks at the death notes. This is
necessary only when the actual hardware feature
which GNU CC thinks of as a register is not actu-
ally a register of the usual sort. (It might, for
example, be a hardware stack.)

If this macro is not defined, it means that no
death notes need to be preserved. This is the
usual situation.


1.6. Register Classes

On many machines, the numbered registers are not all
equivalent. For example, certain registers may not be
allowed for indexed addressing; certain registers may not be
allowed in some instructions. These machine restrictions













are described to the compiler using register classes.

You define a number of register classes, giving each
one a name and saying which of the registers belong to it.
Then you can specify register classes that are allowed as
operands to particular instruction patterns.

In general, each register will belong to several
classes. In fact, one class must be named ALL_REGS and con-
tain all the registers. Another class must be named NO_REGS
and contain no registers. Often the union of two classes
will be another class; however, this is not required.

One of the classes must be named GENERAL_REGS. There
is nothing terribly special about the name, but the operand
constraint letters `r' and `g' specify this class. If
GENERAL_REGS is the same as ALL_REGS, just define it as a
macro which expands to ALL_REGS.

Order the classes so that if class x is contained in
class y then x has a lower class number than y.

The way classes other than GENERAL_REGS are specified
in operand constraints is through machine-dependent operand
constraint letters. You can define such letters to
correspond to various classes, then use them in operand con-
straints.

You should define a class for the union of two classes
whenever some instruction allows both classes. For example,
if an instruction allows either a floating point (coproces-
sor) register or a general register for a certain operand,
you should define a class FLOAT_OR_GENERAL_REGS which
includes both of them. Otherwise you will get suboptimal
code.

You must also specify certain redundant information
about the register classes: for each class, which classes
contain it and which ones are contained in it; for each pair
of classes, the largest class contained in their union.

When a value occupying several consecutive registers is
expected in a certain class, all the registers used must
belong to that class. Therefore, register classes cannot be
used to enforce a requirement for a register pair to start
with an even-numbered register. The way to specify this
requirement is with HARD_REGNO_MODE_OK.

Register classes used for input-operands of bitwise-and
or shift instructions have a special requirement: each such
class must have, for each fixed-point machine mode, a sub-
class whose registers can transfer that mode to or from
memory. For example, on some machines, the operations for













single-byte values (QImode) are limited to certain regis-
ters. When this is so, each register class that is used in
a bitwise-and or shift instruction must have a subclass con-
sisting of registers from which single-byte values can be
loaded or stored. This is so that PREFERRED_RELOAD_CLASS
can always have a possible value to return.

enum reg_class
An enumeral type that must be defined with all the
register class names as enumeral values. NO_REGS
must be first. ALL_REGS must be the last register
class, followed by one more enumeral value,
LIM_REG_CLASSES, which is not a register class but
rather tells how many classes there are.

Each register class has a number, which is the
value of casting the class name to type int. The
number serves as an index in many of the tables
described below.

N_REG_CLASSES
The number of distinct register classes, defined
as follows:


#define N_REG_CLASSES (int) LIM_REG_CLASSES



REG_CLASS_NAMES
An initializer containing the names of the re-
gister classes as C string constants. These
names are used in writing some of the debug-
ging dumps.

REG_CLASS_CONTENTS
An initializer containing the contents of the
register classes, as integers which are bit
masks. The nth integer specifies the contents
of class n. The way the integer mask is in-
terpreted is that register r is in the class
if mask & (1 << r) is 1.

When the machine has more than 32 registers,
an integer does not suffice. Then the in-
tegers are replaced by sub-initializers,
braced groupings containing several integers.
Each sub-initializer must be suitable as an
initializer for the type HARD_REG_SET which is
defined in `hard-reg-set.h'.

REGNO_REG_CLASS (regno)
A C expression whose value is a register class













containing hard register regno. In general
there is more that one such class; choose a
class which is minimal, meaning that no small-
er class also contains the register.

BASE_REG_CLASS
A macro whose definition is the name of the
class to which a valid base register must be-
long. A base register is one used in an ad-
dress which is the register value plus a dis-
placement.

INDEX_REG_CLASS
A macro whose definition is the name of the
class to which a valid index register must be-
long. An index register is one used in an ad-
dress where its value is either multiplied by
a scale factor or added to another register
(as well as added to a displacement).

REG_CLASS_FROM_LETTER (char)
A C expression which defines the machine-
dependent operand constraint letters for re-
gister classes. If char is such a letter, the
value should be the register class correspond-
ing to it. Otherwise, the value should be
NO_REGS.

REGNO_OK_FOR_BASE_P (num)
A C expression which is nonzero if register
number num is suitable for use as a base re-
gister in operand addresses. It may be either
a suitable hard register or a pseudo register
that has been allocated such a hard register.

REGNO_OK_FOR_INDEX_P (num)
A C expression which is nonzero if register
number num is suitable for use as an index re-
gister in operand addresses. It may be either
a suitable hard register or a pseudo register
that has been allocated such a hard register.

The difference between an index register and a
base register is that the index register may
be scaled. If an address involves the sum of
two registers, neither one of them scaled,
then either one may be labeled the ``base''
and the other the ``index''; but whichever la-
beling is used must fit the machine's con-
straints of which registers may serve in each
capacity. The compiler will try both label-
ings, looking for one that is valid, and will
reload one or both registers only if neither













labeling works.

PREFERRED_RELOAD_CLASS (x, class)
A C expression that places additional restric-
tions on the register class to use when it is
necessary to copy value x into a register in
class class. The value is a register class;
perhaps class, or perhaps another, smaller
class. On many machines, the definition


#define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS



is safe.

Sometimes returning a more restrictive class
makes better code. For example, on the 68000,
when x is an integer constant that is in range
for a `moveq' instruction, the value of this
macro is always DATA_REGS as long as class in-
cludes the data registers. Requiring a data
register guarantees that a `moveq' will be
used.

If x is a const_double, by returning NO_REGS
you can force x into a memory constant. This
is useful on certain machines where immediate
floating values cannot be loaded into certain
kinds of registers.

LIMIT_RELOAD_CLASS (mode, class)
A C expression that places additional restric-
tions on the register class to use when it is
necessary to be able to hold a value of mode
mode in a reload register for which class
class would ordinarily be used.

Unlike PREFERRED_RELOAD_CLASS, this macro
should be used when there are certain modes
that simply can't go in certain reload
classes.

The value is a register class; perhaps class,
or perhaps another, smaller class.

Don't define this macro unless the target
machine has limitations which require the mac-
ro to do something nontrivial.

SECONDARY_RELOAD_CLASS (class, mode, x)














SECONDARY_INPUT_RELOAD_CLASS (class, mode, x)

SECONDARY_OUTPUT_RELOAD_CLASS (class, mode, x)
Many machines have some registers that cannot
be copied directly to or from memory or even
from other types of registers. An example is
the `MQ' register, which on most machines, can
only be copied to or from general registers,
but not memory. Some machines allow copying
all registers to and from memory, but require
a scratch register for stores to some memory
locations (e.g., those with symbolic address
on the RT, and those with certain symbolic ad-
dress on the Sparc when compiling PIC). In
some cases, both an intermediate and a scratch
register are required.

You should define these macros to indicate to
the reload phase that it may need to allocate
at least one register for a reload in addition
to the register to contain the data. Specifi-
cally, if copying x to a register class in
mode requires an intermediate register, you
should define SECONDARY_INPUT_RELOAD_CLASS to
return the largest register class all of whose
registers can be used as intermediate regis-
ters or scratch registers.

If copying a register class in mode to x re-
quires an intermediate or scratch register,
you should define
SECONDARY_OUTPUT_RELOAD_CLASS to return the
largest register class required. If the re-
quirements for input and output reloads are
the same, the macro SECONDARY_RELOAD_CLASS
should be used instead of defining both macros
identically.

The values returned by these macros are often
GENERAL_REGS. Return NO_REGS if no spare re-
gister is needed; i.e., if x can be directly
copied to or from a register of class in mode
without requiring a scratch register. Do not
define this macro if it would always return
NO_REGS.

If a scratch register is required (either with
or without an intermediate register), you
should define patterns for `reload_inm' or
`reload_outm', as required (see section Stan-
dard Names. These patterns, which will nor-
mally be implemented with a define_expand,
should be similar to the `movm' patterns, ex-













cept that operand 2 is the scratch register.

Define constraints for the reload register and
scratch register that contain a single regis-
ter class. If the original reload register
(whose class is class) can meet the constraint
given in the pattern, the value returned by
these macros is used for the class of the
scratch register. Otherwise, two additional
reload registers are required. Their classes
are obtained from the constraints in the insn
pattern.

x might be a pseudo-register or a subreg of a
pseudo-register, which could either be in a
hard register or in memory. Use true_regnum
to find out; it will return -1 if the pseudo
is in memory and the hard register number if
it is in a register.

These macros should not be used in the case
where a particular class of registers can only
be copied to memory and not to another class
of registers. In that case, secondary reload
registers are not needed and would not be
helpful. Instead, a stack location must be
used to perform the copy and the movm pattern
should use memory as a intermediate storage.
This case often occurs between floating-point
and general registers.

SMALL_REGISTER_CLASSES
Normally the compiler will avoid choosing
spill registers from registers that have been
explicitly mentioned in the rtl (these regis-
ters are normally those used to pass parame-
ters and return values). However, some
machines have so few registers of certain
classes that there would not be enough regis-
ters to use as spill registers if this were
done.

On those machines, you should define
SMALL_REGISTER_CLASSES. When it is defined,
the compiler allows registers explicitly used
in the rtl to be used as spill registers but
prevents the compiler from extending the life-
time of these registers.

Defining this macro is always safe, but un-
necessarily defining this macro will reduce
the amount of optimizations that can be per-
formed in some cases. If this macro is not













defined but needs to be, the compiler will run
out of reload registers and print a fatal er-
ror message.

For most machines, this macro should not be
defined.

CLASS_MAX_NREGS (class, mode)
A C expression for the maximum number of con-
secutive registers of class class needed to
hold a value of mode mode.

This is closely related to the macro
HARD_REGNO_NREGS. In fact, the value of the
macro CLASS_MAX_NREGS (class, mode) should be
the maximum value of HARD_REGNO_NREGS (regno,
mode) for all regno values in the class class.

This macro helps control the handling of
multiple-word values in the reload pass.


Three other special macros describe which operands fit
which constraint letters.

CONST_OK_FOR_LETTER_P (value, c)
A C expression that defines the machine-dependent
operand constraint letters that specify particular
ranges of integer values. If c is one of those
letters, the expression should check that value,
an integer, is in the appropriate range and return
1 if so, 0 otherwise. If c is not one of those
letters, the value should be 0 regardless of
value.

CONST_DOUBLE_OK_FOR_LETTER_P (value, c)
A C expression that defines the machine-dependent
operand constraint letters that specify particular
ranges of const_double values.

If c is one of those letters, the expression
should check that value, an RTX of code
const_double, is in the appropriate range and re-
turn 1 if so, 0 otherwise. If c is not one of
those letters, the value should be 0 regardless of
value.

const_double is used for all floating-point con-
stants and for DImode fixed-point constants. A
given letter can accept either or both kinds of
values. It can use GET_MODE to distinguish
between these kinds.














EXTRA_CONSTRAINT (value, c)
A C expression that defines the optional machine-
dependent constraint letters that can be used to
segregate specific types of operands, usually
memory references, for the target machine. Nor-
mally this macro will not be defined. If it is
required for a particular target machine, it
should return 1 if value corresponds to the
operand type represented by the constraint letter
c. If c is not defined as an extra constraint,
the value returned should be 0 regardless of
value.

For example, on the ROMP, load instructions cannot
have their output in r0 if the memory reference
contains a symbolic address. Constraint letter
`Q' is defined as representing a memory address
that does not contain a symbolic address. An al-
ternative is specified with a `Q' constraint on
the input and `r' on the output. The next alter-
native specifies `m' on the input and a register
class that does not include r0 on the output.


1.7. Describing Stack Layout and Calling Conventions

1.7.1. Basic Stack Layout

STACK_GROWS_DOWNWARD
Define this macro if pushing a word onto the stack
moves the stack pointer to a smaller address.

When we say, ``define this macro if ...,'' it
means that the compiler checks this macro only
with #ifdef so the precise definition used does
not matter.

FRAME_GROWS_DOWNWARD
Define this macro if the addresses of local vari-
able slots are at negative offsets from the frame
pointer.

ARGS_GROW_DOWNWARD
Define this macro if successive arguments to a
function occupy decreasing addresses on the stack.

STARTING_FRAME_OFFSET
Offset from the frame pointer to the first local
variable slot to be allocated.

If FRAME_GROWS_DOWNWARD, the next slot's offset is
found by subtracting the length of the first slot
from STARTING_FRAME_OFFSET. Otherwise, it is













found by adding the length of the first slot to
the value STARTING_FRAME_OFFSET.

STACK_POINTER_OFFSET
Offset from the stack pointer register to the
first location at which outgoing arguments are
placed. If not specified, the default value of
zero is used. This is the proper value for most
machines.

If ARGS_GROW_DOWNWARD, this is the offset to the
location above the first location at which outgo-
ing arguments are placed.

FIRST_PARM_OFFSET (fundecl)
Offset from the argument pointer register to the
first argument's address. On some machines it may
depend on the data type of the function.

If ARGS_GROW_DOWNWARD, this is the offset to the
location above the first argument's address.

STACK_DYNAMIC_OFFSET (fundecl)
Offset from the stack pointer register to an item
dynamically allocated on the stack, e.g., by allo-
ca.

The default value for this macro is
STACK_POINTER_OFFSET plus the length of the outgo-
ing arguments. The default is correct for most
machines. See `function.c' for details.

DYNAMIC_CHAIN_ADDRESS (frameaddr)
A C expression whose value is RTL representing the
address in a stack frame where the pointer to the
caller's frame is stored. Assume that frameaddr
is an RTL expression for the address of the stack
frame itself.

If you don't define this macro, the default is to
return the value of frameaddr---that is, the stack
frame address is also the address of the stack
word that points to the previous frame.


1.7.2. Registers That Address the Stack Frame

STACK_POINTER_REGNUM
The register number of the stack pointer register,
which must also be a fixed register according to
FIXED_REGISTERS. On most machines, the hardware
determines which register this is.














FRAME_POINTER_REGNUM
The register number of the frame pointer register,
which is used to access automatic variables in the
stack frame. On some machines, the hardware
determines which register this is. On other
machines, you can choose any register you wish for
this purpose.

ARG_POINTER_REGNUM
The register number of the arg pointer register,
which is used to access the function's argument
list. On some machines, this is the same as the
frame pointer register. On some machines, the
hardware determines which register this is. On
other machines, you can choose any register you
wish for this purpose. If this is not the same
register as the frame pointer register, then you
must mark it as a fixed register according to
FIXED_REGISTERS, or arrange to be able to elim-
inate it (see section Elimination).

STATIC_CHAIN_REGNUM

STATIC_CHAIN_INCOMING_REGNUM
Register numbers used for passing a function's
static chain pointer. If register windows are
used, STATIC_CHAIN_INCOMING_REGNUM is the register
number as seen by the called function, while
STATIC_CHAIN_REGNUM is the register number as seen
by the calling function. If these registers are
the same, STATIC_CHAIN_INCOMING_REGNUM need not be
defined.

The static chain register need not be a fixed re-
gister.

If the static chain is passed in memory, these
macros should not be defined; instead, the next
two macros should be defined.

STATIC_CHAIN

STATIC_CHAIN_INCOMING
If the static chain is passed in memory, these
macros provide rtx giving mem expressions that
denote where they are stored. STATIC_CHAIN and
STATIC_CHAIN_INCOMING give the locations as seen
by the calling and called functions, respectively.
Often the former will be at an offset from the
stack pointer and the latter at an offset from the
frame pointer.















The variables stack_pointer_rtx,
frame_pointer_rtx, and arg_pointer_rtx will have
been initialized prior to the use of these macros
and should be used to refer to those items.

If the static chain is passed in a register, the
two previous macros should be defined instead.


1.7.3. Eliminating Frame Pointer and Arg Pointer

FRAME_POINTER_REQUIRED
A C expression which is nonzero if a function must
have and use a frame pointer. This expression is
evaluated in the reload pass. If its value is
nonzero the function will have a frame pointer.

The expression can in principle examine the
current function and decide according to the
facts, but on most machines the constant 0 or the
constant 1 suffices. Use 0 when the machine al-
lows code to be generated with no frame pointer,
and doing so saves some time or space. Use 1 when
there is no possible advantage to avoiding a frame
pointer.

In certain cases, the compiler does not know how
to produce valid code without a frame pointer.
The compiler recognizes those cases and automati-
cally gives the function a frame pointer regard-
less of what FRAME_POINTER_REQUIRED says. You
don't need to worry about them.

In a function that does not require a frame
pointer, the frame pointer register can be allo-
cated for ordinary usage, unless you mark it as a
fixed register. See FIXED_REGISTERS for more in-
formation.

This macro is ignored and need not be defined if
ELIMINABLE_REGS is defined.

INITIAL_FRAME_POINTER_OFFSET (depth-var)
A C statement to store in the variable depth-var
the difference between the frame pointer and the
stack pointer values immediately after the func-
tion prologue. The value would be computed from
information such as the result of get_frame_size
() and the tables of registers regs_ever_live and
call_used_regs.

If ELIMINABLE_REGS is defined, this macro will be
not be used and need not be defined. Otherwise,













it must be defined even if FRAME_POINTER_REQUIRED
is defined to always be true; in that case, you
may set depth-var to anything.

ELIMINABLE_REGS
If defined, this macro specifies a table of regis-
ter pairs used to eliminate unneeded registers
that point into the stack frame. If it is not de-
fined, the only elimination attempted by the com-
piler is to replace references to the frame
pointer with references to the stack pointer.

The definition of this macro is a list of struc-
ture initializations, each of which specifies an
original and replacement register.

On some machines, the position of the argument
pointer is not known until the compilation is com-
pleted. In such a case, a separate hard register
must be used for the argument pointer. This re-
gister can be eliminated by replacing it with ei-
ther the frame pointer or the argument pointer,
depending on whether or not the frame pointer has
been eliminated.

In this case, you might specify:


#define ELIMINABLE_REGS \
{{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
{ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
{FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}



Note that the elimination of the argument
pointer with the stack pointer is specified
first since that is the preferred elimination.

CAN_ELIMINATE (from-reg, to-reg)
A C expression that returns non-zero if the
compiler is allowed to try to replace register
number from-reg with register number to-reg.
This macro need only be defined if
ELIMINABLE_REGS is defined, and will usually
be the constant 1, since most of the cases
preventing register elimination are things
that the compiler already knows about.

INITIAL_ELIMINATION_OFFSET (from-reg, to-
reg, offset-var)
This macro is similar to
INITIAL_FRAME_POINTER_OFFSET. It specifies













the initial difference between the specified
pair of registers. This macro must be defined
if ELIMINABLE_REGS is defined.

LONGJMP_RESTORE_FROM_STACK
Define this macro if the longjmp function re-
stores registers from the stack frames, rather
than from those saved specifically by setjmp.
Certain quantities must not be kept in regis-
ters across a call to setjmp on such machines.


1.7.4. Passing Function Arguments on the Stack

The macros in this section control how arguments are
passed on the stack. See the following section for other
macros that control passing certain arguments in registers.

PROMOTE_PROTOTYPES
Define this macro if an argument declared as char
or short in a prototype should actually be passed
as an int. In addition to avoiding errors in cer-
tain cases of mismatch, it also makes for better
code on certain machines.

PUSH_ROUNDING (npushed)
A C expression that is the number of bytes actual-
ly pushed onto the stack when an instruction at-
tempts to push npushed bytes.

If the target machine does not have a push in-
struction, do not define this macro. That directs
GNU CC to use an alternate strategy: to allocate
the entire argument block and then store the argu-
ments into it.

On some machines, the definition


#define PUSH_ROUNDING(BYTES) (BYTES)



will suffice. But on other machines, instructions
that appear to push one byte actually push two
bytes in an attempt to maintain alignment. Then
the definition should be


#define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
















ACCUMULATE_OUTGOING_ARGS
If defined, the maximum amount of space re-
quired for outgoing arguments will be computed
and placed into the variable
current_function_outgoing_args_size. No space
will be pushed onto the stack for each call;
instead, the function prologue should increase
the stack frame size by this amount.

It is not proper to define both PUSH_ROUNDING
and ACCUMULATE_OUTGOING_ARGS.

REG_PARM_STACK_SPACE
Define this macro if functions should assume
that stack space has been allocated for argu-
ments even when their values are passed in re-
gisters.

The value of this macro is the size, in bytes,
of the area reserved for arguments passed in
registers.

This space can either be allocated by the
caller or be a part of the machine-dependent
stack frame: OUTGOING_REG_PARM_STACK_SPACE
says which.

OUTGOING_REG_PARM_STACK_SPACE
Define this if it is the responsibility of the
caller to allocate the area reserved for argu-
ments passed in registers.

If ACCUMULATE_OUTGOING_ARGS is defined, this
macro controls whether the space for these ar-
guments counts in the value of
current_function_outgoing_args_size.

STACK_PARMS_IN_REG_PARM_AREA
Define this macro if REG_PARM_STACK_SPACE is
defined but stack parameters don't skip the
area specified by REG_PARM_STACK_SPACE.

Normally, when a parameter is not passed in
registers, it is placed on the stack beyond
the REG_PARM_STACK_SPACE area. Defining this
macro suppresses this behavior and causes the
parameter to be passed on the stack in its na-
tural location.

RETURN_POPS_ARGS (funtype, stack-size)
A C expression that should indicate the number
of bytes of its own arguments that a function
pops on returning, or 0 if the function pops













no arguments and the caller must therefore pop
them all after the function returns.

funtype is a C variable whose value is a tree
node that describes the function in question.
Normally it is a node of type FUNCTION_TYPE
that describes the data type of the function.
From this it is possible to obtain the data
types of the value and arguments (if known).

When a call to a library function is being
considered, funtype will contain an identifier
node for the library function. Thus, if you
need to distinguish among various library
functions, you can do so by their names. Note
that ``library function'' in this context
means a function used to perform arithmetic,
whose name is known specially in the compiler
and was not mentioned in the C code being com-
piled.

stack-size is the number of bytes of arguments
passed on the stack. If a variable number of
bytes is passed, it is zero, and argument pop-
ping will always be the responsibility of the
calling function.

On the Vax, all functions always pop their ar-
guments, so the definition of this macro is
stack-size. On the 68000, using the standard
calling convention, no functions pop their ar-
guments, so the value of the macro is always 0
in this case. But an alternative calling con-
vention is available in which functions that
take a fixed number of arguments pop them but
other functions (such as printf) pop nothing
(the caller pops all). When this convention
is in use, funtype is examined to determine
whether a function takes a fixed number of ar-
guments.


1.7.5. Passing Arguments in Registers

This section describes the macros which let you control
how various types of arguments are passed in registers or
how they are arranged in the stack.

FUNCTION_ARG (cum, mode, type, named)
A C expression that controls whether a function
argument is passed in a register, and which regis-
ter.














The arguments are cum, which summarizes all the
previous arguments; mode, the machine mode of the
argument; type, the data type of the argument as a
tree node or 0 if that is not known (which happens
for C support library functions); and named, which
is 1 for an ordinary argument and 0 for nameless
arguments that correspond to `...' in the called
function's prototype.

The value of the expression should either be a reg
RTX for the hard register in which to pass the ar-
gument, or zero to pass the argument on the stack.

For machines like the Vax and 68000, where normal-
ly all arguments are pushed, zero suffices as a
definition.

The usual way to make the ANSI library `stdarg.h'
work on a machine where some arguments are usually
passed in registers, is to cause nameless argu-
ments to be passed on the stack instead. This is
done by making FUNCTION_ARG return 0 whenever
named is 0.

You may use the macro MUST_PASS_IN_STACK (mode,
type) in the definition of this macro to determine
if this argument is of a type that must be passed
in the stack. If REG_PARM_STACK_SPACE is not de-
fined and FUNCTION_ARG returns non-zero for such
an argument, the compiler will abort. If
REG_PARM_STACK_SPACE is defined, the argument will
be computed in the stack and then loaded into a
register.

FUNCTION_INCOMING_ARG (cum, mode, type, named)
Define this macro if the target machine has ``re-
gister windows'', so that the register in which a
function sees an arguments is not necessarily the
same as the one in which the caller passed the ar-
gument.

For such machines, FUNCTION_ARG computes the re-
gister in which the caller passes the value, and
FUNCTION_INCOMING_ARG should be defined in a simi-
lar fashion to tell the function being called
where the arguments will arrive.

If FUNCTION_INCOMING_ARG is not defined,
FUNCTION_ARG serves both purposes.

FUNCTION_ARG_PARTIAL_NREGS (cum, mode, type, named)
A C expression for the number of words, at the be-
ginning of an argument, must be put in registers.













The value must be zero for arguments that are
passed entirely in registers or that are entirely
pushed on the stack.

On some machines, certain arguments must be passed
partially in registers and partially in memory.
On these machines, typically the first n words of
arguments are passed in registers, and the rest on
the stack. If a multi-word argument (a double or
a structure) crosses that boundary, its first few
words must be passed in registers and the rest
must be pushed. This macro tells the compiler
when this occurs, and how many of the words should
go in registers.

FUNCTION_ARG for these arguments should return the
first register to be used by the caller for this
argument; likewise FUNCTION_INCOMING_ARG, for the
called function.

FUNCTION_ARG_PASS_BY_REFERENCE (cum, mode, type, named)
A C expression that indicates when an argument
must be passed by reference. If nonzero for an
argument, a copy of that argument is made in
memory and a pointer to the argument is passed in-
stead of the argument itself. The pointer is
passed in whatever way is appropriate for passing
a pointer to that type.

On machines where REG_PARM_STACK_SPACE is not de-
fined, a suitable definition of this macro might
be


#define FUNCTION_ARG_PASS_BY_REFERENCE(CUM, MODE, TYPE, NAMED) \
MUST_PASS_IN_STACK (MODE, TYPE)



CUMULATIVE_ARGS
A C type for declaring a variable that is used
as the first argument of FUNCTION_ARG and oth-
er related values. For some target machines,
the type int suffices and can hold the number
of bytes of argument so far.

There is no need to record in CUMULATIVE_ARGS
anything about the arguments that have been
passed on the stack. The compiler has other
variables to keep track of that. For target
machines on which all arguments are passed on
the stack, there is no need to store anything
in CUMULATIVE_ARGS; however, the data struc-













ture must exist and should not be empty, so
use int.

INIT_CUMULATIVE_ARGS (cum, fntype, libname)
A C statement (sans semicolon) for initializ-
ing the variable cum for the state at the be-
ginning of the argument list. The variable
has type CUMULATIVE_ARGS. The value of fntype
is the tree node for the data type of the
function which will receive the args, or 0 if
the args are to a compiler support library
function.

When processing a call to a compiler support
library function, libname identifies which
one. It is a symbol_ref rtx which contains
the name of the function, as a string. lib-
name is 0 when an ordinary C function call is
being processed. Thus, each time this macro
is called, either libname or fntype is
nonzero, but never both of them at once.

INIT_CUMULATIVE_INCOMING_ARGS (cum, fntype, libname)
Like INIT_CUMULATIVE_ARGS but overrides it for
the purposes of finding the arguments for the
function being compiled. If this macro is un-
defined, INIT_CUMULATIVE_ARGS is used instead.

The argument libname exists for symmetry with
INIT_CUMULATIVE_ARGS. The value passed for
libname is always 0, since library routines
with special calling conventions are never
compiled with GNU CC.

FUNCTION_ARG_ADVANCE (cum, mode, type, named)
A C statement (sans semicolon) to update the
summarizer variable cum to advance past an ar-
gument in the argument list. The values mode,
type and named describe that argument. Once
this is done, the variable cum is suitable for
analyzing the following argument with
FUNCTION_ARG, etc.

This macro need not do anything if the argu-
ment in question was passed on the stack. The
compiler knows how to track the amount of
stack space used for arguments without any
special help.

FUNCTION_ARG_PADDING (mode, type)
If defined, a C expression which determines
whether, and in which direction, to pad out an
argument with extra space. The value should













be of type enum direction: either upward to
pad above the argument, downward to pad below,
or none to inhibit padding.

This macro does not control the amount of pad-
ding; that is always just enough to reach the
next multiple of FUNCTION_ARG_BOUNDARY.

This macro has a default definition which is
right for most systems. For little-endian
machines, the default is to pad upward. For
big-endian machines, the default is to pad
downward for an argument of constant size
shorter than an int, and upward otherwise.

FUNCTION_ARG_BOUNDARY (mode, type)
If defined, a C expression that gives the
alignment boundary, in bits, of an argument
with the specified mode and type. If it is
not defined, PARM_BOUNDARY is used for all ar-
guments.

FUNCTION_ARG_REGNO_P (regno)
A C expression that is nonzero if regno is the
number of a hard register in which function
arguments are sometimes passed. This does not
include implicit arguments such as the static
chain and the structure-value address. On
many machines, no registers can be used for
this purpose since all function arguments are
pushed on the stack.


1.7.6. How Scalar Function Values Are Returned

This section discusses the macros that control return-
ing scalars as values---values that can fit in registers.

TRADITIONAL_RETURN_FLOAT
Define this macro if `-traditional' should not
cause functions declared to return float to con-
vert the value to double.

FUNCTION_VALUE (valtype, func)
A C expression to create an RTX representing the
place where a function returns a value of data
type valtype. valtype is a tree node representing
a data type. Write TYPE_MODE (valtype) to get the
machine mode used to represent that type. On many
machines, only the mode is relevant. (Actually,
on most machines, scalar values are returned in
the same place regardless of mode).














If the precise function being called is known,
func is a tree node (FUNCTION_DECL) for it; other-
wise, func is a null pointer. This makes it pos-
sible to use a different value-returning conven-
tion for specific functions when all their calls
are known.

FUNCTION_VALUE is not used for return vales with
aggregate data types, because these are returned
in another way. See STRUCT_VALUE_REGNUM and re-
lated macros, below.

FUNCTION_OUTGOING_VALUE (valtype, func)
Define this macro if the target machine has ``re-
gister windows'' so that the register in which a
function returns its value is not the same as the
one in which the caller sees the value.

For such machines, FUNCTION_VALUE computes the re-
gister in which the caller will see the value, and
FUNCTION_OUTGOING_VALUE should be defined in a
similar fashion to tell the function where to put
the value.

If FUNCTION_OUTGOING_VALUE is not defined,
FUNCTION_VALUE serves both purposes.

FUNCTION_OUTGOING_VALUE is not used for return
vales with aggregate data types, because these are
returned in another way. See STRUCT_VALUE_REGNUM
and related macros, below.

LIBCALL_VALUE (mode)
A C expression to create an RTX representing the
place where a library function returns a value of
mode mode. If the precise function being called
is known, func is a tree node (FUNCTION_DECL) for
it; otherwise, func is a null pointer. This makes
it possible to use a different value-returning
convention for specific functions when all their
calls are known.

Note that ``library function'' in this context
means a compiler support routine, used to perform
arithmetic, whose name is known specially by the
compiler and was not mentioned in the C code being
compiled.

The definition of LIBRARY_VALUE need not be con-
cerned aggregate data types, because none of the
library functions returns such types.















FUNCTION_VALUE_REGNO_P (regno)
A C expression that is nonzero if regno is the
number of a hard register in which the values of
called function may come back.

A register whose use for returning values is lim-
ited to serving as the second of a pair (for a
value of type double, say) need not be recognized
by this macro. So for most machines, this defini-
tion suffices:


#define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)



If the machine has register windows, so that
the caller and the called function use dif-
ferent registers for the return value, this
macro should recognize only the caller's re-
gister numbers.


1.7.7. How Large Values Are Returnd

When a function value's mode is BLKmode (and in some
other cases), the value is not returned according to
FUNCTION_VALUE (see section Scalar Return). Instead, the
caller passes the address of a block of memory in which the
value should be stored. This address is called the struc-
ture value address.

This section describes how to control returning struc-
ture values in memory.

RETURN_IN_MEMORY (type)
A C expression which can inhibit the returning of
certain function values in registers, based on the
type of value. A nonzero value says to return the
function value in memory, just as large structures
are always returned. Here type will be a C ex-
pression of type tree, representing the data type
of the value.

Note that values of mode BLKmode are returned in
memory regardless of this macro. Also, the option
`-fpcc-struct-return' takes effect regardless of
this macro. On most systems, it is possible to
leave the macro undefined; this causes a default
definition to be used, whose value is the constant
0.















STRUCT_VALUE_REGNUM
If the structure value address is passed in a re-
gister, then STRUCT_VALUE_REGNUM should be the
number of that register.

STRUCT_VALUE
If the structure value address is not passed in a
register, define STRUCT_VALUE as an expression re-
turning an RTX for the place where the address is
passed. If it returns 0, the address is passed as
an ``invisible'' first argument.

STRUCT_VALUE_INCOMING_REGNUM
On some architectures the place where the struc-
ture value address is found by the called function
is not the same place that the caller put it.
This can be due to register windows, or it could
be because the function prologue moves it to a
different place.

If the incoming location of the structure value
address is in a register, define this macro as the
register number.

STRUCT_VALUE_INCOMING
If the incoming location is not a register, define
STRUCT_VALUE_INCOMING as an expression for an RTX
for where the called function should find the
value. If it should find the value on the stack,
define this to create a mem which refers to the
frame pointer. A definition of 0 means that the
address is passed as an ``invisible'' first argu-
ment.

PCC_STATIC_STRUCT_RETURN
Define this macro if the usual system convention
on the target machine for returning structures and
unions is for the called function to return the
address of a static variable containing the value.
GNU CC does not normally use this convention, even
if it is the usual one, but does use it if `-
fpcc-struct-value' is specified.

Do not define this if the usual system convention
is for the caller to pass an address to the sub-
routine.


1.7.8. Caller-Saves Register Allocation

If you enable it, GNU CC can save registers around
function calls. This makes it possible to use call-
clobbered registers to hold variables that must live across













calls.

DEFAULT_CALLER_SAVES
Define this macro if function calls on the target
machine do not preserve any registers; in other
words, if CALL_USED_REGISTERS has 1 for all regis-
ters. This macro enables `-fcaller-saves' by de-
fault. Eventually that option will be enabled by
default on all machines and both the option and
this macro will be eliminated.

CALLER_SAVE_PROFITABLE (refs, calls)
A C expression to determine whether it is
worthwhile to consider placing a pseudo-register
in a call-clobbered hard register and saving and
restoring it around each function call. The ex-
pression should be 1 when this is worth doing, and
0 otherwise.

If you don't define this macro, a default is used
which is good on most machines: 4 * calls < refs.


1.7.9. Function Entry and Exit

This section describes the macros that output function
entry (prologue) and exit (epilogue) code.

FUNCTION_PROLOGUE (file, size)
A C compound statement that outputs the assembler
code for entry to a function. The prologue is
responsible for setting up the stack frame, ini-
tializing the frame pointer register, saving re-
gisters that must be saved, and allocating size
additional bytes of storage for the local vari-
ables. size is an integer. file is a stdio
stream to which the assembler code should be out-
put.

The label for the beginning of the function need
not be output by this macro. That has already
been done when the macro is run.

To determine which registers to save, the macro
can refer to the array regs_ever_live: element r
is nonzero if hard register r is used anywhere
within the function. This implies the function
prologue should save register r, provided it is
not one of the call-used registers.
(FUNCTION_EPILOGUE must likewise use
regs_ever_live.)















On machines that have ``register windows'', the
function entry code does not save on the stack the
registers that are in the windows, even if they
are supposed to be preserved by function calls;
instead it takes appropriate steps to ``push'' the
register stack, if any non-call-used registers are
used in the function.

On machines where functions may or may not have
frame-pointers, the function entry code must vary
accordingly; it must set up the frame pointer if
one is wanted, and not otherwise. To determine
whether a frame pointer is in wanted, the macro
can refer to the variable frame_pointer_needed.
The variable's value will be 1 at run time in a
function that needs a frame pointer. See section
Elimination.

The function entry code is responsible for allo-
cating any stack space required for the function.
This stack space consists of the regions listed
below. In most cases, these regions are allocated
in the order listed, with the last listed region
closest to the top of the stack (the lowest ad-
dress if STACK_GROWS_DOWNWARD is defined, and the
highest address if it is not defined). You can
use a different order for a machine if doing so is
more convenient or required for compatibility rea-
sons. Except in cases where required by standard
or by a debugger, there is no reason why the stack
layout used by GCC need agree with that used by
other compilers for a machine.

o+ A region of
current_function_pretend_args_size bytes of
uninitialized space just underneath the first
argument arriving on the stack. (This may
not be at the very start of the allocated
stack region if the calling sequence has
pushed anything else since pushing the stack
arguments. But usually, on such machines,
nothing else has been pushed yet, because the
function prologue itself does all the push-
ing.) This region is used on machines where
an argument may be passed partly in registers
and partly in memory, and, in some cases to
support the features in `varargs.h' and
`stdargs.h'.

o+ An area of memory used to save certain regis-
ters used by the function. The size of this
area, which may also include space for such
things as the return address and pointers to













previous stack frames, is machine-specific
and usually depends on which registers have
been used in the function. Machines with re-
gister windows often do not require a save
area.

o+ A region of at least size bytes, possibly
rounded up to an allocation boundary, to con-
tain the local variables of the function. On
some machines, this region and the save area
may occur in the opposite order, with the
save area closer to the top of the stack.

o+ Optionally, in the case that
ACCUMULATE_OUTGOING_ARGS is defined, a region
of current_function_outgoing_args_size bytes
to be used for outgoing argument lists of the
function. See section Stack Arguments.


Normally, it is necessary for FUNCTION_PROLOGUE
and FUNCTION_EPILOGUE to treat leaf functions spe-
cially. The C variable leaf_function is nonzero
for such a function.

EXIT_IGNORE_STACK
Define this macro as a C expression that is
nonzero if the return instruction or the function
epilogue ignores the value of the stack pointer;
in other words, if it is safe to delete an in-
struction to adjust the stack pointer before a re-
turn from the function.

Note that this macro's value is relevant only for
functions for which frame pointers are maintained.
It is never safe to delete a final stack adjust-
ment in a function that has no frame pointer, and
the compiler knows this regardless of
EXIT_IGNORE_STACK.

FUNCTION_EPILOGUE (file, size)
A C compound statement that outputs the assembler
code for exit from a function. The epilogue is
responsible for restoring the saved registers and
stack pointer to their values when the function
was called, and returning control to the caller.
This macro takes the same arguments as the macro
FUNCTION_PROLOGUE, and the registers to restore
are determined from regs_ever_live and
CALL_USED_REGISTERS in the same way.

On some machines, there is a single instruction
that does all the work of returning from the func-













tion. On these machines, give that instruction
the name `return' and do not define the macro
FUNCTION_EPILOGUE at all.

Do not define a pattern named `return' if you want
the FUNCTION_EPILOGUE to be used. If you want the
target switches to control whether return instruc-
tions or epilogues are used, define a `return'
pattern with a validity condition that tests the
target switches appropriately. If the `return'
pattern's validity condition is false, epilogues
will be used.

On machines where functions may or may not have
frame-pointers, the function exit code must vary
accordingly. Sometimes the code for these two
cases is completely different. To determine
whether a frame pointer is in wanted, the macro
can refer to the variable frame_pointer_needed.
The variable's value will be 1 at run time in a
function that needs a frame pointer.

Normally, it is necessary for FUNCTION_PROLOGUE
and FUNCTION_EPILOGUE to treat leaf functions spe-
cially. The C variable leaf_function is nonzero
for such a function. See section Leaf Functions.

On some machines, some functions pop their argu-
ments on exit while others leave that for the
caller to do. For example, the 68020 when given
`-mrtd' pops arguments in functions that take a
fixed number of arguments.

Your definition of the macro RETURN_POPS_ARGS de-
cides which functions pop their own arguments.
FUNCTION_EPILOGUE needs to know what was decided.
The variable current_function_pops_args is the
number of bytes of its arguments that a function
should pop. See section Scalar Return.

DELAY_SLOTS_FOR_EPILOGUE
Define this macro if the function epilogue con-
tains delay slots to which instructions from the
rest of the function can be ``moved''. The defin-
ition should be a C expression whose value is an
integer representing the number of delay slots
there.

ELIGIBLE_FOR_EPILOGUE_DELAY (insn, n)
A C expression that returns 1 if insn can be
placed in delay slot number n of the epilogue.















The argument n is an integer which identifies the
delay slot now being considered (since different
slots may have different rules of eligibility).
It is never negative and is always less than the
number of epilogue delay slots (what
DELAY_SLOTS_FOR_EPILOGUE returns). If you reject
a particular insn for a given delay slot, in prin-
ciple, it may be reconsidered for a subsequent de-
lay slot. Also, other insns may (at least in
principle) be considered for the so far unfilled
delay slot.

The insns accepted to fill the epilogue delay
slots are put in an RTL list made with insn_list
objects, stored in the variable
current_function_epilogue_delay_list. The insn
for the first delay slot comes first in the list.
Your definition of the macro FUNCTION_EPILOGUE
should fill the delay slots by outputting the
insns in this list, usually by calling
final_scan_insn.

You need not define this macro if you did not de-
fine DELAY_SLOTS_FOR_EPILOGUE.


1.7.10. Generating Code for Profiling

FUNCTION_PROFILER (file, labelno)
A C statement or compound statement to output to
file some assembler code to call the profiling
subroutine mcount. Before calling, the assembler
code must load the address of a counter variable
into a register where mcount expects to find the
address. The name of this variable is `LP' fol-
lowed by the number labelno, so you would generate
the name using `LP%d' in a fprintf.

The details of how the address should be passed to
mcount are determined by your operating system en-
vironment, not by GNU CC. To figure them out,
compile a small program for profiling using the
system's installed C compiler and look at the as-
sembler code that results.

PROFILE_BEFORE_PROLOGUE
Define this macro if the code for function profil-
ing should come before the function prologue.
Normally, the profiling code comes after.

FUNCTION_BLOCK_PROFILER (file, labelno)
A C statement or compound statement to output to
file some assembler code to initialize basic-block













profiling for the current object module. This
code should call the subroutine __bb_init_func
once per object module, passing it as its sole ar-
gument the address of a block allocated in the ob-
ject module.

The name of the block is a local symbol made with
this statement:


ASM_GENERATE_INTERNAL_LABEL (buffer, "LPBX", 0);



Of course, since you are writing the defini-
tion of ASM_GENERATE_INTERNAL_LABEL as well as
that of this macro, you can take a short cut
in the definition of this macro and use the
name that you know will result.

The first word of this block is a flag which
will be nonzero if the object module has al-
ready been initialized. So test this word
first, and do not call __bb_init_func if the
flag is nonzero.

BLOCK_PROFILER (file, blockno)
A C statement or compound statement to incre-
ment the count associated with the basic block
number blockno. Basic blocks are numbered
separately from zero within each compilation.
The count associated with block number blockno
is at index blockno in a vector of words; the
name of this array is a local symbol made with
this statement:


ASM_GENERATE_INTERNAL_LABEL (buffer, "LPBX", 2);



Of course, since you are writing the defini-
tion of ASM_GENERATE_INTERNAL_LABEL as well as
that of this macro, you can take a short cut
in the definition of this macro and use the
name that you know will result.


1.8. Implementing the Varargs Macros

GNU CC comes with an implementation of `varargs.h' and
`stdarg.h' that work without change on machines that pass
arguments on the stack. Other machines require their own













implementations of varargs, and the two machine independent
header files must have conditionals to include it.

ANSI `stdarg.h' differs from traditional `varargs.h'
mainly in the calling convention for va_start. The tradi-
tional implementation takes just one argument, which is the
variable in which to store the argument pointer. The ANSI
implementation takes an additional first argument, which is
the last named argument of the function. However, it should
not use this argument. The way to find the end of the named
arguments is with the built-in functions described below.

__builtin_saveregs ()
Use this built-in function to save the argument
registers in memory so that the varargs mechanism
can access them. Both ANSI and traditional ver-
sions of va_start must use __builtin_saveregs, un-
less you use SETUP_INCOMING_VARARGS (see below)
instead.

On some machines, __builtin_saveregs is open-coded
under the control of the macro
EXPAND_BUILTIN_SAVEREGS. On other machines, it
calls a routine written in assembler language,
found in `libgcc2.c'.

Regardless of what code is generated for the call
to __builtin_saveregs, it appears at the beginning
of the function, not where the call to
__builtin_saveregs is written. This is because
the registers must be saved before the function
starts to use them for its own purposes.

__builtin_args_info (category)
Use this built-in function to find the first
anonymous arguments in registers.

In general, a machine may have several categories
of registers used for arguments, each for a par-
ticular category of data types. (For example, on
some machines, floating-point registers are used
for floating-point arguments while other arguments
are passed in the general registers.) To make
non-varargs functions use the proper calling con-
vention, you have defined the CUMULATIVE_ARGS data
type to record how many registers in each category
have been used so far

__builtin_args_info accesses the same data struc-
ture of type CUMULATIVE_ARGS after the ordinary
argument layout is finished with it, with category
specifying which word to access. Thus, the value
indicates the first unused register in a given













category.

Normally, you would use __builtin_args_info in the
implementation of va_start, accessing each
category just once and storing the value in the
va_list object. This is because va_list will have
to update the values, and there is no way to alter
the values accessed by __builtin_args_info.

__builtin_next_arg ()
This is the equivalent of __builtin_args_info, for
stack arguments. It returns the address of the
first anonymous stack argument, as type void *. If
ARGS_GROW_DOWNWARD, it returns the address of the
location above the first anonymous stack argument.
Use it in va_start to initialize the pointer for
fetching arguments from the stack.

__builtin_classify_type (object)
Since each machine has its own conventions for
which data types are passed in which kind of re-
gister, your implementation of va_arg has to em-
body these conventions. The easiest way to
categorize the specified data type is to use
__builtin_classify_type together with sizeof and
__alignof__.

__builtin_classify_type ignores the value of ob-
ject, considering only its data type. It returns
an integer describing what kind of type that is--
-integer, floating, pointer, structure, and so on.

The file `typeclass.h' defines an enumeration that
you can use to interpret the values of
__builtin_classify_type.


These machine description macros help implement
varargs:

EXPAND_BUILTIN_SAVEREGS (args)
If defined, is a C expression that produces the
machine-specific code for a call to
__builtin_saveregs. This code will be moved to
the very beginning of the function, before any
parameter access are made. The return value of
this function should be an RTX that contains the
value to use as the return of __builtin_saveregs.

The argument args is a tree_list containing the
arguments that were passed to __builtin_saveregs.















If this macro is not defined, the compiler will
output an ordinary call to the library function
`__builtin_saveregs'.

SETUP_INCOMING_VARARGS (args_so_far, mode, type, pretend_args_size, second_time)
This macro offers an alternative to using
__builtin_saveregs and defining the macro
EXPAND_BUILTIN_SAVEREGS. Use it to store the
anonymous register arguments into the stack so
that all the arguments appear to have been passed
consecutively on the stack. Once this is done,
you can use the standard implementation of varargs
that works for machines that pass all their argu-
ments on the stack.

The argument args_so_far is the CUMULATIVE_ARGS
data structure, containing the values that obtain
after processing of the named arguments. The ar-
guments mode and type describe the last named
argument---its machine mode and its data type as a
tree node.

The macro implementation should do two things:
first, push onto the stack all the argument regis-
ters not used for the named arguments, and second,
store the size of the data thus pushed into the
int-valued variable whose name is supplied as the
argument pretend_args_size. The value that you
store here will serve as additional offset for
setting up the stack frame.

Because you must generate code to push the
anonymous arguments at compile time without know-
ing their data types, SETUP_INCOMING_VARARGS is
only useful on machines that have just a single
category of argument register and use it uniformly
for all data types.

If the argument second_time is nonzero, it means
that the arguments of the function are being
analyzed for the second time. This happens for an
inline function, which is not actually compiled
until the end of the source file. The macro
SETUP_INCOMING_VARARGS should not generate any in-
structions in this case.


1.9. Trampolines for Nested Functions

A trampoline is a small piece of code that is created
at run time when the address of a nested function is taken.
It normally resides on the stack, in the stack frame of the
containing function. These macros tell GNU CC how to













generate code to allocate and initialize a trampoline.

The instructions in the trampoline must do two things:
load a constant address into the static chain register, and
jump to the real address of the nested function. On CISC
machines such as the m68k, this requires two instructions, a
move immediate and a jump. Then the two addresses exist in
the trampoline as word-long immediate operands. On RISC
machines, it is often necessary to load each address into a
register in two parts. Then pieces of each address form
separate immediate operands.

The code generated to initialize the trampoline must
store the variable parts---the static chain value and the
function address---into the immediate operands of the
instructions. On a CISC machine, this is simply a matter of
copying each address to a memory reference at the proper
offset from the start of the trampoline. On a RISC machine,
it may be necessary to take out pieces of the address and
store them separately.

TRAMPOLINE_TEMPLATE (file)
A C statement to output, on the stream file, as-
sembler code for a block of data that contains the
constant parts of a trampoline. This code should
not include a label---the label is taken care of
automatically.

TRAMPOLINE_SIZE
A C expression for the size in bytes of the tram-
poline, as an integer.

TRAMPOLINE_ALIGNMENT
Alignment required for trampolines, in bits.

If you don't define this macro, the value of
BIGGEST_ALIGNMENT is used for aligning trampo-
lines.

INITIALIZE_TRAMPOLINE (addr, fnaddr, static_chain)
A C statement to initialize the variable parts of
a trampoline. addr is an RTX for the address of
the trampoline; fnaddr is an RTX for the address
of the nested function; static_chain is an RTX for
the static chain value that should be passed to
the function when it is called.

ALLOCATE_TRAMPOLINE (fp)
A C expression to allocate run-time space for a
trampoline. The expression value should be an RTX
representing a memory reference to the space for
the trampoline.














If this macro is not defined, by default the tram-
poline is allocated as a stack slot. This default
is right for most machines. The exceptions are
machines where it is impossible to execute in-
structions in the stack area. On such machines,
you may have to implement a separate stack, using
this macro in conjunction with FUNCTION_PROLOGUE
and FUNCTION_EPILOGUE.

fp points to a data structure, a struct function,
which describes the compilation status of the im-
mediate containing function of the function which
the trampoline is for. Normally (when
ALLOCATE_TRAMPOLINE is not defined), the stack
slot for the trampoline is in the stack frame of
this containing function. Other allocation stra-
tegies probably must do something analogous with
this information.


Implementing trampolines is difficult on many machines
because they have separate instruction and data caches.
Writing into a stack location fails to clear the memory in
the instruction cache, so when the program jumps to that
location, it executes the old contents.

Here are two possible solutions. One is to clear the
relevant parts of the instruction cache whenever a trampo-
line is set up. The other is to make all trampolines ident-
ical, by having them jump to a standard subroutine. The
former technique makes trampoline execution faster; the
latter makes initialization faster.

To clear the instruction cache when a trampoline is
initialized, define the following macros which describe the
shape of the cache.

INSN_CACHE_SIZE
The total size in bytes of the cache.

INSN_CACHE_LINE_WIDTH
The length in bytes of each cache line. The cache
is divided into cache lines which are disjoint
slots, each holding a contiguous chunk of data
fetched from memory. Each time data is brought
into the cache, an entire line is read at once.
The data loaded into a cache line is always
aligned on a boundary equal to the line size.

INSN_CACHE_DEPTH
The number of alternative cache lines that can
hold any particular memory location.














To use a standard subroutine, define the following
macro. In addition, you must make sure that the instruc-
tions in a trampoline fill an entire cache line with identi-
cal instructions, or else ensure that the beginning of the
trampoline code is always aligned at the same point in its
cache line. Look in `m68k.h' as a guide.

TRANSFER_FROM_TRAMPOLINE
Define this macro if trampolines need a special
subroutine to do their work. The macro should ex-
pand to a series of asm statements which will be
compiled with GNU CC. They go in a library func-
tion named __transfer_from_trampoline.

If you need to avoid executing the ordinary prolo-
gue code of a compiled C function when you jump to
the subroutine, you can do so by placing a special
label of your own in the assembler code. Use one
asm statement to generate an assembler label, and
another to make the label global. Then trampo-
lines can use that label to jump directly to your
special assembler code.


1.10. Implicit Calls to Library Routines

MULSI3_LIBCALL
A C string constant giving the name of the func-
tion to call for multiplication of one signed
full-word by another. If you do not define this
macro, the default name is used, which is __mul-
si3, a function defined in `libgcc.a'.

DIVSI3_LIBCALL
A C string constant giving the name of the func-
tion to call for division of one signed full-word
by another. If you do not define this macro, the
default name is used, which is __divsi3, a func-
tion defined in `libgcc.a'.

UDIVSI3_LIBCALL
A C string constant giving the name of the func-
tion to call for division of one unsigned full-
word by another. If you do not define this macro,
the default name is used, which is __udivsi3, a
function defined in `libgcc.a'.

MODSI3_LIBCALL
A C string constant giving the name of the func-
tion to call for the remainder in division of one
signed full-word by another. If you do not define
this macro, the default name is used, which is
__modsi3, a function defined in `libgcc.a'.













UMODSI3_LIBCALL
A C string constant giving the name of the func-
tion to call for the remainder in division of one
unsigned full-word by another. If you do not de-
fine this macro, the default name is used, which
is __umodsi3, a function defined in `libgcc.a'.

MULDI3_LIBCALL
A C string constant giving the name of the func-
tion to call for multiplication of one signed
double-word by another. If you do not define this
macro, the default name is used, which is __mul-
di3, a function defined in `libgcc.a'.

DIVDI3_LIBCALL
A C string constant giving the name of the func-
tion to call for division of one signed double-
word by another. If you do not define this macro,
the default name is used, which is __divdi3, a
function defined in `libgcc.a'.

UDIVDI3_LIBCALL
A C string constant giving the name of the func-
tion to call for division of one unsigned full-
word by another. If you do not define this macro,
the default name is used, which is __udivdi3, a
function defined in `libgcc.a'.

MODDI3_LIBCALL
A C string constant giving the name of the func-
tion to call for the remainder in division of one
signed double-word by another. If you do not de-
fine this macro, the default name is used, which
is __moddi3, a function defined in `libgcc.a'.

UMODDI3_LIBCALL
A C string constant giving the name of the func-
tion to call for the remainder in division of one
unsigned full-word by another. If you do not de-
fine this macro, the default name is used, which
is __umoddi3, a function defined in `libgcc.a'.

TARGET_MEM_FUNCTIONS
Define this macro if GNU CC should generate calls
to the System V (and ANSI C) library functions
memcpy and memset rather than the BSD functions
bcopy and bzero.

LIBGCC_NEEDS_DOUBLE
Define this macro if only float arguments cannot
be passed to library routines (so they must be
converted to double). This macro affects both how
library calls are generated and how the library













routines in `libgcc1.c' accept their arguments.
It is useful on machines where floating and fixed
point arguments are passed differently, such as
the i860.

FLOAT_ARG_TYPE
Define this macro to override the type used by the
library routines to pick up arguments of type
float. (By default, they use a union of float and
int.)

The obvious choice would be float---but that won't
work with traditional C compilers that expect all
arguments declared as float to arrive as double.
To avoid this conversion, the library routines ask
for the value as some other type and then treat it
as a float.

On some systems, no other type will work for this.
For these systems, you must use
LIBGCC_NEEDS_DOUBLE instead, to force conversion
of the values double before they are passed.

FLOATIFY (passed-value)
Define this macro to override the way library rou-
tines redesignate a float argument as a float in-
stead of the type it was passed as. The default
is an expression which takes the float field of
the union.

FLOAT_VALUE_TYPE
Define this macro to override the type used by the
library routines to return values that ought to
have type float. (By default, they use int.)

The obvious choice would be float---but that won't
work with traditional C compilers gratuitously
convert values declared as float into double.

INTIFY (float-value)
Define this macro to override the way the value of
a float-returning library routine should be pack-
aged in order to return it. These functions are
actually declared to return type FLOAT_VALUE_TYPE
(normally int).

These values can't be returned as type float be-
cause traditional C compilers would gratuitously
convert the value to a double.

A local variable named intify is always available
when the macro INTIFY is used. It is a union of a
float field named f and a field named i whose type













is FLOAT_VALUE_TYPE or int.

If you don't define this macro, the default defin-
ition works by copying the value through that un-
ion.

SItype
Define this macro as the name of the data type
corresponding to SImode in the system's own C com-
piler.

You need not define this macro if that type is
int, as it usually is.

perform_...
Define these macros to supply explicit C state-
ments to carry out various arithmetic operations
on types float and double in the library routines
in `libgcc1.c'. See that file for a full list of
these macros and their arguments.

On most machines, you don't need to define any of
these macros, because the C compiler that comes
with the system takes care of doing them.

NEXT_OBJC_RUNTIME
Define this macro to generate code for Objective C
message sending using the calling convention of
the NeXT system. This calling convention involves
passing the object, the selector and the method
arguments all at once to the method-lookup library
function.

The default calling convention passes just the ob-
ject and the selector to the lookup function,
which returns a pointer to the method.


1.11. Addressing Modes

HAVE_POST_INCREMENT
Define this macro if the machine supports post-
increment addressing.

HAVE_PRE_INCREMENT

HAVE_POST_DECREMENT

HAVE_PRE_DECREMENT
Similar for other kinds of addressing.

CONSTANT_ADDRESS_P (x)
A C expression that is 1 if the RTX x is a con-













stant which is a valid address. On most machines,
this can be defined as CONSTANT_P (x), but a few
machines are more restrictive in which constant
addresses are supported.

CONSTANT_P accepts integer-values expressions
whose values are not explicitly known, such as
symbol_ref, label_ref, and high expressions and
const arithmetic expressions, in addition to
const_int and const_double expressions.

MAX_REGS_PER_ADDRESS
A number, the maximum number of registers that can
appear in a valid memory address. Note that it is
up to you to specify a value equal to the maximum
number that GO_IF_LEGITIMATE_ADDRESS would ever
accept.

GO_IF_LEGITIMATE_ADDRESS (mode, x, label)
A C compound statement with a conditional goto la-
bel; executed if x (an RTX) is a legitimate memory
address on the target machine for a memory operand
of mode mode.

It usually pays to define several simpler macros
to serve as subroutines for this one. Otherwise
it may be too complicated to understand.

This macro must exist in two variants: a strict
variant and a non-strict one. The strict variant
is used in the reload pass. It must be defined so
that any pseudo-register that has not been allo-
cated a hard register is considered a memory
reference. In contexts where some kind of regis-
ter is required, a pseudo-register with no hard
register must be rejected.

The non-strict variant is used in other passes.
It must be defined to accept all pseudo-registers
in every context where some kind of register is
required.

Compiler source files that want to use the strict
variant of this macro define the macro
REG_OK_STRICT. You should use an #ifdef
REG_OK_STRICT conditional to define the strict
variant in that case and the non-strict variant
otherwise.

Typically among the subroutines used to define
GO_IF_LEGITIMATE_ADDRESS are subroutines to check
for acceptable registers for various purposes (one
for base registers, one for index registers, and













so on). Then only these subroutine macros need
have two variants; the higher levels of macros may
be the same whether strict or not.

Normally, constant addresses which are the sum of
a symbol_ref and an integer are stored inside a
const RTX to mark them as constant. Therefore,
there is no need to recognize such sums specifi-
cally as legitimate addresses. Normally you would
simply recognize any const as legitimate.

Usually PRINT_OPERAND_ADDRESS is not prepared to
handle constant sums that are not marked with
const. It assumes that a naked plus indicates in-
dexing. If so, then you must reject such naked
constant sums as illegitimate addresses, so that
none of them will be given to
PRINT_OPERAND_ADDRESS.

On some machines, whether a symbolic address is
legitimate depends on the section that the address
refers to. On these machines, define the macro
ENCODE_SECTION_INFO to store the information into
the symbol_ref, and then check for it here. When
you see a const, you will have to look inside it
to find the symbol_ref in order to determine the
section. See section Assembler Format.

The best way to modify the name string is by ad-
ding text to the beginning, with suitable punctua-
tion to prevent any ambiguity. Allocate the new
name in saveable_obstack. You will have to modify
ASM_OUTPUT_LABELREF to remove and decode the added
text and output the name accordingly.

You can check the information stored here into the
symbol_ref in the definitions of
GO_IF_LEGITIMATE_ADDRESS and
PRINT_OPERAND_ADDRESS.

REG_OK_FOR_BASE_P (x)
A C expression that is nonzero if x (assumed to be
a reg RTX) is valid for use as a base register.
For hard registers, it should always accept those
which the hardware permits and reject the others.
Whether the macro accepts or rejects pseudo regis-
ters must be controlled by REG_OK_STRICT as
described above. This usually requires two vari-
ant definitions, of which REG_OK_STRICT controls
the one actually used.

REG_OK_FOR_INDEX_P (x)
A C expression that is nonzero if x (assumed to be













a reg RTX) is valid for use as an index register.

The difference between an index register and a
base register is that the index register may be
scaled. If an address involves the sum of two re-
gisters, neither one of them scaled, then either
one may be labeled the ``base'' and the other the
``index''; but whichever labeling is used must fit
the machine's constraints of which registers may
serve in each capacity. The compiler will try
both labelings, looking for one that is valid, and
will reload one or both registers only if neither
labeling works.

LEGITIMIZE_ADDRESS (x, oldx, mode, win)
A C compound statement that attempts to replace x
with a valid memory address for an operand of mode
mode. win will be a C statement label elsewhere
in the code; the macro definition may use


GO_IF_LEGITIMATE_ADDRESS (mode, x, win);



to avoid further processing if the address has be-
come legitimate.

x will always be the result of a call to
break_out_memory_refs, and oldx will be the
operand that was given to that function to
produce x.

The code generated by this macro should not
alter the substructure of x. If it transforms
x into a more legitimate form, it should as-
sign x (which will always be a C variable) a
new value.

It is not necessary for this macro to come up
with a legitimate address. The compiler has
standard ways of doing so in all cases. In
fact, it is safe for this macro to do nothing.
But often a machine-dependent strategy can
generate better code.

GO_IF_MODE_DEPENDENT_ADDRESS (addr, label)
A C statement or compound statement with a
conditional goto label; executed if memory ad-
dress x (an RTX) can have different meanings
depending on the machine mode of the memory
reference it is used for.














Autoincrement and autodecrement addresses typ-
ically have mode-dependent effects because the
amount of the increment or decrement is the
size of the operand being addressed. Some
machines have other mode-dependent addresses.
Many RISC machines have no mode-dependent ad-
dresses.

You may assume that addr is a valid address
for the machine.

LEGITIMATE_CONSTANT_P (x)
A C expression that is nonzero if x is a legi-
timate constant for an immediate operand on
the target machine. You can assume that x sa-
tisfies CONSTANT_P, so you need not check
this. In fact, `1' is a suitable definition
for this macro on machines where anything
CONSTANT_P is valid.

LEGITIMATE_PIC_OPERAND_P (x)
A C expression that is nonzero if x is a legi-
timate immediate operand on the target machine
when generating position independent code.
You can assume that x satisfies CONSTANT_P, so
you need not check this. You can also assume
flag_pic is true, so you need not check it ei-
ther. You need not define this macro if all
constants (including SYMBOL_REF) can be im-
mediate operands when generating position in-
dependent code.


1.12. Condition Code Status

The file `conditions.h' defines a variable cc_status to
describe how the condition code was computed (in case the
interpretation of the condition code depends on the instruc-
tion that it was set by). This variable contains the RTL
expressions on which the condition code is currently based,
and several standard flags.

Sometimes additional machine-specific flags must be
defined in the machine description header file. It can also
add additional machine-specific information by defining
CC_STATUS_MDEP.

CC_STATUS_MDEP
C code for a data type which is used for declaring
the mdep component of cc_status. It defaults to
int.















This macro is not used on machines that do not use
cc0.

CC_STATUS_MDEP_INIT
A C expression to initialize the mdep field to
``empty''. The default definition does nothing,
since most machines don't use the field anyway.
If you want to use the field, you should probably
define this macro to initialize it.

This macro is not used on machines that do not use
cc0.

NOTICE_UPDATE_CC (exp, insn)
A C compound statement to set the components of
cc_status appropriately for an insn insn whose
body is exp. It is this macro's responsibility to
recognize insns that set the condition code as a
byproduct of other activity as well as those that
explicitly set (cc0).

This macro is not used on machines that do not use
cc0.

If there are insns that do not set the condition
code but do alter other machine registers, this
macro must check to see whether they invalidate
the expressions that the condition code is record-
ed as reflecting. For example, on the 68000,
insns that store in address registers do not set
the condition code, which means that usually
NOTICE_UPDATE_CC can leave cc_status unaltered for
such insns. But suppose that the previous insn
set the condition code based on location
`a4@(102)' and the current insn stores a new value
in `a4'. Although the condition code is not
changed by this, it will no longer be true that it
reflects the contents of `a4@(102)'. Therefore,
NOTICE_UPDATE_CC must alter cc_status in this case
to say that nothing is known about the condition
code value.

The definition of NOTICE_UPDATE_CC must be
prepared to deal with the results of peephole op-
timization: insns whose patterns are parallel RTXs
containing various reg, mem or constants which are
just the operands. The RTL structure of these
insns is not sufficient to indicate what the insns
actually do. What NOTICE_UPDATE_CC should do when
it sees one is just to run CC_STATUS_INIT.

A possible definition of NOTICE_UPDATE_CC is to
call a function that looks at an attribute (see













section Insn Attributes) named, for example,
`cc'. This avoids having detailed information
about patterns in two places, the `md' file and in
NOTICE_UPDATE_CC.

EXTRA_CC_MODES
A list of names to be used for additional modes
for condition code values in registers (see sec-
tion Jump Patterns). These names are added to
enum machine_mode and all have class MODE_CC. By
convention, they should start with `CC' and end
with `mode'.

You should only define this macro if your machine
does not use cc0 and only if additional modes are
required.

EXTRA_CC_NAMES
A list of C strings giving the names for the modes
listed in EXTRA_CC_MODES. For example, the Sparc
defines this macro and EXTRA_CC_MODES as


#define EXTRA_CC_MODES CC_NOOVmode, CCFPmode
#define EXTRA_CC_NAMES "CC_NOOV", "CCFP"



This macro is not required if EXTRA_CC_MODES
is not defined.

SELECT_CC_MODE (op, x)
Returns a mode from class MODE_CC to be used
when comparison operation code op is applied
to rtx x. For example, on the Sparc,
SELECT_CC_MODE is defined as (see see section
Jump Patterns for a description of the reason
for this definition)


#define SELECT_CC_MODE(OP,X) \
(GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT ? CCFPmode \
: (GET_CODE (X) == PLUS || GET_CODE (X) == MINUS \
|| GET_CODE (X) == NEG) \
? CC_NOOVmode : CCmode)



This macro is not required if EXTRA_CC_MODES
is not defined.
















1.13. Describing Relative Costs of Operations

These macros let you describe the relative speed of
various operations on the target machine.

CONST_COSTS (x, code)
A part of a C switch statement that describes the
relative costs of constant RTL expressions. It
must contain case labels for expression codes
const_int, const, symbol_ref, label_ref and
const_double. Each case must ultimately reach a
return statement to return the relative cost of
the use of that kind of constant value in an ex-
pression. The cost may depend on the precise
value of the constant, which is available for ex-
amination in x.

code is the expression code---redundant, since it
can be obtained with GET_CODE (x).

RTX_COSTS (x, code)
Like CONST_COSTS but applies to nonconstant RTL
expressions. This can be used, for example, to
indicate how costly a multiply instruction is. In
writing this macro, you can use the construct
COSTS_N_INSNS (n) to specify a cost equal to n
fast instructions.

This macro is optional; do not define it if the
default cost assumptions are adequate for the tar-
get machine.

ADDRESS_COST (address)
An expression giving the cost of an addressing
mode that contains address. If not defined, the
cost is computed from the address expression and
the CONST_COSTS values.

For most CISC machines, the default cost is a good
approximation of the true cost of the addressing
mode. However, on RISC machines, all instructions
normally have the same length and execution time.
Hence all addresses will have equal costs.

In cases where more than one form of an address is
known, the form with the lowest cost will be used.
If multiple forms have the same, lowest, cost, the
one that is the most complex will be used.

For example, suppose an address that is equal to
the sum of a register and a constant is used twice
in the same basic block. When this macro is not
defined, the address will be computed in a regis-













ter and memory references will be indirect through
that register. On machines where the cost of the
addressing mode containing the sum is no higher
than that of a simple indirect reference, this
will produce an additional instruction and possi-
bly require an additional register. Proper
specification of this macro eliminates this over-
head for such machines.

Similar use of this macro is made in strength
reduction of loops.

address need not be valid as an address. In such
a case, the cost is not relevant and can be any
value; invalid addresses need not be assigned a
different cost.

On machines where an address involving more than
one register is as cheap as an address computation
involving only one register, defining ADDRESS_COST
to reflect this can cause two registers to be live
over a region of code where only one would have
been if ADDRESS_COST were not defined in that
manner. This effect should be considered in the
definition of this macro. Equivalent costs should
probably only be given to addresses with different
numbers of registers on machines with lots of re-
gisters.

This macro will normally either not be defined or
be defined as a constant.

REGISTER_MOVE_COST (from, to)
A C expression for the cost of moving data from a
register in class from to one in class to. The
classes are expressed using the enumeration values
such as GENERAL_REGS. A value of 2 is the de-
fault; other values are interpreted relative to
that.

It is not required that the cost always equal 2
when from is the same as to; on some machines it
is expensive to move between registers if they are
not general registers.

If reload sees an insn consisting of a single set
between two hard registers, and if
REGISTER_MOVE_COST applied to their classes re-
turns a value of 2, reload does not check to en-
sure that the constraints of the insn are met.
Setting a cost of other than 2 will allow reload
to verify that the constraints are met. You
should do this if the `movm' pattern's constraints













do not allow such copying.

MEMORY_MOVE_COST (m)
A C expression for the cost of moving data of mode
m between a register and memory. A value of 2 is
the default; this cost is relative to those in
REGISTER_MOVE_COST.

If moving between registers and memory is more ex-
pensive than between two registers, you should de-
fine this macro to express the relative cost.

BRANCH_COST
A C expression for the cost of a branch instruc-
tion. A value of 1 is the default; other values
are interpreted relative to that.


Here are additional macros which do not specify precise
relative costs, but only that certain actions are more
expensive than GNU CC would ordinarily expect.

SLOW_BYTE_ACCESS
Define this macro as a C expression which is
nonzero if accessing less than a word of memory
(i.e. a char or a short) is no faster than access-
ing a word of memory, i.e., if such access require
more than one instruction or if there is no
difference in cost between byte and (aligned) word
loads.

When this macro is not defined, the compiler will
access a field by finding the smallest containing
object; when it is defined, a fullword load will
be used if alignment permits. Unless bytes
accesses are faster than word accesses, using word
accesses is preferable since it may eliminate sub-
sequent memory access if subsequent accesses occur
to other fields in the same word of the structure,
but to different bytes.

SLOW_ZERO_EXTEND
Define this macro if zero-extension (of a char or
short to an int) can be done faster if the desti-
nation is a register that is known to be zero.

If you define this macro, you must have instruc-
tion patterns that recognize RTL structures like
this:


(set (strict_low_part (subreg:QI (reg:SI ...) 0)) ...)
















and likewise for HImode.

SLOW_UNALIGNED_ACCESS
Define this macro if unaligned accesses have a
cost many times greater than aligned accesses,
for example if they are emulated in a trap
handler.

When this macro is defined, the compiler will
act as if STRICT_ALIGNMENT were defined when
generating code for block moves. This can
cause significantly more instructions to be
produced. Therefore, do not define this macro
if unaligned accesses only add a cycle or two
to the time for a memory access.

DONT_REDUCE_ADDR
Define this macro to inhibit strength reduc-
tion of memory addresses. (On some machines,
such strength reduction seems to do harm rath-
er than good.)

MOVE_RATIO
The number of scalar move insns which should
be generated instead of a string move insn or
a library call. Increasing the value will al-
ways make code faster, but eventually incurs
high cost in increased code size.

If you don't define this, a reasonable default
is used.

NO_FUNCTION_CSE
Define this macro if it is as good or better
to call a constant function address than to
call an address kept in a register.

NO_RECURSIVE_FUNCTION_CSE
Define this macro if it is as good or better
for a function to call itself with an explicit
address than to call an address kept in a re-
gister.


1.14.
Dividing the Output into Sections (Texts, Data, ...)

An object file is divided into sections containing dif-
ferent types of data. In the most common case, there are
three sections: the text section, which holds instructions
and read-only data; the data section, which holds













initialized writable data; and the bss section, which holds
uninitialized data. Some systems have other kinds of sec-
tions.

The compiler must tell the assembler when to switch
sections. These macros control what commands to output to
tell the assembler this. You can also define additional
sections.

TEXT_SECTION_ASM_OP
A C string constant for the assembler operation
that should precede instructions and read-only
data. Normally ".text" is right.

DATA_SECTION_ASM_OP
A C string constant for the assembler operation to
identify the following data as writable initial-
ized data. Normally ".data" is right.

SHARED_SECTION_ASM_OP
If defined, a C string constant for the assembler
operation to identify the following data as shared
data. If not defined, DATA_SECTION_ASM_OP will be
used.

INIT_SECTION_ASM_OP
If defined, a C string constant for the assembler
operation to identify the following data as ini-
tialization code. If not defined, GNU CC will as-
sume such a section does not exist.

EXTRA_SECTIONS
A list of names for sections other than the stan-
dard two, which are in_text and in_data. You need
not define this macro on a system with no other
sections (that GCC needs to use).

EXTRA_SECTION_FUNCTIONS
One or more functions to be defined in `varasm.c'.
These functions should do jobs analogous to those
of text_section and data_section, for your addi-
tional sections. Do not define this macro if you
do not define EXTRA_SECTIONS.

READONLY_DATA_SECTION
On most machines, read-only variables, constants,
and jump tables are placed in the text section.
If this is not the case on your machine, this mac-
ro should be defined to be the name of a function
(either data_section or a function defined in
EXTRA_SECTIONS) that switches to the section to be
used for read-only items.














If these items should be placed in the text sec-
tion, this macro should not be defined.

SELECT_SECTION (exp, reloc)
A C statement or statements to switch to the ap-
propriate section for output of exp. You can as-
sume that exp is either a VAR_DECL node or a con-
stant of some sort. reloc indicates whether the
initial value of exp requires link-time reloca-
tions. Select the section by calling text_section
or one of the alternatives for other sections.

Do not define this macro if you put all read-only
variables and constants in the read-only data sec-
tion (usually the text section).

SELECT_RTX_SECTION (mode, rtx)
A C statement or statements to switch to the ap-
propriate section for output of rtx in mode mode.
You can assume that rtx is some kind of constant
in RTL. The argument mode is redundant except in
the case of a const_int rtx. Select the section
by calling text_section or one of the alternatives
for other sections.

Do not define this macro if you put all constants
in the read-only data section.

JUMP_TABLES_IN_TEXT_SECTION
Define this macro if jump tables (for tablejump
insns) should be output in the text section, along
with the assembler instructions. Otherwise, the
readonly data section is used.

This macro is irrelevant if there is no separate
readonly data section.

ENCODE_SECTION_INFO (decl)
Define this macro if references to a symbol must
be treated differently depending on something
about the variable or function named by the symbol
(such as what section it is in).

The macro definition, if any, is executed immedi-
ately after the rtl for decl has been created and
stored in DECL_RTL (decl). The value of the rtl
will be a mem whose address is a symbol_ref.

The usual thing for this macro to do is to record
a flag in the symbol_ref (such as SYMBOL_REF_FLAG)
or to store a modified name string in the
symbol_ref (if one bit is not enough information).














1.15. Position Independent Code

This section describes macros that help implement gen-
eration of position independent code. Simply defining these
macros is not enough to generate valid PIC; you must also
add support to the macros GO_IF_LEGITIMATE_ADDRESS and
LEGITIMIZE_ADDRESS, and PRINT_OPERAND_ADDRESS as well. You
must modify the definition of `movsi' to do something
appropriate when the source operand contains a symbolic
address. You may also need to alter the handling of switch
statements so that they use relative addresses.

PIC_OFFSET_TABLE_REGNUM
The register number of the register used to ad-
dress a table of static data addresses in memory.
In some cases this register is defined by a
processor's ``application binary interface''
(ABI). When this macro is defined, RTL is gen-
erated for this register once, as with the stack
pointer and frame pointer registers. If this mac-
ro is not defined, it is up to the machine-
dependent files to allocate such a register (if
necessary).

FINALIZE_PIC
By generating position-independent code, when two
different programs (A and B) share a common li-
brary (libC.a), the text of the library can be
shared whether or not the library is linked at the
same address for both programs. In some of these
environments, position-independent code requires
not only the use of different addressing modes,
but also special code to enable the use of these
addressing modes.

The FINALIZE_PIC macro serves as a hook to emit
these special codes once the function is being
compiled into assembly code, but not before. (It
is not done before, because in the case of compil-
ing an inline function, it would lead to multiple
PIC prologues being included in functions which
used inline functions and were compiled to assem-
bly language.)

1.16. Defining the Output Assembler Language

This section describes macros whose principal purpose
is to describe how to write instructions in assembler
language--rather than what the instructions do.

















1.16.1. The Overall Framework of an Assembler File

ASM_FILE_START (stream)
A C expression which outputs to the stdio stream
stream some appropriate text to go at the start of
an assembler file.

Normally this macro is defined to output a line
containing `#NO_APP', which is a comment that has
no effect on most assemblers but tells the GNU as-
sembler that it can save time by not checking for
certain assembler constructs.

On systems that use SDB, it is necessary to output
certain commands; see `attasm.h'.

ASM_FILE_END (stream)
A C expression which outputs to the stdio stream
stream some appropriate text to go at the end of
an assembler file.

If this macro is not defined, the default is to
output nothing special at the end of the file.
Most systems don't require any definition.

On systems that use SDB, it is necessary to output
certain commands; see `attasm.h'.

ASM_IDENTIFY_GCC (file)
A C statement to output assembler commands which
will identify the object file as having been com-
piled with GNU CC (or another GNU compiler).

If you don't define this macro, the string
`gcc_compiled.:' is output. This string is calcu-
lated to define a symbol which, on BSD systems,
will never be defined for any other reason. GDB
checks for the presence of this symbol when read-
ing the symbol table of an executable.

On non-BSD systems, you must arrange communication
with GDB in some other fashion. If GDB is not
used on your system, you can define this macro
with an empty body.

ASM_COMMENT_START
A C string constant describing how to begin a com-
ment in the target assembler language. The com-
piler assumes that the comment will end at the end
of the line.

ASM_APP_ON
A C string constant for text to be output before













each asm statement or group of consecutive ones.
Normally this is "#APP", which is a comment that
has no effect on most assemblers but tells the GNU
assembler that it must check the lines that follow
for all valid assembler constructs.

ASM_APP_OFF
A C string constant for text to be output after
each asm statement or group of consecutive ones.
Normally this is "#NO_APP", which tells the GNU
assembler to resume making the time-saving assump-
tions that are valid for ordinary compiler output.

ASM_OUTPUT_SOURCE_FILENAME (stream, name)
A C statement to output COFF information or DWARF
debugging information which indicates that
filename name is the current source file to the
stdio stream stream.

This macro need not be defined if the standard
form of output for the file format in use is ap-
propriate.

ASM_OUTPUT_SOURCE_LINE (stream, line)
A C statement to output DBX or SDB debugging in-
formation before code for line number line of the
current source file to the stdio stream stream.

This macro need not be defined if the standard
form of debugging information for the debugger in
use is appropriate.

ASM_OUTPUT_IDENT (stream, string)
A C statement to output something to the assembler
file to handle a `#ident' directive containing the
text string. If this macro is not defined, noth-
ing is output for a `#ident' directive.

OBJC_PROLOGUE
A C statement to output any assembler statements
which are required to precede any Objective C ob-
ject definitions or message sending. The state-
ment is executed only when compiling an Objective
C program.


1.16.2. Output of Data

ASM_OUTPUT_LONG_DOUBLE (stream, value)

ASM_OUTPUT_DOUBLE (stream, value)















ASM_OUTPUT_FLOAT (stream, value)
A C statement to output to the stdio stream stream
an assembler instruction to assemble a floating-
point constant of TFmode, DFmode or SFmode,
respectively, whose value is value. value will be
a C expression of type REAL_VALUE__TYPE, usually
double.

ASM_OUTPUT_QUADRUPLE_INT (stream, exp)

ASM_OUTPUT_DOUBLE_INT (stream, exp)

ASM_OUTPUT_INT (stream, exp)

ASM_OUTPUT_SHORT (stream, exp)

ASM_OUTPUT_CHAR (stream, exp)
A C statement to output to the stdio stream stream
an assembler instruction to assemble an integer of
16, 8, 4, 2 or 1 bytes, respectively, whose value
is value. The argument exp will be an RTL expres-
sion which represents a constant value. Use
`output_addr_const (stream, exp)' to output this
value as an assembler expression.

For sizes larger than UNITS_PER_WORD, if the ac-
tion of a macro would be identical to repeatedly
calling the macro corresponding to a size of
UNITS_PER_WORD, once for each word, you need not
define the macro.

ASM_OUTPUT_BYTE (stream, value)
A C statement to output to the stdio stream stream
an assembler instruction to assemble a single byte
containing the number value.

ASM_BYTE_OP
A C string constant giving the pseudo-op to use
for a sequence of single-byte constants. If this
macro is not defined, the default is "byte".

ASM_OUTPUT_ASCII (stream, ptr, len)
A C statement to output to the stdio stream stream
an assembler instruction to assemble a string con-
stant containing the len bytes at ptr. ptr will
be a C expression of type char * and len a C ex-
pression of type int.

If the assembler has a .ascii pseudo-op as found
in the Berkeley Unix assembler, do not define the
macro ASM_OUTPUT_ASCII.















ASM_OUTPUT_POOL_PROLOGUE (file funname fundecl size)
A C statement to output assembler commands to de-
fine the start of the constant pool for a func-
tion. funname is a string giving the name of the
function. Should the return type of the function
be required, it can be obtained via fundecl. size
is the size, in bytes, of the constant pool that
will be written immediately after this call.

If no constant-pool prefix is required, the usual
case, this macro need not be defined.

ASM_OUTPUT_SPECIAL_POOL_ENTRY (file, x, mode, align, labelno, jumpto)
A C statement (with or without semicolon) to out-
put a constant in the constant pool, if it needs
special treatment. (This macro need not do any-
thing for RTL expressions that can be output nor-
mally.)

The argument file is the standard I/O stream to
output the assembler code on. x is the RTL ex-
pression for the constant to output, and mode is
the machine mode (in case x is a `const_int').
align is the required alignment for the value x;
you should output an assembler directive to force
this much alignment.

The argument labelno is a number to use in an
internal label for the address of this pool entry.
The definition of this macro is responsible for
outputting the label definition at the proper
place. Here is how to do this:


ASM_OUTPUT_INTERNAL_LABEL (file, "LC", labelno);



When you output a pool entry specially, you
should end with a goto to the label jumpto.
This will prevent the same pool entry from be-
ing output a second time in the usual manner.

You need not define this macro if it would do
nothing.

ASM_OPEN_PAREN

ASM_CLOSE_PAREN
These macros are defined as C string constant,
describing the syntax in the assembler for
grouping arithmetic expressions. The follow-
ing definitions are correct for most assem-













blers:


#define ASM_OPEN_PAREN "("
#define ASM_CLOSE_PAREN ")"




1.16.3. Output of Uninitialized Variables

Each of the macros in this section is used to do the
whole job of outputting a single uninitialized variable.

ASM_OUTPUT_COMMON (stream, name, size, rounded)
A C statement (sans semicolon) to output to the
stdio stream stream the assembler definition of a
common-label named name whose size is size bytes.
The variable rounded is the size rounded up to
whatever alignment the caller wants.

Use the expression assemble_name (stream, name) to
output the name itself; before and after that,
output the additional assembler syntax for defin-
ing the name, and a newline.

This macro controls how the assembler definitions
of uninitialized global variables are output.

ASM_OUTPUT_ALIGNED_COMMON (stream, name, size, alignment)
Like ASM_OUTPUT_COMMON except takes the required
alignment as a separate, explicit argument. If
you define this macro, it is used in place of
ASM_OUTPUT_COMMON, and gives you more flexibility
in handling the required alignment of the vari-
able.

ASM_OUTPUT_SHARED_COMMON (stream, name, size, rounded)
If defined, it is similar to ASM_OUTPUT_COMMON,
except that it is used when name is shared. If
not defined, ASM_OUTPUT_COMMON will be used.

ASM_OUTPUT_LOCAL (stream, name, size, rounded)
A C statement (sans semicolon) to output to the
stdio stream stream the assembler definition of a
local-common-label named name whose size is size
bytes. The variable rounded is the size rounded
up to whatever alignment the caller wants.

Use the expression assemble_name (stream, name) to
output the name itself; before and after that,
output the additional assembler syntax for defin-
ing the name, and a newline.













This macro controls how the assembler definitions
of uninitialized static variables are output.

ASM_OUTPUT_ALIGNED_LOCAL (stream, name, size, alignment)
Like ASM_OUTPUT_LOCAL except takes the required
alignment as a separate, explicit argument. If
you define this macro, it is used in place of
ASM_OUTPUT_LOCAL, and gives you more flexibility
in handling the required alignment of the vari-
able.

ASM_OUTPUT_SHARED_LOCAL (stream, name, size, rounded)
If defined, it is similar to ASM_OUTPUT_LOCAL, ex-
cept that it is used when name is shared. If not
defined, ASM_OUTPUT_LOCAL will be used.


1.16.4. Output and Generation of Labels

ASM_OUTPUT_LABEL (stream, name)
A C statement (sans semicolon) to output to the
stdio stream stream the assembler definition of a
label named name. Use the expression
assemble_name (stream, name) to output the name
itself; before and after that, output the addi-
tional assembler syntax for defining the name, and
a newline.

ASM_DECLARE_FUNCTION_NAME (stream, name, decl)
A C statement (sans semicolon) to output to the
stdio stream stream any text necessary for declar-
ing the name name of a function which is being de-
fined. This macro is responsible for outputting
the label definition (perhaps using
ASM_OUTPUT_LABEL). The argument decl is the
FUNCTION_DECL tree node representing the function.

If this macro is not defined, then the function
name is defined in the usual manner as a label (by
means of ASM_OUTPUT_LABEL).

ASM_DECLARE_FUNCTION_SIZE (stream, name, decl)
A C statement (sans semicolon) to output to the
stdio stream stream any text necessary for declar-
ing the size of a function which is being defined.
The argument name is the name of the function.
The argument decl is the FUNCTION_DECL tree node
representing the function.

If this macro is not defined, then the function
size is not defined.















ASM_DECLARE_OBJECT_NAME (stream, name, decl)
A C statement (sans semicolon) to output to the
stdio stream stream any text necessary for declar-
ing the name name of an initialized variable which
is being defined. This macro must output the la-
bel definition (perhaps using ASM_OUTPUT_LABEL).
The argument decl is the VAR_DECL tree node
representing the variable.

If this macro is not defined, then the variable
name is defined in the usual manner as a label (by
means of ASM_OUTPUT_LABEL).

ASM_GLOBALIZE_LABEL (stream, name)
A C statement (sans semicolon) to output to the
stdio stream stream some commands that will make
the label name global; that is, available for
reference from other files. Use the expression
assemble_name (stream, name) to output the name
itself; before and after that, output the addi-
tional assembler syntax for making that name glo-
bal, and a newline.

ASM_OUTPUT_EXTERNAL (stream, decl, name)
A C statement (sans semicolon) to output to the
stdio stream stream any text necessary for declar-
ing the name of an external symbol named name
which is referenced in this compilation but not
defined. The value of decl is the tree node for
the declaration.

This macro need not be defined if it does not need
to output anything. The GNU assembler and most
Unix assemblers don't require anything.

ASM_OUTPUT_EXTERNAL_LIBCALL (stream, symref)
A C statement (sans semicolon) to output on stream
an assembler pseudo-op to declare a library func-
tion name external. The name of the library func-
tion is given by symref, which has type rtx and is
a symbol_ref.

This macro need not be defined if it does not need
to output anything. The GNU assembler and most
Unix assemblers don't require anything.

ASM_OUTPUT_LABELREF (stream, name)
A C statement (sans semicolon) to output to the
stdio stream stream a reference in assembler syn-
tax to a label named name. This should add `_' to
the front of the name, if that is customary on
your operating system, as it is in most Berkeley
Unix systems. This macro is used in













assemble_name.

ASM_OUTPUT_LABELREF_AS_INT (file, label)
Define this macro for systems that use the program
collect2. The definition should be a C statement
to output a word containing a reference to the la-
bel label.

ASM_GENERATE_INTERNAL_LABEL (string, prefix, num)
A C statement to store into the string string a
label whose name is made from the string prefix
and the number num.

This string, when output subsequently by
ASM_OUTPUT_LABELREF, should produce the same out-
put that ASM_OUTPUT_INTERNAL_LABEL would produce
with the same prefix and num.

ASM_OUTPUT_INTERNAL_LABEL (stream, prefix, num)
A C statement to output to the stdio stream stream
a label whose name is made from the string prefix
and the number num. These labels are used for
internal purposes, and there is no reason for them
to appear in the symbol table of the object file.
On many systems, the letter `L' at the beginning
of a label has this effect. The usual definition
of this macro is as follows:


fprintf (stream, "L%s%d:\n", prefix, num)



ASM_FORMAT_PRIVATE_NAME (outvar, name, number)
A C expression to assign to outvar (which is a
variable of type char *) a newly allocated
string made from the string name and the
number number, with some suitable punctuation
added. Use alloca to get space for the
string.

This string will be used as the argument to
ASM_OUTPUT_LABELREF to produce an assembler
label for an internal static variable whose
name is name. Therefore, the string must be
such as to result in valid assembler code.
The argument number is different each time
this macro is executed; it prevents conflicts
between similarly-named internal static vari-
ables in different scopes.

Ideally this string should not be a valid C
identifier, to prevent any conflict with the













user's own symbols. Most assemblers allow
periods or percent signs in assembler symbols;
putting at least one of these between the name
and the number will suffice.

OBJC_GEN_METHOD_LABEL (buf, is_inst, class_name, cat_name, sel_name)
Define this macro to override the default as-
sembler names used for Objective C methods.

The default name is a unique method number
followed by the name of the class (e.g.
`_1_Foo'). For methods in categories, the
name of the category is also included in the
assembler name (e.g. `_1_Foo_Bar').

These names are safe on most systems, but make
debugging difficult since the method's selec-
tor is not present in the name. Therefore,
particular systems define other ways of com-
puting names.

buf is a buffer in which to store the name
(256 chars max); is_inst specifies whether the
method is an instance method or a class
method; class_name is the name of the class;
cat_name is the name of the category (or NULL
if the method is not in a category); and
sel_name is the name of the selector.

On systems where the assembler can handle
quoted names, you can use this macro to pro-
vide more human-readable names.


1.16.5. Output of Initialization Routines

The compiled code for certain languages includes con-
structors (also called initialization routines)---functions
to initialize data in the program when the program is
started. These functions need to be called before the pro-
gram is ``started''---that is to say, before main is called.

Compiling some languages generates destructors (also
called termination routines) that should be called when the
program terminates.

To make the initialization and termination functions
work, the compiler must output something in the assembler
code to cause those functions to be called at the appropri-
ate time. When you port the compiler to a new system, you
need to specify what assembler code is needed to do this.















Here are the two macros you should define if necessary:

ASM_OUTPUT_CONSTRUCTOR (stream, name)
Define this macro as a C statement to output on
the stream stream the assembler code to arrange to
call the function named name at initialization
time.

Assume that name is the name of a C function gen-
erated automatically by the compiler. This func-
tion takes no arguments. Use the function
assemble_name to output the name name; this per-
forms any system-specific syntactic transforma-
tions such as adding an underscore.

If you don't define this macro, nothing special is
output to arrange to call the function. This is
correct when the function will be called in some
other manner---for example, by means of the col-
lect program, which looks through the symbol table
to find these functions by their names. If you
want to use collect, then you need to arrange for
it to be built and installed and used on your sys-
tem.

ASM_OUTPUT_DESTRUCTOR (stream, name)
This is like ASM_OUTPUT_CONSTRUCTOR but used for
termination functions rather than initialization
functions.


1.16.6. Output of Assembler Instructions

REGISTER_NAMES
A C initializer containing the assembler's names
for the machine registers, each one as a C string
constant. This is what translates register
numbers in the compiler into assembler language.

ADDITIONAL_REGISTER_NAMES
If defined, a C initializer for an array of struc-
tures containing a name and a register number.
This macro defines additional names for hard re-
gisters, thus allowing the asm option in declara-
tions to refer to registers using alternate names.

ASM_OUTPUT_OPCODE (stream, ptr)
Define this macro if you are using an unusual as-
sembler that requires different names for the
machine instructions.

The definition is a C statement or statements
which output an assembler instruction opcode to













the stdio stream stream. The macro-operand ptr is
a variable of type char * which points to the op-
code name in its ``internal'' form---the form that
is written in the machine description. The defin-
ition should output the opcode name to stream,
performing any translation you desire, and incre-
ment the variable ptr to point at the end of the
opcode so that it will not be output twice.

In fact, your macro definition may process less
than the entire opcode name, or more than the op-
code name; but if you want to process text that
includes `%'-sequences to substitute operands, you
must take care of the substitution yourself. Just
be sure to increment ptr over whatever text should
not be output normally.

If you need to look at the operand values, they
can be found as the elements of recog_operand.

If the macro definition does nothing, the instruc-
tion is output in the usual way.

FINAL_PRESCAN_INSN (insn, opvec, noperands)
If defined, a C statement to be executed just pri-
or to the output of assembler code for insn, to
modify the extracted operands so they will be out-
put differently.

Here the argument opvec is the vector containing
the operands extracted from insn, and noperands is
the number of elements of the vector which contain
meaningful data for this insn. The contents of
this vector are what will be used to convert the
insn template into assembler code, so you can
change the assembler output by changing the con-
tents of the vector.

This macro is useful when various assembler syn-
taxes share a single file of instruction patterns;
by defining this macro differently, you can cause
a large class of instructions to be output dif-
ferently (such as with rearranged operands). Na-
turally, variations in assembler syntax affecting
individual insn patterns ought to be handled by
writing conditional output routines in those pat-
terns.

If this macro is not defined, it is equivalent to
a null statement.

PRINT_OPERAND (stream, x, code)
A C compound statement to output to stdio stream













stream the assembler syntax for an instruction
operand x. x is an RTL expression.

code is a value that can be used to specify one of
several ways of printing the operand. It is used
when identical operands must be printed different-
ly depending on the context. code comes from the
`%' specification that was used to request print-
ing of the operand. If the specification was just
`%digit' then code is 0; if the specification was
`%ltr digit' then code is the ASCII code for ltr.

If x is a register, this macro should print the
register's name. The names can be found in an ar-
ray reg_names whose type is char *[]. reg_names
is initialized from REGISTER_NAMES.

When the machine description has a specification
`%punct' (a `%' followed by a punctuation charac-
ter), this macro is called with a null pointer for
x and the punctuation character for code.

PRINT_OPERAND_PUNCT_VALID_P (code)
A C expression which evaluates to true if code is
a valid punctuation character for use in the
PRINT_OPERAND macro. If
PRINT_OPERAND_PUNCT_VALID_P is not defined, it
means that no punctuation characters (except for
the standard one, `%') are used in this way.

PRINT_OPERAND_ADDRESS (stream, x)
A C compound statement to output to stdio stream
stream the assembler syntax for an instruction
operand that is a memory reference whose address
is x. x is an RTL expression.

On some machines, the syntax for a symbolic ad-
dress depends on the section that the address
refers to. On these machines, define the macro
ENCODE_SECTION_INFO to store the information into
the symbol_ref, and then check for it here. See
section Assembler Format.

DBR_OUTPUT_SEQEND(file)
A C statement, to be executed after all slot-
filler instructions have been output. If neces-
sary, call dbr_sequence_length to determine the
number of slots filled in a sequence (zero if not
currently outputting a sequence), to decide how
many no-ops to output, or whatever.

Don't define this macro if it has nothing to do,
but it is helpful in reading assembly output if













the extent of the delay sequence is made explicit
(e.g. with white space).

Note that output routines for instructions with
delay slots must be prepared to deal with not be-
ing output as part of a sequence (i.e. when the
scheduling pass is not run, or when no slot fill-
ers could be found.) The variable final_sequence
is null when not processing a sequence, otherwise
it contains the sequence rtx being output.

REGISTER_PREFIX

LOCAL_LABEL_PREFIX

USER_LABEL_PREFIX

IMMEDIATE_PREFIX
If defined, C string expressions to be used for
the `%R', `%L', `%U', and `%I' options of
asm_fprintf (see `final.c'). These are useful
when a single `md' file must support multiple as-
sembler formats. In that case, the various `tm.h'
files can define these macros differently.

ASM_OUTPUT_REG_PUSH (stream, regno)
A C expression to output to stream some assembler
code which will push hard register number regno
onto the stack. The code need not be optimal,
since this macro is used only when profiling.

ASM_OUTPUT_REG_POP (stream, regno)
A C expression to output to stream some assembler
code which will pop hard register number regno off
of the stack. The code need not be optimal, since
this macro is used only when profiling.


1.16.7. Output of Dispatch Tables

ASM_OUTPUT_ADDR_DIFF_ELT (stream, value, rel)
This macro should be provided on machines where
the addresses in a dispatch table are relative to
the table's own address.

The definition should be a C statement to output
to the stdio stream stream an assembler pseudo-
instruction to generate a difference between two
labels. value and rel are the numbers of two
internal labels. The definitions of these labels
are output using ASM_OUTPUT_INTERNAL_LABEL, and
they must be printed in the same way here. For
example,














fprintf (stream, "\t.word L%d-L%d\n",
value, rel)



ASM_OUTPUT_ADDR_VEC_ELT (stream, value)
This macro should be provided on machines
where the addresses in a dispatch table are
absolute.

The definition should be a C statement to out-
put to the stdio stream stream an assembler
pseudo-instruction to generate a reference to
a label. value is the number of an internal
label whose definition is output using
ASM_OUTPUT_INTERNAL_LABEL. For example,


fprintf (stream, "\t.word L%d\n", value)



ASM_OUTPUT_CASE_LABEL (stream, prefix, num, table)
Define this if the label before a jump-table
needs to be output specially. The first three
arguments are the same as for
ASM_OUTPUT_INTERNAL_LABEL; the fourth argument
is the jump-table which follows (a jump_insn
containing an addr_vec or addr_diff_vec).

This feature is used on system V to output a
swbeg statement for the table.

If this macro is not defined, these labels are
output with ASM_OUTPUT_INTERNAL_LABEL.

ASM_OUTPUT_CASE_END (stream, num, table)
Define this if something special must be out-
put at the end of a jump-table. The defini-
tion should be a C statement to be executed
after the assembler code for the table is
written. It should write the appropriate code
to stdio stream stream. The argument table is
the jump-table insn, and num is the label-
number of the preceding label.

If this macro is not defined, nothing special
is output at the end of the jump-table.

















1.16.8. Assembler Commands for Alignment

ASM_OUTPUT_ALIGN_CODE (file)
A C expression to output text to align the loca-
tion counter in the way that is desirable at a
point in the code that is reached only by jumping.

This macro need not be defined if you don't want
any special alignment to be done at such a time.
Most machine descriptions do not currently define
the macro.

ASM_OUTPUT_LOOP_ALIGN (file)
A C expression to output text to align the loca-
tion counter in the way that is desirable at the
beginning of a loop.

This macro need not be defined if you don't want
any special alignment to be done at such a time.
Most machine descriptions do not currently define
the macro.

ASM_OUTPUT_SKIP (stream, nbytes)
A C statement to output to the stdio stream stream
an assembler instruction to advance the location
counter by nbytes bytes. Those bytes should be
zero when loaded. nbytes will be a C expression
of type int.

ASM_NO_SKIP_IN_TEXT
Define this macro if ASM_OUTPUT_SKIP should not be
used in the text section because it fails put
zeros in the bytes that are skipped. This is true
on many Unix systems, where the pseudo--op to skip
bytes produces no-op instructions rather than
zeros when used in the text section.

ASM_OUTPUT_ALIGN (stream, power)
A C statement to output to the stdio stream stream
an assembler command to advance the location
counter to a multiple of 2 to the power bytes.
power will be a C expression of type int.


1.17. Controlling Debugging Information Format

DBX_REGISTER_NUMBER (regno)
A C expression that returns the DBX register
number for the compiler register number regno. In
simple cases, the value of this expression may be
regno itself. But sometimes there are some regis-
ters that the compiler knows about and DBX does
not, or vice versa. In such cases, some register













may need to have one number in the compiler and
another for DBX.

If two registers have consecutive numbers inside
GNU CC, and they can be used as a pair to hold a
multiword value, then they must have consecutive
numbers after renumbering with
DBX_REGISTER_NUMBER. Otherwise, debuggers will be
unable to access such a pair, because they expect
register pairs to be consecutive in their own
numbering scheme.

If you find yourself defining DBX_REGISTER_NUMBER
in way that does not preserve register pairs, then
what you must do instead is redefine the actual
register numbering scheme.

DBX_DEBUGGING_INFO
Define this macro if GNU CC should produce debug-
ging output for DBX in response to the `-g' op-
tion.

SDB_DEBUGGING_INFO
Define this macro if GNU CC should produce COFF-
style debugging output for SDB in response to the
`-g' option.

DWARF_DEBUGGING_INFO
Define this macro if GNU CC should produce dwarf
format debugging output in response to the `-g'
option.

DEFAULT_GDB_EXTENSIONS
Define this macro to control whether GNU CC should
by default generate GDB's extended version of DBX
debugging information (assuming DBX-format debug-
ging information is enabled at all). If you don't
define the macro, the default is 1: always gen-
erate the extended information.

DEBUG_SYMS_TEXT
Define this macro if all .stabs commands should be
output while in the text section.

DEBUGGER_AUTO_OFFSET (x)
A C expression that returns the integer offset
value for an automatic variable having address x
(an RTL expression). The default computation as-
sumes that x is based on the frame-pointer and
gives the offset from the frame-pointer. This is
required for targets that produce debugging output
for DBX or COFF-style debugging output for SDB and
allow the frame-pointer to be eliminated when the













`-g' options is used.

DEBUGGER_ARG_OFFSET (offset, x)
A C expression that returns the integer offset
value for an argument having address x (an RTL ex-
pression). The nominal offset is offset.

ASM_STABS_OP
A C string constant naming the assembler pseudo op
to use instead of .stabs to define an ordinary de-
bugging symbol. If you don't define this macro,
.stabs is used. This macro applies only to DBX
debugging information format.

ASM_STABD_OP
A C string constant naming the assembler pseudo op
to use instead of .stabd to define a debugging
symbol whose value is the current location. If
you don't define this macro, .stabd is used. This
macro applies only to DBX debugging information
format.

ASM_STABN_OP
A C string constant naming the assembler pseudo op
to use instead of .stabn to define a debugging
symbol with no name. If you don't define this
macro, .stabn is used. This macro applies only to
DBX debugging information format.

PUT_SDB_...
Define these macros to override the assembler syn-
tax for the special SDB assembler directives. See
`sdbout.c' for a list of these macros and their
arguments. If the standard syntax is used, you
need not define them yourself.

SDB_DELIM
Some assemblers do not support a semicolon as a
delimiter, even between SDB assembler directives.
In that case, define this macro to be the delim-
iter to use (usually `\n'). It is not necessary
to define a new set of PUT_SDB_op macros if this
is the only change required.

SDB_GENERATE_FAKE
Define this macro to override the usual method of
constructing a dummy name for anonymous structure
and union types. See `sdbout.c' for more informa-
tion.

SDB_ALLOW_UNKNOWN_REFERENCES
Define this macro to allow references to unknown
structure, union, or enumeration tags to be emit-













ted. Standard COFF does not allow handling of
unknown references, MIPS ECOFF has support for it.

SDB_ALLOW_FORWARD_REFERENCES
Define this macro to allow references to struc-
ture, union, or enumeration tags that have not yet
been seen to be handled. Some assemblers choke if
forward tags are used, while some require it.

DBX_NO_XREFS
Define this macro if DBX on your system does not
support the construct `xstagname'. On some sys-
tems, this construct is used to describe a forward
reference to a structure named tagname. On other
systems, this construct is not supported at all.

DBX_CONTIN_LENGTH
A symbol name in DBX-format debugging information
is normally continued (split into two separate
.stabs directives) when it exceeds a certain
length (by default, 80 characters). On some
operating systems, DBX requires this splitting; on
others, splitting must not be done. You can inhi-
bit splitting by defining this macro with the
value zero. You can override the default
splitting-length by defining this macro as an ex-
pression for the length you desire.

DBX_CONTIN_CHAR
Normally continuation is indicated by adding a `\'
character to the end of a .stabs string when a
continuation follows. To use a different charac-
ter instead, define this macro as a character con-
stant for the character you want to use. Do not
define this macro if backslash is correct for your
system.

DBX_STATIC_STAB_DATA_SECTION
Define this macro if it is necessary to go to the
data section before outputting the `.stabs'
pseudo-op for a non-global static variable.

DBX_LBRAC_FIRST
Define this macro if the N_LBRAC symbol for a
block should precede the debugging information for
variables and functions defined in that block.
Normally, in DBX format, the N_LBRAC symbol comes
first.

DBX_FUNCTION_FIRST
Define this macro if the DBX information for a
function and its arguments should precede the as-
sembler code for the function. Normally, in DBX













format, the debugging information entirely follows
the assembler code.

DBX_OUTPUT_FUNCTION_END (stream, function)
Define this macro if the target machine requires
special output at the end of the debugging infor-
mation for a function. The definition should be a
C statement (sans semicolon) to output the ap-
propriate information to stream. function is the
FUNCTION_DECL node for the function.

DBX_OUTPUT_STANDARD_TYPES (syms)
Define this macro if you need to control the order
of output of the standard data types at the begin-
ning of compilation. The argument syms is a tree
which is a chain of all the predefined global sym-
bols, including names of data types.

Normally, DBX output starts with definitions of
the types for integers and characters, followed by
all the other predefined types of the particular
language in no particular order.

On some machines, it is necessary to output dif-
ferent particular types first. To do this, define
DBX_OUTPUT_STANDARD_TYPES to output those symbols
in the necessary order. Any predefined types that
you don't explicitly output will be output after-
ward in no particular order.

Be careful not to define this macro so that it
works only for C. There are no global variables
to access most of the built-in types, because
another language may have another set of types.
The way to output a particular type is to look
through syms to see if you can find it. Here is
an example:


{
tree decl;
for (decl = syms; decl; decl = TREE_CHAIN (decl))
if (!strcmp (IDENTIFIER_POINTER (DECL_NAME (decl)), "long int"))
dbxout_symbol (decl);
...
}



This does nothing if the expected type does not ex-
ist.















See the function init_decl_processing in
source file `c-decl.c' to find the names to
use for all the built-in C types.

DBX_OUTPUT_MAIN_SOURCE_FILENAME (stream, name)
A C statement to output DBX debugging informa-
tion to the stdio stream stream which indi-
cates that file name is the main source file-
--the file specified as the input file for
compilation. This macro is called only once,
at the beginning of compilation.

This macro need not be defined if the standard
form of output for DBX debugging information
is appropriate.

DBX_OUTPUT_MAIN_SOURCE_DIRECTORY (stream, name)
A C statement to output DBX debugging informa-
tion to the stdio stream stream which indi-
cates that the current directory during compi-
lation is named name.

This macro need not be defined if the standard
form of output for DBX debugging information
is appropriate.

DBX_OUTPUT_MAIN_SOURCE_FILE_END (stream, name)
A C statement to output DBX debugging informa-
tion at the end of compilation of the main
source file name.

If you don't define this macro, nothing spe-
cial is output at the end of compilation,
which is correct for most machines.

DBX_OUTPUT_SOURCE_FILENAME (stream, name)
A C statement to output DBX debugging informa-
tion to the stdio stream stream which indi-
cates that file name is the current source
file. This output is generated each time in-
put shifts to a different source file as a
result of `#include', the end of an included
file, or a `#line' command.

This macro need not be defined if the standard
form of output for DBX debugging information
is appropriate.


1.18. Cross Compilation and Floating Point Format

While all modern machines use 2's complement represen-
tation for integers, there are a variety of representations













for floating point numbers. This means that in a cross-
compiler the representation of floating point numbers in the
compiled program may be different from that used in the
machine doing the compilation.

Because different representation systems may offer dif-
ferent amounts of range and precision, the cross compiler
cannot safely use the host machine's floating point arith-
metic. Therefore, floating point constants must be
represented in the target machine's format. This means that
the cross compiler cannot use atof to parse a floating point
constant; it must have its own special routine to use
instead. Also, constant folding must emulate the target
machine's arithmetic (or must not be done at all).

The macros in the following table should be defined
only if you are cross compiling between different floating
point formats.

Otherwise, don't define them. Then default definitions
will be set up which use double as the data type, == to test
for equality, etc.

You don't need to worry about how many times you use an
operand of any of these macros. The compiler never uses
operands which have side effects.

REAL_VALUE_TYPE
A macro for the C data type to be used to hold a
floating point value in the target machine's for-
mat. Typically this would be a struct containing
an array of int.

REAL_VALUES_EQUAL (x, y)
A macro for a C expression which compares for
equality the two values, x and y, both of type
REAL_VALUE_TYPE.

REAL_VALUES_LESS (x, y)
A macro for a C expression which tests whether x
is less than y, both values being of type
REAL_VALUE_TYPE and interpreted as floating point
numbers in the target machine's representation.

REAL_VALUE_LDEXP (x, scale)
A macro for a C expression which performs the
standard library function ldexp, but using the
target machine's floating point representation.
Both x and the value of the expression have type
REAL_VALUE_TYPE. The second argument, scale, is
an integer.















REAL_VALUE_FIX (x)
A macro whose definition is a C expression to con-
vert the target-machine floating point value x to
a signed integer. x has type REAL_VALUE_TYPE.

REAL_VALUE_UNSIGNED_FIX (x)
A macro whose definition is a C expression to con-
vert the target-machine floating point value x to
an unsigned integer. x has type REAL_VALUE_TYPE.

REAL_VALUE_FIX_TRUNCATE (x)
A macro whose definition is a C expression to con-
vert the target-machine floating point value x to
a signed integer, rounding toward 0. x has type
REAL_VALUE_TYPE.

REAL_VALUE_UNSIGNED_FIX_TRUNCATE (x)
A macro whose definition is a C expression to con-
vert the target-machine floating point value x to
an unsigned integer, rounding toward 0. x has
type REAL_VALUE_TYPE.

REAL_VALUE_ATOF (string)
A macro for a C expression which converts string,
an expression of type char *, into a floating
point number in the target machine's representa-
tion. The value has type REAL_VALUE_TYPE.

REAL_INFINITY
Define this macro if infinity is a possible float-
ing point value, and therefore division by 0 is
legitimate.

REAL_VALUE_ISINF (x)
A macro for a C expression which determines wheth-
er x, a floating point value, is infinity. The
value has type int. By default, this is defined
to call isinf.

REAL_VALUE_ISNAN (x)
A macro for a C expression which determines wheth-
er x, a floating point value, is a ``nan'' (not-
a-number). The value has type int. By default,
this is defined to call isnan.


Define the following additional macros if you want to
make floating point constant folding work while cross com-
piling. If you don't define them, cross compilation is
still possible, but constant folding will not happen for
floating point values.















REAL_ARITHMETIC (output, code, x, y)
A macro for a C statement which calculates an ar-
ithmetic operation of the two floating point
values x and y, both of type REAL_VALUE_TYPE in
the target machine's representation, to produce a
result of the same type and representation which
is stored in output (which will be a variable).

The operation to be performed is specified by
code, a tree code which will always be one of the
following: PLUS_EXPR, MINUS_EXPR, MULT_EXPR,
RDIV_EXPR, MAX_EXPR, MIN_EXPR.

The expansion of this macro is responsible for
checking for overflow. If overflow happens, the
macro expansion should execute the statement re-
turn 0;, which indicates the inability to perform
the arithmetic operation requested.

REAL_VALUE_NEGATE (x)
A macro for a C expression which returns the nega-
tive of the floating point value x. Both x and
the value of the expression have type
REAL_VALUE_TYPE and are in the target machine's
floating point representation.

There is no way for this macro to report overflow,
since overflow can't happen in the negation opera-
tion.

REAL_VALUE_TRUNCATE (x)
A macro for a C expression which converts the
double-precision floating point value x to
single-precision.

Both x and the value of the expression have type
REAL_VALUE_TYPE and are in the target machine's
floating point representation. However, the value
should have an appropriate bit pattern to be out-
put properly as a single-precision floating con-
stant.

There is no way for this macro to report overflow.

REAL_VALUE_TO_INT (low, high, x)
A macro for a C expression which converts a float-
ing point value x into a double-precision integer
which is then stored into low and high, two vari-
ables of type int.

REAL_VALUE_FROM_INT (x, low, high)
A macro for a C expression which converts a
double-precision integer found in low and high,













two variables of type int, into a floating point
value which is then stored into x.


1.19. Miscellaneous Parameters

PREDICATE_CODES
Optionally define this if you have added predi-
cates to `machine.c'. This macro is called within
an initializer of an array of structures. The
first field in the structure is the name of a
predicate and the second field is an arrary of rtl
codes. For each predicate, list all rtl codes
that can be in expressions matched by the predi-
cate. The list should have a trailing comma.
Here is an example of two entries in the list for
a typical RISC machine:


#define PREDICATE_CODES \
{"gen_reg_rtx_operand", {SUBREG, REG}}, \
{"reg_or_short_cint_operand", {SUBREG, REG, CONST_INT}},



Defining this macro does not affect the gen-
erated code (however, incorrect definitions
that omit an rtl code that may be matched by
the predicate can cause the compiler to mal-
function). Instead, it allows the table built
by `genrecog' to be more compact and effi-
cient, thus speeding up the compiler. The
most important predicates to include in the
list specified by this macro are thoses used
in the most insn patterns.

CASE_VECTOR_MODE
An alias for a machine mode name. This is the
machine mode that elements of a jump-table
should have.

CASE_VECTOR_PC_RELATIVE
Define this macro if jump-tables should con-
tain relative addresses.

CASE_DROPS_THROUGH
Define this if control falls through a case
insn when the index value is out of range.
This means the specified default-label is ac-
tually ignored by the case insn proper.

BYTE_LOADS_ZERO_EXTEND
Define this macro if an instruction to load a













value narrower than a word from memory into a
register also zero-extends the value to the
whole register.

IMPLICIT_FIX_EXPR
An alias for a tree code that should be used
by default for conversion of floating point
values to fixed point. Normally,
FIX_ROUND_EXPR is used.

FIXUNS_TRUNC_LIKE_FIX_TRUNC
Define this macro if the same instructions
that convert a floating point number to a
signed fixed point number also convert validly
to an unsigned one.

EASY_DIV_EXPR
An alias for a tree code that is the easiest
kind of division to compile code for in the
general case. It may be TRUNC_DIV_EXPR,
FLOOR_DIV_EXPR, CEIL_DIV_EXPR or
ROUND_DIV_EXPR. These four division operators
differ in how they round the result to an in-
teger. EASY_DIV_EXPR is used when it is per-
missible to use any of those kinds of division
and the choice should be made on the basis of
efficiency.

MOVE_MAX
The maximum number of bytes that a single in-
struction can move quickly from memory to
memory.

SHIFT_COUNT_TRUNCATED
Defining this macro causes the compiler to
omit a sign-extend, zero-extend, or bitwise
`and' instruction that truncates the count of
a shift operation to a width equal to the
number of bits needed to represent the size of
the object being shifted. On machines that
have instructions that act on bitfields at
variable positions, including `bit test' in-
structions, defining SHIFT_COUNT_TRUNCATED
also causes truncation not to be applied to
these instructions.

If both types of instructions truncate the
count (for shifts) and position (for bitfield
operations), or if no variable-position bit-
field instructions exist, you should define
this macro.















However, on some machines, such as the 80386,
truncation only applies to shift operations
and not bitfield operations. Do not define
SHIFT_COUNT_TRUNCATED on such machines. In-
stead, add patterns to the `md' file that in-
clude the implied truncation of the shift in-
structions.

TRULY_NOOP_TRUNCATION (outprec, inprec)
A C expression which is nonzero if on this
machine it is safe to ``convert'' an integer
of inprec bits to one of outprec bits (where
outprec is smaller than inprec) by merely
operating on it as if it had only outprec
bits.

On many machines, this expression can be 1.

It is reported that suboptimal code can result
when TRULY_NOOP_TRUNCATION returns 1 for a
pair of sizes for modes for which
MODES_TIEABLE_P is 0. If this is the case,
making TRULY_NOOP_TRUNCATION return 0 in such
cases may improve things.

STORE_FLAG_VALUE
A C expression describing the value returned
by a comparison operator and stored by a
store-flag instruction (`scond') when the con-
dition is true. This description must apply
to all the `scond' patterns and all the com-
parison operators.

A value of 1 or -1 means that the instruction
implementing the comparison operator returns
exactly 1 or -1 when the comparison is true
and 0 when the comparison is false. Other-
wise, the value indicates which bits of the
result are guaranteed to be 1 when the com-
parison is true. This value is interpreted in
the mode of the comparison operation, which is
given by the mode of the first operand in the
`scond' pattern. Either the low bit or the
sign bit of STORE_FLAG_VALUE be on. Present-
ly, only those bits are used by the compiler.

If STORE_FLAG_VALUE is neither 1 or -1, the
compiler will generate code that depends only
on the specified bits. It can also replace
comparison operators with equivalent opera-
tions if they cause the required bits to be
set, even if the remaining bits are undefined.
For example, on a machine whose comparison













operators return an SImode value and where
STORE_FLAG_VALUE is defined as `0x80000000',
saying that just the sign bit is relevant, the
expression


(ne:SI (and:SI x (const_int power-of-2)) (const_int 0))



can be converted to


(ashift:SI x (const_int n))



where n is the appropriate shift count to move the
bit being tested into the sign bit.

There is no way to describe a machine that al-
ways sets the low-order bit for a true value,
but does not guarantee the value of any other
bits, but we do not know of any machine that
has such an instruction. If you are trying to
port GNU CC to such a machine, include an in-
struction to perform a logical-and of the
result with 1 in the pattern for the comparis-
on operators and let us know (see section Bug
Reporting).

Often, a machine will have multiple instruc-
tions that obtain a value from a comparison
(or the condition codes). Here are rules to
guide the choice of value for
STORE_FLAG_VALUE, and hence the instructions
to be used:

o+ Use the shortest sequence that yields a valid
definition for STORE_FLAG_VALUE. It is more
efficent for the compiler to ``normalize''
the value (convert it to, e.g., 1 or 0) than
for the comparison operators to do so because
there may be opportunities to combine the
normalization with other operations.

o+ For equal-length sequences, use a value of 1
or -1, with -1 being slightly preferred on
machines with expensive jumps and 1 preferred
on other machines.

o+ As a second choice, choose a value of
`0x80000001' if instructions exist that set













both the sign and low-order bits but do not
define the others.

o+ Otherwise, use a value of `0x80000000'.


You need not define STORE_FLAG_VALUE if the
machine has no store-flag instructions.

Pmode
An alias for the machine mode for pointers. Nor-
mally the definition can be


#define Pmode SImode



FUNCTION_MODE
An alias for the machine mode used for memory
references to functions being called, in call
RTL expressions. On most machines this should
be QImode.

INTEGRATE_THRESHOLD (decl)
A C expression for the maximum number of in-
structions above which the function decl
should not be inlined. decl is a
FUNCTION_DECL node.

The default definition of this macro is 64
plus 8 times the number of arguments that the
function accepts. Some people think a larger
threshold should be used on RISC machines.

SCCS_DIRECTIVE
Define this if the preprocessor should ignore
#sccs directives and print no error message.

HANDLE_PRAGMA (stream)
Define this macro if you want to implement any
pragmas. If defined, it should be a C state-
ment to be executed when #pragma is seen. The
argument stream is the stdio input stream from
which the source text can be read.

It is generally a bad idea to implement new
uses of #pragma. The only reason to define
this macro is for compatibility with other
compilers that do support #pragma for the sake
of any user programs which already use it.















HAVE_VPRINTF
Define this if the library function vprintf is
available on your system.

DOLLARS_IN_IDENTIFIERS
Define this macro to control use of the char-
acter `$' in identifier names. The value
should be 0, 1, or 2. 0 means `$' is not al-
lowed by default; 1 means it is allowed by de-
fault if `-traditional' is used; 2 means it is
allowed by default provided `-ansi' is not
used. 1 is the default; there is no need to
define this macro in that case.

DEFAULT_MAIN_RETURN
Define this macro if the target system expects
every program's main function to return a
standard ``success'' value by default (if no
other value is explicitly returned).

The definition should be a C statement (sans
semicolon) to generate the appropriate rtl in-
structions. It is used only when compiling
the end of main.

HAVE_ATEXIT
Define this if the target system supports the
function atexit from the ANSI C standard. If
this is not defined, and INIT_SECTION_ASM_OP
is not defined, a default exit function will
be provided to support C++.

EXIT_BODY
Define this if your exit function needs to do
something besides calling an external function
_cleanup before terminating with _exit. The
EXIT_BODY macro is only needed if netiher
HAVE_ATEXIT nor INIT_SECTION_ASM_OP are de-
fined.