Native Binary Project: Day Whatever

Published October 27, 2014
Advertisement
I continue to hack on the Epoch compiler, slowly shaping it into a powerhouse of executable binary generation. So far I've gotten the program string table and DLL import table built in a flexible and extensible manner. This is the first step towards getting actual code generation back online at full capacity.

Now that I can link to DLLs from native Epoch programs, I can start replacing the old runtime library with a newer, cleaner, and slimmer version. As part of the process, I'm rewriting the LLVM bindings, which means that code generation is going to be broken for a while, at least in part.

A few minutes ago, the compiler generated a rudimentary .EXE that imports the new Epoch runtime DLL and calls a function in it. This is all completely flexible - none of the data is hardcoded or hackish to make it work. This is in direct contrast to the old method of building Epoch .EXEs, which basically amounted to hardcoding a tiny program that launched the main program after JIT compiling it with LLVM.


My goal here is to do absolutely everything I can in Epoch, and slice out as much C++ code as possible. I'm still playing around with ideas in my head for how to make the LLVM bindings as slim as possible, but it shouldn't be hard to seriously cut down on the amount of fragile C++ hackery being done there.


It's kind of annoying how much sheer effort I can dump into a project like this, and then be able to summarize the entire affair with a single sentence. I'd rail on about all the detailed hacking and prodding that went into making this happen, but it's actually pretty boring and involves a lot of profanity. So instead, I'll just leave you with a short journal entry.


And now to bed, and now to bed.
8 likes 7 comments

Comments

tnovelli

hehe, yep... compiler implementation takes 10-20 years to really get the hang of it. LLVM probably isn't helping you that much; at least, I always thought parsing was by far the hardest part.

It's not a waste though.. it's good practice. Makes you a real programmer. :D

October 27, 2014 01:19 PM
swiftcoder

The LLVM assembly language and code gen backends are extremely valuable - writing optimal assembly generation for N different CPU architectures is a nightmare I'd rather not dwell on, and even simple-sounding tasks like register allocation consume an ungodly amount of time and energy.

The C++ library part of LLVM I'm still not sold on. My current project just emits llvm assembly directly, and it seems to be a simpler solution than binding the LLVM API to yet another language...

October 27, 2014 03:18 PM
ApochPiQ
The only reason I mess with the LLVM C++ API is so that I can statically link in the LLVM codegen. I don't feel like making my users run a separate third-party tool to compile their programs.
October 27, 2014 06:16 PM
Washu

That being said, I wouldn't mind just having it broken out to produce LLVM IL and then later plug in the compiler chain.

October 28, 2014 08:00 AM
swiftcoder

Makes sense. Though I've become rather fond of the *nix compiler-as-filter-chain paradigm.

October 28, 2014 02:54 PM
ApochPiQ
The chain-of-simple-tools philosophy has a strong appeal to me as well; but I'm torn between that and the reality of developing primarily on and for Windows. The Windows paradigm, for better or worse, is basically defined by Visual Studio, and that's a very "integrated" sort of setup.

There are other motivations for wanting LLVM codegen embedded in my tools, though - such as building a next-generation REPL into the IDE, something I have speculated on in the past but not revealed much about yet.
October 28, 2014 04:20 PM
Washu

Well, to be honest, I do a lot of my consumer usage in OS-X, so... being able to migrate epoch over to *nix is something I would very much like to do. It's a lot easier to do with a chain of tools, especially when we can simply change one single tool (the compiler) to later be fully integrated.

October 29, 2014 01:46 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement