Currently, the parser loads raw text code and converts it to lists of "operations" within memory; each operation is an atomic action (from the language's point of view) and includes things like assigning values into variables, invoking function calls, and so on.
Up until now, that binary data has existed purely in memory. As the language - and, specifically, the grammar - becomes more complex, it takes increasingly long to parse that raw code into binary form. To get past this, I'm working on caching the binary data into a separate file for faster loading and execution.
There's another motivation for this engineering decision as well: I will be converting the VM from a standalone EXE to a standalone DLL. You feed the DLL a binary Epoch file, and it executes it. The VM DLL will be totally self-contained, aside from the interface to A) get the version and make sure it is compatible with the binary code, and B) fire off the execution of the program itself.
Therefore, the new Epoch toolchain will look something like this:
- Text editor for the coding phase (will eventually be an IDE, possibly integrated into Visual Studio)
- Binary conversion pre-pass tool (outputs binary code)
- Code optimization and static verification pass (refines binary code)
- Execution stub (a simple platform-specific executable that invokes the VM
- VM DLL which actually executes the binary code
This introduces the pseudo-code compiler tool, which will take the results of the binary conversion pass (and, someday, the results of the optimization pass) and bury it inside an EXE (or whatever local platform-dependent packaging). The EXE will be a simple stub that reads the pseudo-code data from disk and passes it into the VM DLL for execution.
Ten bonus points to anyone who knows where I got that idea [wink]
There are a couple of major advantages to doing this. First and most significantly, it allows the distribution of binary-format (as in .EXE) Epoch programs, and will be available very soon in the development cycle. Coders will be able to write Epoch software and have it run on any machine. Secondly, by splitting the VM into a DLL, all Epoch programs on a local system can use the same VM code, without having to have a copy of the VM itself embedded in each program. This is basically how most real-world VMs operate anyways.
One concern with the binary format is that it is actually easily converted back directly to raw source code, since it stores variable and function identifiers as raw strings. I might look into making an obfuscation pass for "release mode" binaries that don't need debug information like variable names. That should be fairly straightforward.
A couple of hurdles remain before Epoch is ready for prime-time usage in writing Win32 apps. First, we have no support for structures, so most of the Win32 API is inaccessible. Getting this into place will be a major bit of work, since basically the entire object and type system will need to be implemented in order for structures to be supported in a first-class way.
The second big hurdle is adoption. Someone (preferably besides me) needs to take the time to actually write a nontrivial program in Epoch, and take note of any deficiencies in the language's features. These will then be made the priorities for further work on the language itself. In this way, I can keep development rolling smoothly while ensuring that the "real-world" pragmatic edge of the language stays sharp.
So far, I have to say the adoption rate thus far looks pretty disappointing. I can only really blame one thing for that: there's no damn reason to use Epoch to write Win32 software if you already know C. Or C++. Or any of the .Net languages. Or any language, really.
I need a selling point that makes the language superior to existing alternatives. I'm especially competing with .Net and (eurgh) Java on that front. Of course in the long run the main thing that will make Epoch attractive will be its support for multiple processing paradigms, but that has to come after the foundations are fully laid.
So this looks to be a bit of a chicken/egg problem. Bootstrapping the language itself has been fairly easy, but getting it to a point where it is not only a viable but a preferable option will be difficult I suspect.
Oh well. I didn't start this damn project because I thought it'd be easy [grin]
