🎉 Celebrating 25 Years of GameDev.net! 🎉

Not many can claim 25 years on the Internet! Join us in celebrating this milestone. Learn more about our history, and thank you for being a part of our community!

Yawn

Published March 10, 2009
Advertisement
Today was mostly consumed by hunting down a couple of sneaky memory leaks and a crash or two. Somewhere in there I threw in an update from Boost 1.35.0 to 1.38.0, which made some breaking changes to the boost::spirit code used by the parse grammars. I wasted a couple of hours getting all that cleaned up, although there's still one annoying little mystery.

(For those interested, or who may know the solution, it's related to a missing STATIC_ASSERTION_FAILURE template. Right now I'm just providing the template myself since it's pretty simple, but if there's a proper fix I'd love to know.)

Aside from that, no major work got done; just assorted cleanup and making sure all the pieces are still in sync (especially all the divisions of the compiler/assembler/linker chain).


There is some good news for the day, though: I've worked out a clean and powerful way to ensure that side effects do not propagate out of their owner task. In other words, Task A can't screw with Task B's memory, and neither of them can talk to the "master" task which runs the entrypoint function.

This is done by traversing the generated code tree in memory and looking at what functions and operations are being performed. A simple flag records whether or not the traversal is inside a task, or inside a function called from within a task, etc. If this flag is set, any offending accesses to outside memory or certain types of functions is tagged. Once the traversal is finished, each problematic line of code is logged, along with the call chain that resulted in that line of code being evaluated. Code coverage with this method can easily be 100% because of the way the VM is designed.

So once the task safety stuff is in place, it should be basically impossible to introduce a bug into an Epoch program that arises from use of shared state - because there isn't any concept of shared state.

Of course, this also means that tasks are basically useless, until I get the message passing stuff finished. Only then can we reliably move data in and out of parallel tasks.


Once that is done, I plan to write up several documents about the language and a general sales pitch to take to GDC. Considering that's not too far away now, I'll probably be squeezing my schedule to get this done on time. However, if there is time left over, it'd be nice to cram in a couple more features.
0 likes 1 comments

Comments

Twisol
Wow, you're really making good progress. [grin] Good work!

~Jonathan
March 10, 2009 02:32 AM
You must log in to join the conversation.
Don't have a GameDev.net account? Sign up!
Profile
Author
Advertisement
Advertisement