3.17.16 Intel 960 Options
These `-m' options are defined for the Intel 960 implementations:
- Assume the defaults for the machine type cpu-type for some of
the other options, including instruction scheduling, floating point
support, and addressing modes. The choices for cpu-type are
`ka', `kb', `mc', `ca', `cf',
`sa', and `sb'.
The default is
- The -mnumerics option indicates that the processor does support
floating-point instructions. The -msoft-float option indicates
that floating-point support should not be assumed.
- Do (or do not) attempt to alter leaf procedures to be callable with the
bal instruction as well as
call. This will result in more
efficient code for explicit calls when the
bal instruction can be
substituted by the assembler or linker, but less efficient code in other
cases, such as calls via function pointers, or using a linker that doesn't
support this optimization.
- Do (or do not) make additional attempts (beyond those of the
machine-independent portions of the compiler) to optimize tail-recursive
calls into branches. You may not want to do this because the detection of
cases where this is not valid is not totally complete. The default is
- Assume (or do not assume) that the use of a complex addressing mode is a
win on this implementation of the i960. Complex addressing modes may not
be worthwhile on the K-series, but they definitely are on the C-series.
The default is currently -mcomplex-addr for all processors except
the CB and CC.
- Align code to 8-byte boundaries for faster fetching (or don't bother).
Currently turned on by default for C-series implementations only.
- Enable compatibility with iC960 v2.0 or v3.0.
- Enable compatibility with the iC960 assembler.
- Do not permit (do permit) unaligned accesses.
- Enable structure-alignment compatibility with Intel's gcc release version
1.3 (based on gcc 1.37). This option implies -mstrict-align.
- Implement type `long double' as 64-bit floating point numbers.
Without the option `long double' is implemented by 80-bit
floating point numbers. The only reason we have it because there is
no 128-bit `long double' support in `fp-bit.c' yet. So it
is only useful for people using soft-float targets. Otherwise, we
should recommend against use of it.