Jump to content
  • Advertisement
  • entries
  • comments
  • views

Two steps forward, one step sideways

Sign in to follow this  


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 :-)
Sign in to follow this  


Recommended Comments

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.

Share this comment

Link to comment

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
  • Advertisement

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!