<varlistentry>
<term>
+ <option>-pgmm</option> <replaceable>cmd</replaceable>
+ <indexterm><primary><option>-pgmm</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Use <replaceable>cmd</replaceable> as the
+ mangler.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-pgms</option> <replaceable>cmd</replaceable>
+ <indexterm><primary><option>-pgms</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Use <replaceable>cmd</replaceable> as the
+ splitter.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<option>-pgma</option> <replaceable>cmd</replaceable>
<indexterm><primary><option>-pgma</option></primary></indexterm>
</term>
<varlistentry>
<term>
- <option>-pgmdep</option> <replaceable>cmd</replaceable>
- <indexterm><primary><option>-pgmdep</option></primary></indexterm>
- </term>
- <listitem>
- <para>Use <replaceable>cmd</replaceable> as the dependency
- generator.</para>
- </listitem>
- </varlistentry>
-
- <varlistentry>
- <term>
<option>-pgmF</option> <replaceable>cmd</replaceable>
<indexterm><primary><option>-pgmF</option></primary></indexterm>
</term>
</varlistentry>
<varlistentry>
<term>
+ <option>-optm</option> <replaceable>option</replaceable>
+ <indexterm><primary><option>-optm</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Pass <replaceable>option</replaceable> to the mangler.</para>
+ </listitem>
+ </varlistentry>
+ <varlistentry>
+ <term>
<option>-opta</option> <replaceable>option</replaceable>
<indexterm><primary><option>-opta</option></primary></indexterm>
</term>
are fed to <replaceable>cmd</replaceable> on the command
line after the three standard input and output
arguments.</para>
+
+ <para>
+ An example of a pre-processor is to convert your source files to the
+ input encoding that GHC expects, i.e. create a script
+ <literal>convert.sh</literal> containing the lines:
+ </para>
+
+<screen>#!/bin/sh
+( echo "{-# LINE 1 \"$2\" #-}" ; iconv -f l1 -t utf-8 $2 ) > $3</screen>
+
+ <para>and pass <literal>-F -pgmF convert.sh</literal> to GHC.
+ The <literal>-f l1</literal> option tells iconv to convert your
+ Latin-1 file, supplied in argument <literal>$2</literal>, while
+ the "-t utf-8" options tell iconv to return a UTF-8 encoded file.
+ The result is redirected into argument <literal>$3</literal>.
+ The <literal>echo "{-# LINE 1 \"$2\" #-}"</literal>
+ just makes sure that your error positions are reported as
+ in the original source file.</para>
</listitem>
</varlistentry>
</variablelist>
<para>Use GHC's native code generator rather than
compiling via C. This will compile faster (up to twice as
fast), but may produce code that is slightly slower than
- compiling via C. <option>-fasm</option> is the default
- when optimisation is off (see <xref
- linkend="options-optimise"/>).</para>
+ compiling via C. <option>-fasm</option> is the default.</para>
</listitem>
</varlistentry>
</term>
<listitem>
<para>Compile via C instead of using the native code
- generator. This is default for optimised compilations,
- and on architectures for which GHC doesn't have a native
- code generator.</para>
+ generator. This is the default on architectures for which GHC
+ doesn't have a native code generator.</para>
</listitem>
</varlistentry>
<varlistentry>
<term>
+ <option>-fobject-code</option>
+ <indexterm><primary><option>-fobject-code</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Generate object code. This is the default outside of
+ GHCi, and can be used with GHCi to cause object code to be
+ generated in preference to bytecode.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
+ <option>-fbyte-code</option>
+ <indexterm><primary><option>-fbyte-code</option></primary></indexterm>
+ </term>
+ <listitem>
+ <para>Generate byte-code instead of object-code. This is
+ the default in GHCi. Byte-code can currently only be used
+ in the interactive interpreter, not saved to disk. This
+ option is only useful for reversing the effect of
+ <option>-fobject-code</option>.</para>
+ </listitem>
+ </varlistentry>
+
+ <varlistentry>
+ <term>
<option>-fPIC</option>
<indexterm><primary><option>-fPIC</option></primary></indexterm>
</term>
<para>Tell the linker to split the single object file that
would normally be generated into multiple object files,
one per top-level Haskell function or type in the module.
- We use this feature for building GHC's libraries libraries
+ This only makes sense for libraries, where it means that
+ executables linked against the library are smaller as they only
+ link against the object files that they need. However, assembling
+ all the sections separately is expensive, so this is slower than
+ compiling normally.
+ We use this feature for building GHC's libraries
(warning: don't use it unless you know what you're
doing!).</para>
</listitem>
<literal>ghc</literal> is not clever
enough to figure out that they both need recompiling. You can
force recompilation by removing the object file, or by using the
- <option>-no-recomp</option> flag.
+ <option>-fforce-recomp</option> flag.
</para>
</listitem>
</varlistentry>
<indexterm><primary><option>-threaded</option></primary></indexterm>
</term>
<listitem>
- <para>Link the program with the "threaded" runtime system.
- This version of the runtime is designed to be used in
- programs that use multiple operating-system threads. It
- supports calls to foreign-exported functions from multiple
- OS threads. Calls to foreign functions are made using the
- same OS thread that created the Haskell thread (if it was
- created by a call-in), or an arbitrary OS thread otherwise
- (if the Haskell thread was created by
+ <para>Link the program with the "threaded" version of the
+ runtime system. The threaded runtime system is so-called
+ because it manages multiple OS threads, as opposed to the
+ default runtime system which is purely
+ single-threaded.</para>
+
+ <para>Note that you do <emphasis>not</emphasis> need
+ <option>-threaded</option> in order to use concurrency; the
+ single-threaded runtime supports concurrency between Haskell
+ threads just fine.</para>
+
+ <para>The threaded runtime system provides the following
+ benefits:</para>
+
+ <itemizedlist>
+ <listitem>
+ <para>Parallelism<indexterm><primary>parallelism</primary></indexterm> on a multiprocessor<indexterm><primary>multiprocessor</primary></indexterm><indexterm><primary>SMP</primary></indexterm> or multicore<indexterm><primary>multicore</primary></indexterm>
+ machine. See <xref linkend="using-smp" />.</para>
+
+ <para>The ability to make a foreign call that does not
+ block all other Haskell threads.</para>
+
+ <para>The ability to invoke foreign exported Haskell
+ functions from multiple OS threads.</para>
+ </listitem>
+ </itemizedlist>
+
+ <para>With <option>-threaded</option>, calls to foreign
+ functions are made using the same OS thread that created the
+ Haskell thread (if it was created by a call to a foreign
+ exported Haskell function), or an arbitrary OS thread
+ otherwise (if the Haskell thread was created by
<literal>forkIO</literal>).</para>
<para>More details on the use of "bound threads" in the
threaded runtime can be found in the <ulink
url="../libraries/base/Control.Concurrent.html"><literal>Control.Concurrent</literal></ulink> module.</para>
-
- <para>The threaded RTS does <emphasis>not</emphasis>
- support using multiple CPUs to speed up execution of a
- multi-threaded Haskell program. The GHC runtime platform
- is still single-threaded, but using the
- <option>-threaded</option> option it can be used safely in
- a multi-threaded environment.</para>
</listitem>
</varlistentry>
</variablelist>