CPC README
**********

CPC is a programming language designed for writing concurrent systems.

The CPC programmer manipulates cooperatively scheduled threads; the CPC
program is then processed by the CPC translator, which produces highly
efficient event-loop code. In the author's opinion, this approach gives
the best of the two worlds: the convenience of programming with threads,
and the low memory usage of event-loop code.

The semantics of CPC is defined as a source-to-source translation from
CPC into plain C using a technique known as conversion into Continuation
Passing Style.

Requirements:
-------------
    - autoconf
    - gcc (or another C compiler, but this is untested)
    - Ocaml >= 3.12
    - (optional) Latex, to build the cpc manual (in doc directory)

Installation:
-------------
To build cpc, you juste have to run from the root directory:

    ./configure  (or FORCE_PERL_PREFIX=1 ./configure --prefix=...)
    make
    make test    (optional, run full CIL test suite)
    make testcpc (optional, run CPC test suite)
    make install (optional, as root unless you used --prefix=... above)

This will build the main executable (bin/cpc.native, or bin/cpc.byte if your
platform does not support native OCaml compilation).  It also builds the cpc
runtime (in runtime directory) and a bunch of samples (in samples directory).

At last, if you want to clean everything:
    make uninstall
    make distclean

How to use:
-----------
To compile a cpc program, use the wrapper in bin/cpc for .cpc files, just like
you would use gcc for .c files.  Since you need to link to the CPC runtime
library, do not forget to use the following flags:
    -I cpc -lm -pthread -lcpc

For example:

    bin/cpc -I include/cpc -lm -pthread -lcpc -o samples/loops samples/loops.cpc

If you want to inspect intermediate .c files generated by CPC, use --save-temps.

Options:
--------
bin/cpc has the following useful options:

--stage n           perform transformations up to stage n
--pause             step by step cps marking [*]
--goto n            choose the goto elimination method (0 <= n <= 2)
                    0 is the "safe" one (no optimisation), 1 is the "smart"
                    one and 2 is the "too smart" one (trying to build smaller
                    functions, thus ending with some unnecessary ones).
                    1 is the default and recommanded method. Other methods
                    produce generally bigger and slower code.
--tr cpc            print (a lot of) debug messages
--tr cpc_stats      print some (raw) statistics
--dumpcfg           creates a cfg directory and dump the control flow
                    graph of every cps function in it (in .dot files)
--debug debug       include debug printf in the generated code
--out file          output file
--external-patch    cpc_patch from cpc_runtime.h instead of inlining it.
                    This is useful to remove some warnings if you use
                    --check (which checks the correctness of the CIL AST
                    after CPC transformations).
                    This is now the default.  Use --noexternal-patch to inline
                    patching code.
--packed            build compact continuations.  This saves some memory but
                    yields unaligned memory accesses.  It is broken on some
                    architectures, and requires that every CPC code be compiled
                    in packed mode (include the runtime, see cpc_runtime.h).

and a gazillion useless ones, inherited from CIL, that you might
discover through bin/cpc --help. Using some of them might break
cpc completely, so use at your own risk!

[*] In step by step mode, here is what you can do at each step:
    d<Enter>    dump the current file
    q<Enter>    quit (saving the current file)
    r<Enter>    exit step by step mode
    <Enter>     perform another step

Known bugs and limitations:
---------------------------
Condition variables must not be used in detached mode.  Others limitations
might be found in the CPC manual (doc/cpc-manual.tex), which you should read
anyway.

CPC relies on CIL, which makes a number of assumptions about
the underlying C machine and compiler. These assumptions are defined
when ./configure is executed. As a result:
- if you move on another machine/architecture/compiler, you should
  re-run ./configure.
- if you want to cross-compile, you must use the CIL_MACHINE environment
  variable. See the CIL documentation and src/machdepenv.ml for further
  details.  Another way is to use qemu-user to run machdep-env; when cross-
  compiling with the autotools, this is already done for mips-linux and 
  mipsel-linux architectures.

Please do not hesitate to report any bug at <kerneis@pps.univ-paris-diderot.fr>.

Further details:
----------------
Current information about cpc can be found on the cpc web page:

    http://www.pps.univ-paris-diderot.fr/~kerneis/software/cpc

The current version of cpc is built upon the CIL framework. Development
version in kept in sync with CIL svn, but some CIL features have been
disabled in cpc.  If you want more information about CIL, you'll find
the (automatically generated) documentation in doc/html. Also checkout:
http://manju.cs.berkeley.edu/cil/ for the original CIL.

                           Gabriel Kerneis <kerneis@pps.univ-paris-diderot.fr>
                           Juliusz Chroboczek <jch@pps.univ-paris-diderot.fr>