Jump to content
  • Advertisement
  • entries
  • comments
  • views

Epoch - quick status update

Sign in to follow this  


So after the little existential whine-fest about Epoch a few days ago, I've found myself miraculously rejuvenated.

I credit this to two things. First, I started writing about the development process, which got me thinking about what's left to do and how much I really want the language. Second, I attended GoingNative 2012 - which is, by and large, a giant C++ party.

GoingNative was cool in its own right, but it radically cemented in my mind the certainty that Epoch is a necessity. All of the major outstanding issues in C++ programming are addressed (at least conceptually) by Epoch, and even a lot of the new C++11 features are done better (in my thoroughly not-humble opinion) in my conceptual versions of Epoch.

To this end, I've spent much of the past 18 hours hacking on Epoch vigorously. At the beginning of the marathon, the compiler was so utterly broken that (1) semantic checking didn't really even exist, (2) type inference was a distant dream, and (3) code generation was just plain never reached, because the compiler would vomit before it got there.

Throughout the course of these hours, I've managed to get a large volume of semantic checking down, and whittled away at spurious type system errors until the Era IDE source code compiles cleanly. There's still a few semantic errors that can't be detected by the current implementation, but I'll get those hammered out soon enough.

Type inference is loosely sketched in and shouldn't be terribly hard to return to the point where it used to be.

And, as of a few minutes ago, code generation is officially being performed again - although there are gaps in what it generates due to missing implementations of a few language features. The code can be generated but is hardly suitable for execution yet.

At this point, the challenges remaining in the R12 compiler rewrite are basically boiling down to reimplementation of language features. Notably, most of the language's overload semantics are broken right now, pattern matching is totally unsupported, and a fair few weird bugs are sure to be lurking in the semantic checker. This is a considerably more manageable chunk of work than what was left to do at this time yesterday... or at least, it seems that way.

As a final note of interest, parsing of the Era source code takes an average of 13ms on my crappy old laptop. Semantic validation is around 100ms, including the type inference pass. Code generation is about 7ms. This is stupid fast compared to the old compiler, which even in optimized Release builds was taking upwards of 30 seconds to do the same job. I estimate that the compiler is around 350x faster now, in a thoroughly unscientific set of tests. This is without optimizing memory allocation patterns in the semantic validation and AST transform phases.

Life looks really damn good right now.

[edit] Found some low-hanging optimization fruit in the semantic validation stuff. Down to 45ms, still without optimizing memory allocations. Can you say "daaayumn"?
Sign in to follow this  


Recommended Comments

So, after building the latest checkin in the repository (I submitted a patch to make it build against VS2010, and also to fix a few other issues)...

Running it against a simple file, on my laptop mind you:


Epoch Language Project
Command line tools interface

Executing: ..\Debug\test.epoc

Parsing... finished in 1ms
Validating semantics... finished in 0ms with 0 error(s)
Generating code... finished in 1ms



Enjoy [img]http://public.gamedev.net//public/style_emoticons/default/biggrin.png[/img]

Share this comment

Link to comment
By the way, I just grabbed Release 11 and couldnt find a way to compile/run the code through Era. So instead I fired up EpochTools in the command line with the command, "/compile blah.epoch out.easm" and it said "Output: out.easm" but the file was no where to be found. I looked around and finally did a search and the only file that popped up was in my user\appdata\local\virtualstore... Is that functionality just broken?

Share this comment

Link to comment
On a side note, could you elaborate on how the VM works and give more information on the instruction set? It would come in handy for a personal project of mine that im working on at the moment. I cant even tell how a conditional statement works by looking at the assembly, POOL_STR if?

Share this comment

Link to comment
The compiler isn't terribly intelligent about paths, so it's entirely possible that it just tried to write to c:\out.easm which would redirect to virtualstore depending on your Windows permissions/elevation. Try fully qualifying the path, that's how I usually run it. (Yes, needs improvement!)

As for the VM/instruction set - I'll be covering that in quite a bit of depth later in the series.

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.

We are the game development community.

Whether you are an indie, hobbyist, AAA developer, or just trying to learn, GameDev.net is the place for you to learn, share, and connect with the games industry. Learn more About Us or sign up!

Sign me up!