Taddeus Kroes 1c076c3774 Added something about reference compiler usage to toolchain README 11 лет назад
..
README 1c076c3774 Added something about reference compiler usage to toolchain README 11 лет назад
civic.h 7415320dd6 Removed comment in header file that triggers a cpp warning 11 лет назад
run.sh 4b9d4222bc Added toolchain target and restructured binary paths a bit 11 лет назад

README

Overview
========

There are three binaries in the toolchain:

- The compiler "civcc", which compiles CiviC source code to assembly source

- The assembler "civas", which compiles assembly source to an object file that
can be run by the VM.

- The virtual machine "civvm", which runs one or more object files, one of
which should export a "main" function.

Additionally, there is a run script "run.sh" which takes one file name argument
and runs it through the entire pipeline, deleting intermediate files
afterwards. E.g. for the first assignment you may want to run:
$ bin/run.sh euclid.cvc



Reference compiler usage
========================

You can use the output of the reference compiler "civcc" as benchmark for your
own compiler. Apart from the extensions in the language reference, it
implements constant propagation/folding on compiler-generated variables, and
also does rudimentary loop unrolling. You are not expected to reproduce this,
these phases are just there to show you how even simple optimizations can have
a significant effect on code size.

Some other remarks about the compiler:

- Optimizations can be disabled with the -noopt flag.

- By default it reads CiviC code from stdin, and prints assembly to stdout, so
you can use it with unix pipes.

- The "-v 2" verbosity option makes it print the AST after each phase, showing
you step-by-step transformations. This can be very useful when you are
confused about what a milestone should do. You can compile simple example
file and see how the reference compiler transforms it in the different phase.
Use -noopt as well if you want to get something closer to what your own
compiler should do (since you don't need to implement optimizations).

- the "-upto ..." argument makes the compiler stop after a certain phase and
print the AST (or assembly) at that point. E.g. when you are implementing
context analysis and want to compare your output to that of the refrence
compiler, use "-upto context" or "-upto context -v 2".

- The generated assembly code contains comments that shows to which CiviC code
it corresponds. This can be used for relating instructions to AST nodes
during debugging, and we recommend you do the same in your own compiler
(although it is not required). Note that the last optimization phase
(peephpole optimization) strips these comments, so you will need to pass "-v
2" or -noopt to actually see them. You can also disable them completely by
passing "-v 0".