sam-gc/lanky

A new interpreted language implemented in C

lanky's Issues

Constants should be copied

Right now constants are simply loaded from an array and pushed onto the stack, meaning they are treated all the same object, so in the case of

a = 5;
b = 5;
a.test = 8;
b.test == 8; --this line will return 1

Clearly this is not ideal.

No way to overload functions

Right now any class can only have one function with a given name; this effectively renders class declarations useless.

Single-line comments fail on the last line

If a comment is on the last line of a file, it will not be recognized by flex if there is no trailing newline.

Reimplement locals

In order to get closures to work, I made every variable save to the implicit function object in a trie. This is fine for closures and whatnot, but a lot of time is spent searching that trie and only a few variables need to be captured. GProf reported ~50% looking up members of that function object in a tight loop. This will significantly reduce time.

Compiler makes wrong assumptions about local/closure

The compiler makes bad assumptions sometimes about what is a local and what is not.

mempool.c slow

When the file size is sufficiently large, the compiler slows down the whole process. This could be fixed by tracking the tail of the mempool list, as well as the head.

Make data stack a block of memory rather than an arraylist

Right now an arraylist holds the data stack and consequently push/pops (very common) are actually relatively expensive. In a tight loop from 0 to 1,000,000, the array operations account for 30+% of the time. This is terrible. We can precompute the max depth of the stack so we should use that to block allocate the data stack.

Memory leaks

The project (and in particular the interpreter) is leakier than the RMS Titanic. Fortunately they should mostly be one-time leaks (i.e. caused by setup rather than actual code execution) so the performance of Lanky code should not be impacted. That said, I believe I introduced some new leaks with the closures so that will cause memory leaks during Lanky execution.

Jumps can only address up to 127 opcodes

The jump instruction gets arguments in the opcode. The argument for these instructions is an address to the next opcode to which to jump. Currently it can only address opcodes up to CHAR_MAX. This is obviously flawed... I think there should be two arguments to the jump opcodes: the first is a char representing the number of bytes in the address, the next is the address itself, which can span multiple bytes.

Locals are kinda broken

It is impossible to assign a vale to a global variable inside of a function.