Next: MCore Options, Previous: M32R/D Options, Up: Submodel Options
These are the `-m' options defined for M680x0 and ColdFire processors. The default settings depend on which architecture was selected when the compiler was configured; the defaults for the most common choices are given below.
-march=
archgcc defines a macro `__mcfarch__' whenever it is generating code for a ColdFire target. The arch in this macro is one of the -march arguments given above.
When used together, -march and -mtune select code
that runs on a family of similar processors but that is optimized
for a particular microarchitecture.
-mcpu=
cpuFamily | `-mcpu' arguments
|
`51' | `51' `51ac' `51cn' `51em' `51qe'
|
`5206' | `5202' `5204' `5206'
|
`5206e' | `5206e'
|
`5208' | `5207' `5208'
|
`5211a' | `5210a' `5211a'
|
`5213' | `5211' `5212' `5213'
|
`5216' | `5214' `5216'
|
`52235' | `52230' `52231' `52232' `52233' `52234' `52235'
|
`5225' | `5224' `5225'
|
`52259' | `52252' `52254' `52255' `52256' `52258' `52259'
|
`5235' | `5232' `5233' `5234' `5235' `523x'
|
`5249' | `5249'
|
`5250' | `5250'
|
`5271' | `5270' `5271'
|
`5272' | `5272'
|
`5275' | `5274' `5275'
|
`5282' | `5280' `5281' `5282' `528x'
|
`53017' | `53011' `53012' `53013' `53014' `53015' `53016' `53017'
|
`5307' | `5307'
|
`5329' | `5327' `5328' `5329' `532x'
|
`5373' | `5372' `5373' `537x'
|
`5407' | `5407'
|
`5475' | `5470' `5471' `5472' `5473' `5474' `5475' `547x' `5480' `5481' `5482' `5483' `5484' `5485'
|
-mcpu=cpu overrides -march=arch if arch is compatible with cpu. Other combinations of -mcpu and -march are rejected.
gcc defines the macro `__mcf_cpu_cpu' when ColdFire target
cpu is selected. It also defines `__mcf_family_family',
where the value of family is given by the table above.
-mtune=
tuneYou can also use -mtune=68020-40 for code that needs to run relatively well on 68020, 68030 and 68040 targets. -mtune=68020-60 is similar but includes 68060 targets as well. These two options select the same tuning decisions as -m68020-40 and -m68020-60 respectively.
gcc defines the macros `__mcarch' and `__mcarch__' when tuning for 680x0 architecture arch. It also defines `mcarch' unless either -ansi or a non-GNU -std option is used. If gcc is tuning for a range of architectures, as selected by -mtune=68020-40 or -mtune=68020-60, it defines the macros for every architecture in the range.
gcc also defines the macro `__muarch__' when tuning for
ColdFire microarchitecture uarch, where uarch is one
of the arguments given above.
-m68000
-mc68000
Use this option for microcontrollers with a 68000 or EC000 core,
including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
-m68010
-m68020
-mc68020
-m68030
-m68040
This option inhibits the use of 68881/68882 instructions that have to be
emulated by software on the 68040. Use this option if your 68040 does not
have code to emulate those instructions.
-m68060
This option inhibits the use of 68020 and 68881/68882 instructions that
have to be emulated by software on the 68060. Use this option if your 68060
does not have code to emulate those instructions.
-mcpu32
Use this option for microcontrollers with a
CPU32 or CPU32+ core, including the 68330, 68331, 68332, 68333, 68334,
68336, 68340, 68341, 68349 and 68360.
-m5200
Use this option for microcontroller with a 5200 core, including
the MCF5202, MCF5203, MCF5204 and MCF5206.
-m5206e
-m528x
-m5307
-m5407
-mcfv4e
-m68020-40
The option is equivalent to -march=68020 -mtune=68020-40.
-m68020-60
The option is equivalent to -march=68020 -mtune=68020-60.
-mhard-float
-m68881
-msoft-float
-mdiv
-mno-div
gcc defines the macro `__mcfhwdiv__' when this option is enabled.
-mshort
int
to be 16 bits wide, like short int
.
Additionally, parameters passed on the stack are also aligned to a
16-bit boundary even on targets whose API mandates promotion to 32-bit.
-mno-short
int
to be 16 bits wide. This is the default.
-mnobitfield
-mno-bitfield
-mbitfield
-mrtd
rtd
instruction, which pops their arguments while returning. This
saves one instruction in the caller since there is no need to pop
the arguments there.
This calling convention is incompatible with the one normally used on Unix, so you cannot use it if you need to call libraries compiled with the Unix compiler.
Also, you must provide function prototypes for all functions that
take variable numbers of arguments (including printf
);
otherwise incorrect code will be generated for calls to those
functions.
In addition, seriously incorrect code will result if you call a function with too many arguments. (Normally, extra arguments are harmlessly ignored.)
The rtd
instruction is supported by the 68010, 68020, 68030,
68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
-mno-rtd
-malign-int
-mno-align-int
int
, long
, long long
,
float
, double
, and long double
variables on a 32-bit
boundary (-malign-int) or a 16-bit boundary (-mno-align-int).
Aligning variables on 32-bit boundaries produces code that runs somewhat
faster on processors with 32-bit busses at the expense of more memory.
Warning: if you use the -malign-int switch, GCC will
align structures containing the above types differently than
most published application binary interface specifications for the m68k.
-mpcrel
-mno-strict-align
-mstrict-align
-msep-data
-mno-sep-data
-mid-shared-library
-mno-id-shared-library
-mshared-library-id=n
-mxgot
-mno-xgot
GCC normally uses a single instruction to load values from the GOT. While this is relatively efficient, it only works if the GOT is smaller than about 64k. Anything larger causes the linker to report an error such as:
relocation truncated to fit: R_68K_GOT16O foobar
If this happens, you should recompile your code with -mxgot. It should then work with very large GOTs. However, code generated with -mxgot is less efficient, since it takes 4 instructions to fetch the value of a global symbol.
Note that some linkers, including newer versions of the GNU linker, can create multiple GOTs and sort GOT entries. If you have such a linker, you should only need to use -mxgot when compiling a single object file that accesses more than 8192 GOT entries. Very few do.
These options have no effect unless GCC is generating position-independent code.