ubclaunchpad / durian Goto Github PK

Implement an optimizer that implements the Visitor interface.

Write EBNF for Durian, in file grammar.ebnf.

write bytecode VM

At the moment most errors in the parser cause silent failure; we should report these and prevent crashes.

32 vs 64

Decided on to use 64 across the board.

The VM currently takes a pointer to bytecode, but doesn't include the metadata or static data described on the wiki. Now that we have at least some bytecode being written to a file, we need to write the metadata at the top of every bytecode file, load the file after writing and pass it to the VM, and change the VM to take into account the metadata.

Implement a pretty printer that implements the Visitor interface.

Write source to bytecode compiler.

Implement RET and CALL opcodes as described in the calling conventions section of the implementation decisions wiki page, as well as a DurianObject to represent functions.

STORE:  top -> index
LOAD:   top -> index

LSTORE/LLOAD for functions

dependent on #57

String literals still need to be compiled. In particular, we would like to have (immutable) shared string literals in the static data section of the bytecode. To do so, the compiler will store a dictionary of string literals/static data indices, and when compiling of an entire source file is finished, the string literals will be written as appropriate to the static data section. The actual string literal nodes, then, will simply determine the appropriate index, push this onto the stack, and then output the NEWSTR8 opcode.

Implement a code generator that implements the Visitor interface.

Create a class to represent different types of tokens, storing the token type, value (if an identifier), literal (if a literal), and line number (at least).

Implement the actual lexer, taking a string and producing a list of tokens (as defined in #13).

Write lexer.

Write parser.

tagged union of type and value

finish design of Durian.

Set up a build system (possibly CMakeLists?) and hook it up to Travis for continuous integration.

It would also be good to have a basic main file and maybe a sample unit test (GTest?).

Write a small command-line game or utility in our new programming language.

We should add more unit tests of the parser, as well as stress-testing it with complex inputs.