Jump to content

  • Log In with Google      Sign In   
  • Create Account

Two steps forward, one step sideways

Posted by ApochPiQ, 09 December 2013 · 542 views

Epoch language design
Over the weekend, I finished the last of the Epoch compiler support for templates. This means that, in theory, the Epoch-implemented compiler is capable of passing every test in the compiler test suite that I use for the C++ version of the compiler.

Unfortunately, I introduced two regressions along the way, which will require some tweaking to get fixed. No more than a day or so of work, though.

Given that the majority of the compiler is done, I went ahead and tried self-hosting last night, just for shiggles. The results were very informative.
  • Garbage collection is happening too frequently and creates ridiculous stalls when collections occur during parsing and semantic analysis.
  • Disabling the garbage collector causes the parser to chew up a huge amount of memory, but it makes parsing actually fast enough to bother with on large projects (like the compiler itself).
  • There are still a lot of edge cases that aren't handled by the compiler - mostly bits of syntax that are strictly legal in Epoch but haven't been totally shored up yet.
  • There are also a lot of built-in functions and operators that aren't recognized by the compiler yet; this is easy to fix, though.
My biggest conclusion is that the compiler will be driving a very heavy reimagining of how memory management works in Epoch. I already knew I wanted to fix some of the annoyances with how it works, such as heap-allocating all aggregate types all the time, but this is going to take more than just refinements of the existing systems.

It also brings me to a major decision point that I have been avoiding deliberately for a long time: how to handle manual memory management strategies in a type-safe way. The fundamental difficulty is that it's currently impossible to ask the language for a chunk of memory that isn't directly bound to a type - I can't even make an array of a type and do some hacky kind of object pooling.

Fixing this will take a significant amount of design and planning, to ensure I don't wind up crippling the type system or some such.

There's also going to be a lot of optimization necessary in the compiler implementation itself, and that's going to require richer language features and standard containers and all that jazz.

So while I might actually get self-hosting done by the end of the year (which was my original goal), I've unearthed a huge backlog of new stuff to work on in 2014 :-)

One step sideways is better than a step backwards. :)

I really think this is a nice project. I've always wanted to make a language and compiler, I just never had the time to do. What you've accomplished is pretty awesome.

May 2016 »

2223242526 27 28