Browse files

Organization: TODO

Split out the implementation plan into its own document for ease of
finding.  Turns out I had already been fairly verbose there, so little
addition was required.
  • Loading branch information...
1 parent a34eb92 commit 8e34f71057d1f3799b94b203040fd2ff87a5e7d1 @Benabik Benabik committed Oct 5, 2011
Showing with 38 additions and 0 deletions.
  1. +38 −0
@@ -0,0 +1,38 @@
+## Short Term
+* Clean up brainstorming into real design docs
+* But don't get caught up designing things we aren't implementing
+* Build framework: Makefile, test harness, etc
+* Sketch (design and/or code) out lowest level compiler
+## Long Term
+One of the main motivations of PACT is generating bytecode. Instead of
+starting at the top and trying to ensure we keep everything we'll need
+around, starting from the bytecode and working our way up seems far more
+useful. The implementation plan looks a little like this:
+* Build a set of classes that mirror packfile layout.
+ * Populated with PACT classes like Sub, Op, etc instead of
+ PackfileConstantTable
+* Make that able to produce bytecode and PIR
+ * Register allocation
+ * Stage structure
+* Build assembly language on top of that
+ * assembler and disassembler
+* Build control-flow graph IR
+* Build tree-like POST (optional, POST may only be CFG level)
+* Build PAST
+* Build simple language that exposes PAST very directly (or convert existing)
+Share as much across layers as possible. (We want only one
+implementation/type for things like registers, variables, symbol
+tables, location information, etc.)
+Maintain as much type information as possible. If we start off with an
+integer constant, remember that all the way down to the bytecode.
+After that, start building top-down. Add features to PAST and see if any
+additional POST/CFG/bytecode features are needed to support it.

0 comments on commit 8e34f71

Please sign in to comment.