README 3.1 KB

123456789101112131415161718192021222324252627282930313233343536373839404142434445464748495051525354555657585960616263646566676869707172
  1. Overview
  2. ========
  3. There are three binaries in the toolchain:
  4. - The compiler "civcc", which compiles CiviC source code to assembly source
  5. - The assembler "civas", which compiles assembly source to an object file that
  6. can be run by the VM.
  7. - The virtual machine "civvm", which runs one or more object files, one of
  8. which should export a "main" function.
  9. Additionally, there is a run script "civrun" which takes one file name argument
  10. and runs it through the entire pipeline, deleting intermediate files
  11. afterwards. E.g. for the first assignment you may want to run:
  12. $ bin/civrun euclid.cvc
  13. Please enter an integer value: 60
  14. Please enter an integer value: 45
  15. 15
  16. Or even:
  17. $ echo 60 45 | bin/civrun euclid.cvc 2>&1
  18. 15
  19. The toolchain also contains the file "civic.h" which defines the CiviC standard
  20. library supported by the VM. It is practical to keep this in the same directory
  21. as the reference compiler binary, because the compiler adds the folder in which
  22. it resides in to the include directories of the C preprocessor (along with the
  23. current working directory).
  24. You may want to add the toolchain directory to your $PATH so you can run the
  25. tools without having to prefix "<...>/bin/" every time when using the
  26. toolchain. E.g. add to your ~/.bashrc:
  27. export PATH=$PATH:<directory_where_you_unpacked_the_toolchain>/bin
  28. Reference compiler usage
  29. ========================
  30. You can use the output of the reference compiler "civcc" as benchmark for your
  31. own compiler. Apart from the extensions in the language reference, it
  32. implements constant propagation/folding on compiler-generated variables, and
  33. also does rudimentary loop unrolling. You are not expected to reproduce this,
  34. these phases are just there to show you how even simple optimizations can have
  35. a significant effect on code size.
  36. Some other remarks about the compiler:
  37. - Optimizations can be disabled with the -noopt flag.
  38. - By default it reads CiviC code from stdin, and prints assembly to stdout, so
  39. you can use it with unix pipes.
  40. - The "-v 2" verbosity option makes it print the AST after each phase, showing
  41. you step-by-step transformations. This can be very useful when you are
  42. confused about what a milestone should do. You can compile simple example
  43. file and see how the reference compiler transforms it in the different phase.
  44. Use -noopt as well if you want to get something closer to what your own
  45. compiler should do (since you don't need to implement optimizations).
  46. - the "-upto ..." argument makes the compiler stop after a certain phase and
  47. print the AST (or assembly) at that point. E.g. when you are implementing
  48. context analysis and want to compare your output to that of the refrence
  49. compiler, use "-upto context" or "-upto context -v 2".
  50. - The generated assembly code contains comments that shows to which CiviC code
  51. it corresponds. This can be used for relating instructions to AST nodes
  52. during debugging, and we recommend you do the same in your own compiler
  53. (although it is not required). Note that the last optimization phase
  54. (peephpole optimization) strips these comments, so you will need to pass "-v
  55. 2" or -noopt to actually see them. You can also disable them completely by
  56. passing "-v 0".