Skip to content

Latest commit

 

History

History
92 lines (73 loc) · 3.55 KB

TODO.mkd

File metadata and controls

92 lines (73 loc) · 3.55 KB
Raw

PACT TODO List

Short Term

  • Flesh out design docs where needed
    Input from HLL authors very welcome!
  • But don't get caught up designing things we aren't implementing
  • Decide on some coding standards (package names, etc)

The following portions of the project are early code, and are planned to be replaced this summer:

  • src/packfile/ contains the beginning of a set of classes to handle PBC files in a structured way. It's mostly full of design notes and ideas.
  • src/disasm.winxed contains the beginnings of a PBC -> PACT disassembler.

Summer of Code 2012

Writing the lowest levels of PACT is a GSoC 2012 project by benabik. Here's a short list of what will be done:

  • Build framework: Makefile, test harness, etc.
  • Classes for the lowest layer of PACT (Packfile).
  • Disassembler for those classes (based on src/disasm.winxed)
  • Design a low-level assembly language
  • Implement that language

This roughly corresponds to the first three points on the long-term plan.

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, etc
  • Make that able to produce bytecode and PIR
    • Register allocation
    • Stage structure
  • Build simple assembly language on top of that
    • assembler and disassembler
    • Primarily for machine consumption and production
    • PASM replacement
  • Add control-flow graph primitives (basic blocks linked by conditionals)
  • Build complex assembly language on top of that
    • PIR replacement
    • More human useful features
  • Build AST that compiles to CFG
  • Build simple language on top of that
    • Example / Squaak replacement
    • Sanity check

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 the AST and see if any additional 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 PACT.

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 control flow graphs 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.