Luna-Canis

I think I found some Spirit examples that could solve my grammar problems. I haven’t been able to implement any post expression operators recusively, such as ++, generalized functions, or dot operators. They require left recursion, which is something Spirit can’t handle. But I found some examples that can transform them to right recursion grammars.

Getting some good results. Currently I’m hacking the prefix operators, and the only postfix operator ([]) is also a hack. It would be good to get all this working.

The right recursion worked. I can create and chain post operators. That means that I can do matrix[i][j][k], things like that. Also, the way I was linking parameters subtypes using ‘prm(”opName.i”)’, which is a hack. Now I can do ‘prm(”opName”)[i]’, which is what i originally intended. I have to verify that the []operator works properly with the smd code generation. Post-increment operators (++,–) are now possible.

Another things that got taken care of, is the fact that my previous method for handling [] never allowed for an expression, or a varying index argument. I would have found this out eventually, so I’m glad I found it now. Promoting the [] to a full blown operator was the only way to move forward.

vector[i] = 1.23 works.

I had some trouble with the pre-post operator precedence. So ++p[0] was evaluated as (++p)[0] instead of ++(p[0]). This gives the wrong results since we want to increment the first element of p, not increment the entire vector, then return the first element. But that works now.

The remaining thing is whether I can get the callable chaining, methods, etc. to play nicely with the existing function calling mechanism I have in place. Hopefully not….

As a first test, I was able to implement callable functions on complex numbers. Deciding where to hook in the functionality went back and forth for a bit. First, I bundled it with spa::Value, but it ended up being bundled with the spa::Type. It ended up being a neater implementation, and I had to change fewer header files.

Methods work. So I got z(10.)(20.).abc(-3) to parse and execute correctly.

Members work. z.re = z.im = z[0] works.

To re-iterate how to do this, we call spa::setMethodCtor and spa::setMemberCtor for defining methods/members for an object type. The symbolTable calls spa::getTypeMethod and spa::getTypeMember on the object type for resolving.

Since I’m running the uf compiler under the Bwain executable and not the compiler, I’m finding that different groups of operators/functions/objects are being initialized. Things that compiled under lcc don’t compile with Bwain, and vice versa. Which brings us to the inevidable reconciliation of the two expression types, one under spa and one under smd.

I’ve verified the problem. When I compile stuff under Bwain, the expression language is a mix of smd and spa Funct nodes. So I currently don’t know which nodes are able to produce asm and calculate tmp varaibles.

As a solution…. I think I can have the bootstrap functions have a symbol table passed in. That way, I can have multiple symbol tables for different environments. For starters, I have need to define two tables, one is an application level symbol table, another for simd compilation. Also don’t want variables getting mixed up between both environments.

I’m eventually going to have to develop Bwain and the Matrix library seperately, so I figured that having a separate categories would help.

Found some text on writing numerical libraries in C++. I know I have to implement different matrix storage types, and I know not to use a base class with virtual methods for access. I came across the idiom for Curiously recurring template pattern. I want static polymorphism, not dynamic polymorphism. Each time I use a matrix, I know its type at compile time, so any runtime polymorphism is a waste of cycles. I’m going to use this to define a templated base class for matrices, then fill in the blanks.

Matrix types. I’m planning on doing row and column major implementations

• Dense
• Banded
• Upper/Lower Triangular
• Symmetric
• Block
• Sparse

For each, I need the following operations, for row and col major matrices.

• saxpy row
• saxpy col
• vector/matrix row
• vector/matrix col