Luna-Canis

Thinking of ways to combine old-school imagery with new. What more expressive archetype than the space invaders characters?? Ancient glyphs representing the FIRST time we saw computers as entertainment in the back of some old bar in the 80s? Click on the image to start the player. You can download the full rez version here.

Should really get started on cleaning up the todo list. The latest animation/project is done. The only thing that needs to be looked at on the creative side is printing up stills onto postcards. The animation controls would be a good place to start, but what I really should focus on is the unary/binary operator problem….

The yac grammar has an excellent breakdown of the c-language grammar. I’m going to base the new expression grammar structure on this. I’ve implemented a test program using it and it properly handles unary and binary operators. I’m going to re-do ExprGrammar.hpp and hopefully this problem will be in the past.

Although the grammar test works, I haven’t had a chance to verify that the operator precedence works properly. The grammar appears to be in the reverse order of the original ExprGrammar.hpp.

The operator precedence is working with the new grammar. AND I found out what was causing the problem with the single/double operators. The method I was using to resolve the operators would look at all arguments on the stack. So a unary operator would suck in two arguments if they existed. All I had to do is provide a modifier to tell the actor class the number of arguments to pop off of the stack. It works!!!

Since I know the problem, I suppose I could revert to the old grammar, but this new one is more cleanly structured. I’m just going to go foreward and try implementing the remaining actions. This grammar is very stable. I can parse things like “1 + —–2″, things that would have never worked in my old grammar.

Got the closure I used to hold the function name for doing nested function calls. 95% of the original expression functionality has been re-implemented. Oddly enough, the only remaining problem is being able to parse “1+1+1+1″ correctly. The old grammar could do this, but the new one can’t for some reason.

It was the ‘+’ unary operator. Got rid of that, and its all good. The new grammar appears to be fully functional.

Got the kinks out, and the another animated piece. Time to continue bulletproofing the SIMD virtual machine and try to make a serious go at emulating the Ultrafractal renderer. Two optimizations come to mind.

1. Have to keep track of constants and reuse them if they are repeated.
2. Have the virtual machine run in three modes. One where all the registers are allocated up front and deallocated when the machine is destroyed. Another where the registers are allocated and released as they get used. Another method could be a version that does garbage collection and periodically releases unused registers, with a varying number of instructions between each sweep. This would provide a tunable value for doing the memory/speed tradeoff. For very heavy programs, we would be forced to minimize the memory footprint. This would also be an interesting way to measure the max ram needed to execute.

On second thought, what would be optimal would be to calculate what the minimal number of registers required to execute the code, and just use that. Since the registers are just memory allocations and not type specific, we could calculate the max memory allocation needed for each register.

Ended up adding some meta-methods for the spa::Value class. To manipulate spa::Value and sort them linearly, I had to be able to define operator== and operator< on spa::Value, which would in turn, foreward the method to the ValueImp class.

A typical compiler task is the register allocation issue. A given CPU has a limited number of registers to execute all the temporaries needed to calculate a given expression. Graph coloring is used to determine how the registers can be optimally utilized.

Since we’re coding a virtual machine, our problem is different. Basic steps:igure out is find the minimal number of registers needed to execute a piece of code.

1. Figure out the minimal number of registers needed to execute a piece of code.
2. Map all temporaries to a given register.
3. Find the minimum size for each temporary.

Once this is implemented, it opens up some other interesting possibilities. We’ll be able to tell what the ram usage is. If we need for the virtual machine to have a smaller RAM footprint, we can open up the possiblity of allocating/deallocating more temporary registers as needed for RAM critical parts of the program. This would extend the working size of shader code, providing a tunable memory/performance control.

---

The solution is a graph coloring problem. Each Funct node is a graph node. Make a connection between nodes that depend on one another. If a set of nodes are arguments for a given node, (like a function with multiple arguments), all Funct arguments are interconnected. Then color the graph. The number of temporaries needed is the number of colors. Each node color points to the temporary used.So Boost has a Graph Library. I’ll have to see if I can use it easily enough….Christ…. My current Boost implementation is Boost 1.31. So I had to upgrade to the latest Boost 1.34. The MSVC 7.1 compiler just chokes up and spits all over the place with its ‘Internal Compiler Error’. Half the libraries wont compile. Sucks. The online docs say that boost 1.34.1 should fix a lot of the compiler issues.Compiling with boost 1.34.1 allows compilation, but creates executables that wont run. The runtime library wont enter the ‘main’ method. The graph library will have to wait.