some files aren't too happy in a library
[suif.git] / html / man_snoot.1.html
blobd38590213958f9da9eab564bbb842ccb667433ed
1 <!-- manual page source format generated by PolyglotMan v3.0.7, -->
2 <!-- available via anonymous ftp from ftp.cs.berkeley.edu:/ucb/people/phelps/tcltk/rman.tar.Z -->
4 <HTML>
5 <HEAD>
6 <TITLE>Man page for snoot.1</TITLE>
7 </HEAD>
8 <BODY bgcolor=white>
9 <A HREF="#toc">Table of Contents</A><P>
11 <H2><A NAME="sect0" HREF="#toc0">Name</A></H2>
13 <P>
14 snoot - translate pre-processed C to SUIF
16 <H2><A NAME="sect1" HREF="#toc1"><B>Synopsis</B></A></H2>
18 <P>
19 <B>snoot</B> [ <I>options</I> ] <I>infile</I> <I>outfile</I>
21 <H2><A NAME="sect2" HREF="#toc2"><B>Description</B></A></H2>
23 <P>
24 The <I>snoot</I> program is the core of the SUIF C front end. It
25 translates from pre-processed ANSI-C to SUIF. The SUIF
26 code that <I>snoot</I> produces is non-standard, however; it must
27 be passed through <I>porky</I> with the <I>-defaults</I> flag before it
28 becomes standard SUIF that other passes can handle.
29 <P>
30 The entire C front-end for SUIF consists of three passes.
31 First, <I>cpp,</I> the ANSI-C pre-processor. This is not
32 included with SUIF. Any standard ANSI-C pre-processor may
33 be used; the gnu C pre-processor that is included with gcc
34 is one option. The output of <I>cpp</I> is then fed into <I>snoot.</I>
35 The output from <I>snoot</I> is the first SUIF file. Then the
36 last stage is <I>porky</I> with the <I>-defaults</I> option. Together,
37 these three passes turn ANSI-C into standard SUIF.
39 <H2><A NAME="sect3" HREF="#toc3"><B>Options</B></A></H2>
42 <DL>
44 <DT><B>-W</B> </DT></DT>
45 <DD> Turn on more warning messages. By default, only
46 important warnings are displayed. If used a second
47 time, all possible warnings are issued.
48 </DD>
50 <DT><B>-w</B> </DT></DT>
51 <DD> Suppress all warning messages. This overrides the
52 <B>-W</B> option.
53 </DD>
55 <DT><B>-keep-comments</B></DT></DT>
56 <DD>
57 Save all comments from the C code as \x01C comment"
58 annotations on SUIF ``mrk'' instructions. By
59 default, comments are ignored.
60 </DD>
61 </DL>
62 <P>
63 Note that for this to have any effect, the C comments
64 must have been preserved by the C pre-processor;
65 by default <I>cpp</I> throws them away before <I>snoot</I>
66 even sees the code. Use the <B>-C</B> option for <I>cpp</I> to
67 save comments in the pre-processing stage.
69 <DL>
71 <DT><B>-ignore-comments</B></DT></DT>
72 <DD>
73 Do not save C comments. This is the default. If
74 both <B>-keep-comments</B> and <B>-ignore-comments</B> are specified,
75 the one that occurs latest on the command
76 line takes effect.
77 </DD>
79 <DT><B>-x</B> </DT></DT>
80 <DD> Write cross-reference of symbol uses as \x01source
81 references\x02 annotations on the SUIF symbols. The
82 location of each reference in the source file is
83 recorded.
84 </DD>
86 <DT><B>-P</B> </DT></DT>
87 <DD> Print function prototypes and global variable declarations
88 to standard error. This output can be
89 appended to the top of a source file so that the
90 next time it's compiled more type checking can be
91 done.
92 </DD>
94 <DT><B>-s</B><I>density</I></DT></DT>
95 <DD>
96 Set the density of labels used as a cutoff for
97 using SUIF mbr instructions instead of individual
98 comparisons for switch statements. The <I>density</I> is
99 interpreted as a floating point value. The default
100 is 0.5, meaning that at least half the values in a
101 range have to have case labels before an mbr
102 instruction is used.
103 </DD>
105 <DT><B>-e</B><I>n</I> </DT></DT>
106 <DD> Set the maximum number of error messages <I>snoot</I> will
107 issue before giving up. The default is 20. Ordinarily,
108 <I>snoot</I> will issue an error message and continue
109 to look for more errors. Even if the rest of
110 the program can successfully be translated, <I>snoot</I>
111 will still return an error code. Once the limit is
112 reached, <I>snoot</I> assumes that it is so hopelessly
113 confused by earlier errors that there's no point in
114 reporting any more.
115 </DD>
117 <DT><B>-mark-execution-points</B></DT></DT>
118 <DD>
119 Put \x01sequence point\x02 annotations in the SUIF code
120 corresponding to sequence points in the source
121 code, when possible. Temporary values will be
122 spilled into new variables if necessary. The one
123 situation where sequence points are not properly
124 inserted is for C ``for()'' statements that are
125 translated into SUIF TREE_FOR nodes. There is no
126 place on a SUIF TREE_FOR to put the sequence point
127 that comes between evaluation of the incrementing
128 expression and the test expression.
129 </DD>
130 </DL>
132 Sequence points are defined in the ANSI C standard
133 as points in the execution where some things are
134 guaranteed to have already been executed and others
135 not yet executed. The standard defines exactly
136 where they occur. The option of marking these in
137 the SUIF code is provided in case later passes want
138 to use them to print traces of variable values or
139 something of that sort.
141 <DL>
143 <DT><B>-ignore-execution-points</B></DT></DT>
144 <DD>
145 Do not mark sequence points in the SUIF code. This
146 is the default. If both <B>-mark-execution-points</B> and
147 <B>-ignore-execution-points</B> are specified, the one
148 that occurs latest on the command line takes
149 effect.
150 </DD>
152 <DT><B>-null-check</B></DT></DT>
153 <DD>
154 Insert code to check at runtime for a NULL pointer
155 every time memory is explicitly read or written in
156 the C code (i.e. for every use of the ``[]'',
157 ``-&gt;'', or unary ``*'' operators). If a NULL
158 pointer is found, an error message is issued giving
159 the source line number and file and the program
160 aborts.
161 </DD>
163 <DT><B>-no-null-check</B></DT></DT>
164 <DD>
165 Do not insert code to check at runtime for NULL
166 pointers. This is the default. If both <B>-nullcheck</B>
167 and <B>-no-null-check</B> are specified, the one
168 that occurs latest on the command line takes
169 effect.
170 </DD>
172 <DT><B>-T</B><I>target-name</I></DT></DT>
173 <DD>
174 Use the system-specific target parameters specified
175 by <I>target-name</I> in compilation. This is used in
176 cross-compilation or to generate code for a different
177 back-end C compiler. The parameters include
178 such things as the byte order of the machine, the
179 sizes of the various types, and whether the type
180 ``char'' is signed or unsigned. The default is to
181 use the parameters from the C compiler used to
182 build snoot (typically gcc).
183 </DD>
184 </DL>
186 To see a list of targets <I>snoot</I> understands, type
187 <I>snoot</I> <I>-T-.</I> Target information is stored in the
188 <I>snoot</I> source file <I>config.h.</I> See the <I>snoot</I> source
189 file <I>find</I><B>_</B><I>params.c</I> for information on generating
190 target information for new systems.
192 <DL>
194 <DT><B>-keep-typedef-info</B></DT></DT>
195 <DD>
196 Create dummy variables to represent typedef names.
197 The dummy variables are given type ``int'' and have
198 \x01typedef name\x02 annotations attached. The data on
199 the annotation contains an immed list with one
200 item, the type of the typedef.
201 </DD>
203 <DT><B>-builtin</B> <I>builtin-name</I></DT></DT>
204 <DD>
205 Consider <I>builtin-name</I> to be a built-in identifier.
206 That means that <I>builtin-name</I> can be used as a variable
207 or followed by arguments in parentheses and
208 each such expression will be translated to a SUIF
209 generic instruction with <I>builtin-name</I> as its name.
210 Within the parentheses can be a comma-separated
211 argument list, where each argument can be a type, a
212 string literal, or an expression. These generic
213 instructions will be passed through most SUIF
214 passes and <I>s2c</I> will translate them back into a form
215 similar to their form in the original source code.
216 This can be used to implement asm() directives, or
217 built-in identifiers used for vararg macros in
218 headers for some systems. Note that an alternative
219 to specifying built-in identifiers on the commandline
220 with this switch is to specify them in the
221 configuration file \x01config.h".
222 </DD>
224 <DT><B>-force-enum-is-int</B></DT></DT>
225 <DD>
226 Force all enum types to use type ``int'' as their
227 equivalent type. Ordinarily, enum types are mapped
228 to the smallest integer type that can contain all
229 their enumeration constants. This option overrides
230 that for compatibility, since some programs assume
231 that the compiler maps enums only to ``int'' under
232 all circumstances.
233 </DD>
234 </DL>
236 <H2><A NAME="sect4" HREF="#toc4"><B>History</B></A></H2>
239 The first ANSI-C front-end for SUIF was <I>snout,</I> written by
240 Robert French. It was based on <I>lcc,</I> a portable C frontend
241 with a code-generation interface (see ``A Code Generation
242 Interface for ANSI C'' by Fraser and Hanson). Since
243 the back-end interface provided by <I>lcc</I> is too low-level
244 for SUIF, some substantial changes were made in various
245 levels of <I>lcc</I> code and data-structures to preserve more
246 information when generating SUIF code.
248 When the SUIF system was overhauled, Todd Smith rewrote
249 the SUIF-specific parts of <I>snout</I> to create <I>snoot</I> for new
250 SUIF. When more changes were made to SUIF that required
251 more information to be preserved that lcc was losing
252 early-on, Chris Wilson rewrote <I>snoot.</I> Various internal
253 transformations and datastructures used by lcc were
254 removed. Now the front-end of lcc is used to generate
255 SUIF code directly.
258 <HR><P>
259 <A NAME="toc"><B>Table of Contents</B></A><P>
260 <UL>
261 <LI><A NAME="toc0" HREF="#sect0">Name</A></LI>
262 <LI><A NAME="toc1" HREF="#sect1">Synopsis</A></LI>
263 <LI><A NAME="toc2" HREF="#sect2">Description</A></LI>
264 <LI><A NAME="toc3" HREF="#sect3">Options</A></LI>
265 <LI><A NAME="toc4" HREF="#sect4">History</A></LI>
266 </UL>
267 </BODY></HTML>