Luna-Canis

Going to FINALLY start coding again. Just finished spiderman 3, ordered NEW GEAR, all new mac stuff to finally replace this poor Dell computer that I think I bought sometime in 2000 or so. 7 years old, I’m glad it made it this far. The Mac stuff should arrive within a week, so that should hopefully be enough time to put it together.

I just looked at the old ‘todo.txt’ in spa/app/spaExe, and I’m hoping that this blog will do a much better job of keeping track of shit than a single text file.

So the last thing I was working on was the grammer for the shading language. Lets see if I can get something decent compiled. I was working on lcc. I’m trying to get a simple example working that will produce the same output as the simd assembly that I hand coded. The problem (now that my memory is coming back to me) is that I was trying to find a way to generalize the compiler to handle geometry, images, everything possible. It would be kinda wasteful to try and figure out all generalizations now, I should just work on getting this example working for images. I just have to define some default variables (like size and position) and it should work.

Ah… also the default scalar flag I was thinking about. I realized that depending on context, we want scalar values to default to either doubles or float. I’m putting that in now… Done.. that was simple.

Now faced with the way to defined I/O variables. We *could* compile them into the compiler, but that’s definitely not the way to go. We want to have header files to define these variables. But then that brings up the problem of generalizing ‘include’ paths and using the c pre-processor. We’re not going to do that… I’ll hand code the global variables for now, we’ll try using the c-preprocessor later.

Added a globals keyword, so we can declare global variables. This will turn out to be more flexible than renderman or mantra. We will be able to declare user defined globals at compile time. The user will have to know what the expected I/O variable names are, but they can also keep some globals handy for computational/signalling purposes.

One aspect that I have to start dealing with is the whole varying/non varying temp variable initialization. With a little overhead, I can have user defined temp variables default as non-varying, and have them mutate to varying as needed. Keeps the overhead at a minimum as well. I was going to handle this on the fly, but on second hand, I think it might be easier to do as an operation in a 2nd pass. There are too many things to add and take care of.

GOT IT WORKING. 

The parser can suck in the full shader file that duplicates the assembly file test. Next is spitting out assembly code. Maybe by tomorrow??? YES

Today, we try getting the source to dump assembly code, which will be a monumental step for the shading language. We may begin rendering by the end of the week.

Trying to think about a strategy for doing temp variables for evaluating expressions. There should be a recursive virtual function, (re-implemented by VarValue) to take a tmp variable template, a tmp variable count, and an array of variable names and types to fill.

Also another interesting point, the root node of any expression doesn’t need a temp variable because it can write its results directly into the assigned variable. We need to initialize the root node of every exprssion to write its assignments directly into the assigned variable.

Got so much working today. The proof of concept for the recursive expressions calculating their own temp variables and creating assembly code WORKS. Unbelieveable.

I glossed over the extremely simple case: straight variable assignments, no expressions. Lets enumerate the different variable assignments to get things straight…

• vector = vector
• scalar = scalar
• vector[i] = scalar
• scalar = vector[i]

Actually, the first two cases are the same, we just make certain that both are the same type. So there will be a total of 3 new assembly commands, templated to handle the different data types and vector sizes.

Its pathetic when Apple can make hardware to run windows XP better than any PC manufacturer. The hardware hooks up perfectly, wireless runs, putting it together was great. Looking foreward to splitting up the SIMD virtual machine execution to the seperate Intel cores. 4 Threads!! We’ll see.

For now, I spent the last two days putting all the old windows stuff onto the new machine. Installed msvc7.1 no problem. Got the old Ultrafractal stuff back. MAN, thats so fast its scary. Better yet, we’ll see how long it takes to port to the mac side. That would a GUI port to fltk, but that would be the end goal anyway.

Got the entire test script (test6.shd) to compile and produce good object code. Of course, it doesn’t work, so I’m finding I need to also be implementing debugging commands as well. Starting with our old friend printf. But this also points out something I forgot in the grammar definition. I hadn’t allowed for expressions that produce side effects, expressions that are just function calls. So I’ve inserted it into the grammar, and I’ll be producing some printf commands as well.

Implementing was a bit tricky. I required some grammar debugging, and some research into how Spirit grammars work. I forgot that actions tied to rules get executed as soon as they’re matched, so I was chasing some ghost bugs for a while. I also forgot about the role of errors and having an initialized stack for expression parsing. Once I got these out of the way, I correctly had expression statements implements. Even got a print command started for debugging.

Unfortunately, there is still something fundamentally wrong with the variable linking stage. The base example is missing values, and anything more complicated coredumps. So I’ll have to have that working before getting any print commands implemented.