📄 sparc-options.html
字号:
<html lang="en">
<head>
<title>Using the GNU Compiler Collection (GCC)</title>
<meta http-equiv="Content-Type" content="text/html">
<meta name="description" content="Using the GNU Compiler Collection (GCC)">
<meta name="generator" content="makeinfo 4.3">
<link href="http://www.gnu.org/software/texinfo/" rel="generator-home">
<!--
Copyright © 1988, 1989, 1992, 1993, 1994, 1995, 1996, 1997, 1998,
1999, 2000, 2001, 2002, 2003 Free Software Foundation, Inc.
<p>Permission is granted to copy, distribute and/or modify this document
under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with the
Invariant Sections being "GNU General Public License" and "Funding
Free Software", the Front-Cover texts being (a) (see below), and with
the Back-Cover Texts being (b) (see below). A copy of the license is
included in the section entitled "GNU Free Documentation License".
<p>(a) The FSF's Front-Cover Text is:
<p>A GNU Manual
<p>(b) The FSF's Back-Cover Text is:
<p>You have freedom to copy and modify this GNU Manual, like GNU
software. Copies published by the Free Software Foundation raise
funds for GNU development.-->
</head>
<body>
<div class="node">
<p>
Node:<a name="SPARC%20Options">SPARC Options</a>,
Next:<a rel="next" accesskey="n" href="ARM-Options.html#ARM%20Options">ARM Options</a>,
Previous:<a rel="previous" accesskey="p" href="VAX-Options.html#VAX%20Options">VAX Options</a>,
Up:<a rel="up" accesskey="u" href="Submodel-Options.html#Submodel%20Options">Submodel Options</a>
<hr><br>
</div>
<h4 class="subsection">SPARC Options</h4>
<p>These <code>-m</code> switches are supported on the SPARC:
<dl>
<dt><code>-mno-app-regs</code>
<dd><dt><code>-mapp-regs</code>
<dd>Specify <code>-mapp-regs</code> to generate output using the global registers
2 through 4, which the SPARC SVR4 ABI reserves for applications. This
is the default.
<p>To be fully SVR4 ABI compliant at the cost of some performance loss,
specify <code>-mno-app-regs</code>. You should compile libraries and system
software with this option.
<br><dt><code>-mfpu</code>
<dd><dt><code>-mhard-float</code>
<dd>Generate output containing floating point instructions. This is the
default.
<br><dt><code>-mno-fpu</code>
<dd><dt><code>-msoft-float</code>
<dd>Generate output containing library calls for floating point.
<strong>Warning:</strong> the requisite libraries are not available for all SPARC
targets. Normally the facilities of the machine's usual C compiler are
used, but this cannot be done directly in cross-compilation. You must make
your own arrangements to provide suitable library functions for
cross-compilation. The embedded targets <code>sparc-*-aout</code> and
<code>sparclite-*-*</code> do provide software floating point support.
<p><code>-msoft-float</code> changes the calling convention in the output file;
therefore, it is only useful if you compile <em>all</em> of a program with
this option. In particular, you need to compile <code>libgcc.a</code>, the
library that comes with GCC, with <code>-msoft-float</code> in order for
this to work.
<br><dt><code>-mhard-quad-float</code>
<dd>Generate output containing quad-word (long double) floating point
instructions.
<br><dt><code>-msoft-quad-float</code>
<dd>Generate output containing library calls for quad-word (long double)
floating point instructions. The functions called are those specified
in the SPARC ABI. This is the default.
<p>As of this writing, there are no sparc implementations that have hardware
support for the quad-word floating point instructions. They all invoke
a trap handler for one of these instructions, and then the trap handler
emulates the effect of the instruction. Because of the trap handler overhead,
this is much slower than calling the ABI library routines. Thus the
<code>-msoft-quad-float</code> option is the default.
<br><dt><code>-mno-flat</code>
<dd><dt><code>-mflat</code>
<dd>With <code>-mflat</code>, the compiler does not generate save/restore instructions
and will use a "flat" or single register window calling convention.
This model uses %i7 as the frame pointer and is compatible with the normal
register window model. Code from either may be intermixed.
The local registers and the input registers (0-5) are still treated as
"call saved" registers and will be saved on the stack as necessary.
<p>With <code>-mno-flat</code> (the default), the compiler emits save/restore
instructions (except for leaf functions) and is the normal mode of operation.
<br><dt><code>-mno-unaligned-doubles</code>
<dd><dt><code>-munaligned-doubles</code>
<dd>Assume that doubles have 8 byte alignment. This is the default.
<p>With <code>-munaligned-doubles</code>, GCC assumes that doubles have 8 byte
alignment only if they are contained in another type, or if they have an
absolute address. Otherwise, it assumes they have 4 byte alignment.
Specifying this option avoids some rare compatibility problems with code
generated by other compilers. It is not the default because it results
in a performance loss, especially for floating point code.
<br><dt><code>-mno-faster-structs</code>
<dd><dt><code>-mfaster-structs</code>
<dd>With <code>-mfaster-structs</code>, the compiler assumes that structures
should have 8 byte alignment. This enables the use of pairs of
<code>ldd</code> and <code>std</code> instructions for copies in structure
assignment, in place of twice as many <code>ld</code> and <code>st</code> pairs.
However, the use of this changed alignment directly violates the SPARC
ABI. Thus, it's intended only for use on targets where the developer
acknowledges that their resulting code will not be directly in line with
the rules of the ABI.
<br><dt><code>-mv8</code>
<dd><dt><code>-msparclite</code>
<dd>These two options select variations on the SPARC architecture.
<p>By default (unless specifically configured for the Fujitsu SPARClite),
GCC generates code for the v7 variant of the SPARC architecture.
<p><code>-mv8</code> will give you SPARC v8 code. The only difference from v7
code is that the compiler emits the integer multiply and integer
divide instructions which exist in SPARC v8 but not in SPARC v7.
<p><code>-msparclite</code> will give you SPARClite code. This adds the integer
multiply, integer divide step and scan (<code>ffs</code>) instructions which
exist in SPARClite but not in SPARC v7.
<p>These options are deprecated and will be deleted in a future GCC release.
They have been replaced with <code>-mcpu=xxx</code>.
<br><dt><code>-mcypress</code>
<dd><dt><code>-msupersparc</code>
<dd>These two options select the processor for which the code is optimized.
<p>With <code>-mcypress</code> (the default), the compiler optimizes code for the
Cypress CY7C602 chip, as used in the SPARCStation/SPARCServer 3xx series.
This is also appropriate for the older SPARCStation 1, 2, IPX etc.
<p>With <code>-msupersparc</code> the compiler optimizes code for the SuperSPARC cpu, as
used in the SPARCStation 10, 1000 and 2000 series. This flag also enables use
of the full SPARC v8 instruction set.
<p>These options are deprecated and will be deleted in a future GCC release.
They have been replaced with <code>-mcpu=xxx</code>.
<br><dt><code>-mcpu=</code><var>cpu_type</var><code></code>
<dd>Set the instruction set, register set, and instruction scheduling parameters
for machine type <var>cpu_type</var>. Supported values for <var>cpu_type</var> are
<code>v7</code>, <code>cypress</code>, <code>v8</code>, <code>supersparc</code>, <code>sparclite</code>,
<code>hypersparc</code>, <code>sparclite86x</code>, <code>f930</code>, <code>f934</code>,
<code>sparclet</code>, <code>tsc701</code>, <code>v9</code>, <code>ultrasparc</code>, and
<code>ultrasparc3</code>.
<p>Default instruction scheduling parameters are used for values that select
an architecture and not an implementation. These are <code>v7</code>, <code>v8</code>,
<code>sparclite</code>, <code>sparclet</code>, <code>v9</code>.
<p>Here is a list of each supported architecture and their supported
implementations.
<pre class="smallexample"> v7: cypress
v8: supersparc, hypersparc
sparclite: f930, f934, sparclite86x
sparclet: tsc701
v9: ultrasparc, ultrasparc3
</pre>
<br><dt><code>-mtune=</code><var>cpu_type</var><code></code>
<dd>Set the instruction scheduling parameters for machine type
<var>cpu_type</var>, but do not set the instruction set or register set that the
option <code>-mcpu=</code><var>cpu_type</var><code></code> would.
<p>The same values for <code>-mcpu=</code><var>cpu_type</var><code></code> can be used for
<code>-mtune=</code><var>cpu_type</var><code></code>, but the only useful values are those
that select a particular cpu implementation. Those are <code>cypress</code>,
<code>supersparc</code>, <code>hypersparc</code>, <code>f930</code>, <code>f934</code>,
<code>sparclite86x</code>, <code>tsc701</code>, <code>ultrasparc</code>, and
<code>ultrasparc3</code>.
</dl>
<p>These <code>-m</code> switches are supported in addition to the above
on the SPARCLET processor.
<dl>
<dt><code>-mlittle-endian</code>
<dd>Generate code for a processor running in little-endian mode.
<br><dt><code>-mlive-g0</code>
<dd>Treat register <code>%g0</code> as a normal register.
GCC will continue to clobber it as necessary but will not assume
it always reads as 0.
<br><dt><code>-mbroken-saverestore</code>
<dd>Generate code that does not use non-trivial forms of the <code>save</code> and
<code>restore</code> instructions. Early versions of the SPARCLET processor do
not correctly handle <code>save</code> and <code>restore</code> instructions used with
arguments. They correctly handle them used without arguments. A <code>save</code>
instruction used without arguments increments the current window pointer
but does not allocate a new stack frame. It is assumed that the window
overflow trap handler will properly handle this case as will interrupt
handlers.
</dl>
<p>These <code>-m</code> switches are supported in addition to the above
on SPARC V9 processors in 64-bit environments.
<dl>
<dt><code>-mlittle-endian</code>
<dd>Generate code for a processor running in little-endian mode.
<br><dt><code>-m32</code>
<dd><dt><code>-m64</code>
<dd>Generate code for a 32-bit or 64-bit environment.
The 32-bit environment sets int, long and pointer to 32 bits.
The 64-bit environment sets int to 32 bits and long and pointer
to 64 bits.
<br><dt><code>-mcmodel=medlow</code>
<dd>Generate code for the Medium/Low code model: the program must be linked
in the low 32 bits of the address space. Pointers are 64 bits.
Programs can be statically or dynamically linked.
<br><dt><code>-mcmodel=medmid</code>
<dd>Generate code for the Medium/Middle code model: the program must be linked
in the low 44 bits of the address space, the text segment must be less than
2G bytes, and data segment must be within 2G of the text segment.
Pointers are 64 bits.
<br><dt><code>-mcmodel=medany</code>
<dd>Generate code for the Medium/Anywhere code model: the program may be linked
anywhere in the address space, the text segment must be less than
2G bytes, and data segment must be within 2G of the text segment.
Pointers are 64 bits.
<br><dt><code>-mcmodel=embmedany</code>
<dd>Generate code for the Medium/Anywhere code model for embedded systems:
assume a 32-bit text and a 32-bit data segment, both starting anywhere
(determined at link time). Register %g4 points to the base of the
data segment. Pointers are still 64 bits.
Programs are statically linked, PIC is not supported.
<br><dt><code>-mstack-bias</code>
<dd><dt><code>-mno-stack-bias</code>
<dd>With <code>-mstack-bias</code>, GCC assumes that the stack pointer, and
frame pointer if present, are offset by -2047 which must be added back
when making stack frame references.
Otherwise, assume no such offset is present.
</dl>
</body></html>
⌨️ 快捷键说明
复制代码
Ctrl + C
搜索代码
Ctrl + F
全屏模式
F11
切换主题
Ctrl + Shift + D
显示快捷键
?
增大字号
Ctrl + =
减小字号
Ctrl + -