Skip to content


Subversion checkout URL

You can clone with
Download ZIP
100644 165 lines (124 sloc) 6.54 KB
c8a35b0 @Benabik Use more obvious header formatting
Benabik authored
1 Parrot Alternate Compiler Toolkit
2 =================================
2f8b563 @leto Add a readme
leto authored
a34eb92 @Benabik Organization, part 1: README
Benabik authored
4 This is a redesign and rebuild of the Parrot Compiler Toolkit (PCT), which
5 is installed with Parrot. PCT provides a quick and easy framework to build
6 high-level languages (HLLs) on Parrot, but has its limitations. The main
7 goal of PACT is to provide the same ease of use as PCT, but add easier
8 extensibility, more power, and more features. This project was sparked by
9 benabik++'s comments during his Google Summer of Code 2011 project.
2f8b563 @leto Add a readme
leto authored
a34eb92 @Benabik Organization, part 1: README
Benabik authored
11 Currently the project is in the planning stages and this repository contains
12 notes and design documents. Assistance, forks, and commentary are welcome!
63c9bcb @Benabik Update README
Benabik authored
14 PACT is written in Winxed and requires the
15 [Rosella]( library to build and test.
16 However, no dependency on Rosella should be required for the compiled
17 library.
19 Repository Tour
20 ---------------
22 ### Makefile / setup.winxed
24 The Makefile is just a thin wrapper around a distutils/Rosella based
25 setup.winxed. You can give either one the following commands:
27 * `build` (the default): builds all libraries and programs
28 * `test`: runs all tests in the the `t/` directory
29 * `install`: Installs the libraries and programs in the same location as Parrot
30 * `clean`: Removes all libraries, programs, and intermediate files.
32 ### docs
34 This directory contains Markdown files that are design documents for PACT.
36 ### pact
38 This directory includes the actual PACT library. The library is built in
39 pieces. Each section of the library is either a single winxed file or a
40 directory containing winxed files that are collected together into a single
41 packfile.
43 ### src
45 This directory includes sources for all the programs created by this
46 project. The resulting executable is prefixed with `pact_` and is based on
47 the filename of the source. At the moment this is just `pact_disasm` which
48 is built from `src/disasm.winxed`.
50 ### t
52 This directory includes the tests for the PACT library. Each test file
53 should end with `.t` and output TAP. (Generally by way of the Rosella.Test
54 library)
c8a35b0 @Benabik Use more obvious header formatting
Benabik authored
56 Project Goals
57 -------------
a34eb92 @Benabik Organization, part 1: README
Benabik authored
59 * Ease of Hacking
60 * Similar to PCT
61 * Modular and Flexible
62 * Test-Driven Development
63 * Bytecode Generation
64 * Typed
65 * Optimizations
66 * Round-Trip Code
67 * Use Compiler Best Practices
69 ### Ease of Hacking
71 PCT was written in PIR, which gives it a lot of access to the Parrot VM,
72 but makes it very difficult to work on. To make the source easier to work
73 on, PACT will be implemented in Winxed, which gives most of the power of
74 direct PIR but in a far more expressive form.
76 ### Similar to PCT
78 There is a lot of experience in the Parrot community with PCT, and its
79 value in developing large compilers has been proved by Rakudo. PACT does
80 not strive for 100% compatibility, but the features and interface of PCT
81 should be kept in mind while designing/building PACT.
83 ### Modular and Flexible
85 While PACT will strive to be a one-size-fits-all toolkit, we must also
86 recognize that someone will always have something that doesn't quite match
87 what PACT does. PACT should be designed in pieces that are easy to use
88 individually, replace, and combine in new and interesting ways. There are
89 some uses in particular to keep in mind:
91 * Alternate lexing/parsing frameworks
92 * Including low-level code in high-level <br />
93 (Think POST nodes in a PAST tree. A more structured version of inline
509afea @Benabik Typo/whitespace fixes
Benabik authored
94 nodes.)
a34eb92 @Benabik Organization, part 1: README
Benabik authored
95 * Compiling portions of a program.<br />
e7aed76 @Benabik Notes on REPLs
Benabik authored
96 (Given a PAST expression, return a POST expression not a full program.
97 Particularly useful for REPLs and eval functions.)
a34eb92 @Benabik Organization, part 1: README
Benabik authored
99 ### Test-Driven Development
101 When working on as complicated a system as a compiler, it is very difficult
102 to determine ahead of time what will break when you alter a section of
103 code. A thorough testing framework will help ensure that the compilers
104 that depend on PACT will not break due to updates.
106 ### Bytecode Generation
108 PCT was very tied to the structure of PIR. PACT is intended to be designed
109 with the idea of building directly to bytecode from the start. In
110 particular, this means that no portion of the system can rely on simply
111 generating PIR that does the right thing.
113 On the other hand, PIR is an extremely useful format. PBC is not stable
114 across versions of parrot, so being able to save PIR bootstrap steps is
115 invaluable. Other backends such as Winxed may also be useful.
117 ### Typed
119 The key to building sane bytecode is maintaining knowledge of what type
120 every value in the tree is intended to be. Because of this, every PACT
121 node should maintain an idea of what type it returns (even if this is
122 'void'). In addition, passing around information encoded into strings
123 makes further processing of it very difficult so all information in the
124 tree should be a PACT node. (For example, registers should be
125 `'P', 2)`, not `'$P2'`.)
127 ### Optimizations
129 While creating fast code can be done by hand, it is usually far more
130 convenient to write what you mean and have the computer make it faster.
131 While optimizing code is not required for the design of PACT, it should be
132 simple to add and customize. Notably, the [tree
133 optimization]( project should
134 be integrated very deeply into the system.
136 Some basic optimizations like constant folding (for non-PMC values) and
137 dead code elimination can be implemented quickly. More complex
138 optimizations involving SSA and data-flow analysis are not required, but
139 the ability to perform them should be kept in mind.
141 ### Round-Trip Code
509afea @Benabik Typo/whitespace fixes
Benabik authored
143 Generating high quality code is difficult when the output of the compiler
144 is opaque. PASM is a mostly dead format and PIR is often derided for both
145 the amount of hidden work it does and its compiler IMCC. New assembly and
146 intermediate formats are required. These formats should be as easy to
147 generate and process as possible.
a34eb92 @Benabik Organization, part 1: README
Benabik authored
149 The ability to store arbitrary objects in bytecode files means that not
150 every PBC can be regenerated faithfully from disassembly, but handling the
151 simple cases will keep the disassembler honest and make code generation
152 easier to test. Human-readability is key, but ease of writing is not.
154 ### Use Compiler Best Practices
156 Recommended reading: The Dragon Book (_Compilers: Principles, Techniques,
157 and Tools_ by Aho, Lam, Sethi, and Ullman)
159 Those who do not learn from history are doomed to repeat it. While
160 converting to multiple intermediate steps or worrying about SSA may seem
161 like unnecessary work, using similar phases and styles as other compilers
162 will make it easy to use the lessons learned from them. GCC and LLVM are
163 designed the way they are because it helps them generate fast and correct
164 code, so emulating them is no bad thing.
Something went wrong with that request. Please try again.