Browse files

TODO: Add notes about PACT languages

Having a language at each level will be instructive and useful.  Also
add to documentation the idea that PACT assembly is intended to be
also implemented in C and used in favor of PIR.
  • Loading branch information...
1 parent 3195755 commit 340008ce3471acfed3c6827f0b64b666764435f3 @Benabik Benabik committed Oct 6, 2011
Showing with 25 additions and 3 deletions.
  1. +25 −3
@@ -24,10 +24,9 @@ useful. The implementation plan looks a little like this:
* 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)
+* Add control-flow graph primitives (basic blocks linked by conditionals)
+* Build tree-like POST
* 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
@@ -38,3 +37,26 @@ 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.
+## Languages
+Both as a sanity check and as a kind of textual IR, it would be extremely
+useful to build extremely simple languages on top of several layers of
+An assembly-esque language directly on top of our bytecode support classes
+allows for easy introspection of the output of the compiler. In addition,
+once a PACT assembly format stabilizes, it would be possible (and likely
+encouraged) to create a version of the assembler in C to function as a
+replacement for PIR/IMCC as the de facto standard for bootstrapping.
+An extended assembly language on top of the opcode tree format would be
+easier for human production and let them use the same standard shortcuts
+the compiler tends to. Alternatively, this could be a viable target for a
+system-level language like Winxed.
+A full language that exposes the high level AST as directly as possible is
+an excellent tool for testing new features and showing an example for new
+implementers. Ideally there will be many languages at this level, so an
+official in-core language is less vital but having some language use it as
+it is being developed will be key to creating a sane API.

0 comments on commit 340008c

Please sign in to comment.