chrishowie.com

Over two nights of hacking I implemented a movement filter that’s compatible with the AVS Dynamic Movement effect.

Google Video was giving me grief, so I posted it on YouTube this time:

Lately I’ve taken to hacking Affe quite a bit. Just a quick list of a few changes:

• Value types can now be the target of invocations.
• A value type will be automatically boxed when being cast to an interface that it implements.
• Any object type can now be unboxed. This fixes the case where a value type boxed into an interface type could not be unboxed without being cast to System.Object first.
• Any expression can be used as a boolean. Reference types will be compared to null, and numeric values will be compared to 0.
• Added the &&, ||, and ?: operators.
• null is now a keyword.
• Fixed a parser bug that would cause syntax errors when the sequence “(identifier)” was encountered and did not begin a CastExpression.
• The == and != operators can now be applied to reference types.
• OperatorExpression now checks for operator overloads and uses them when present.
• Arrays and types with indexers can now be indexed.
• Added support for single-line (//) comments.
• Added a “local bag” which is used when building locals.

The last item could use some explanation. It’s a size optimization really, and probably unneeded, but I’ve always thought something like this would be neat for mcs to have. This implementation is my proof-of-concept.

There are a lot of things that require extra locals to be defined. For example, if some method returns a value type and you’re directly invoking on it (for example, somestring.Length.ToString()) then there are two IL sequences that could be used. Assuming the int is on the top of the stack, the first is box System.Int32; callvirt instance string object::ToString();. This is what seems intuitive, but there’s a reason mcs does not do this. Boxing creates a new object, and that object must now be garbage collected. It’s much more efficient to use the stack for value types. So instead of boxing, a new local is declared, say “temp”, and this IL is used: stloc temp; ldloca temp; call instance string int32::ToString();. No boxed object, no virtual method resolution, no additional strain on the GC, no wasted heap. But now we have another local.

What if you hard-coded ten such calls? That’s right, you get ten locals. The JIT may be smart enough to optimize them out, but the IL is still going to be bloated. That’s where my local bag comes in. When such an expression is compiled in Affe, it asks the compiler state object for a local from the bag, for temporary use. The state will look through a list of unused locals it has and will return the first it finds of the same type, but will keep it in the unused list (since the callee said it’s temporary). If none can be found then it will create one and add it to the list. (If the local was requested for permanent use then it would be removed from the list if it was there, or if it wasn’t then it won’t be added to the list.)

The upshot of this is that if you make 10 hardcoded invocations against a value type that’s being returned from somewhere (or even a constant) they will all use the same local, assuming they’re all the same value type.

Now consider the case where you have this code in C#: if (foo) { object o; ... } else { object o2; ... }. This is admittedly contrived, but it does the job. We have two scopes with a variable of the same type. With mcs you get two locals. With Affe you get one.

To maintain scoped variables, the Affe compiler state maintains a stack of symbol tables. Each block has its own table that is pushed prior to analysis, then popped, and again for the compile pass. When a table is pushed, the state will check for symbols that correspond to locals and will remove them from the local bag if present. Then when popped, all the locals are added to the bag. So in the example above, the “if” block’s table is pushed during analysis and a new local symbol is added. Then it’s popped, and the local gets put in the bag. When the “else” block’s analysis is run and it asks for a local of type object, the one from the bag is handed to it.

It’s not a terribly major optimization, and I expect in Affe’s case it actually takes more time during compilation than it saves during runtime, but I’m interested if this would be interesting for the mcs hackers. I imagine it would eliminate a fair amount of IL bloat.

I have finished removing Lua from Kaffeeklatsch and have enhanced Affe with the ability to bind field, property, and method calls at runtime. I noticed this gap when rewriting some of the key binding scripts; where I could just set a field before, my compiler threw an exception since it could not find the field on the IEffect interface. After wrestling with this for a while I finally came up with another hackish solution: a new operator.

The period operator binds during compilation, and the new dollar sign operator binds during runtime. Instead of the standard target-arguments-call emission, it emits a call to a static method declared inside Affe that takes the target object, the member name, and an object[] containing the call parameters. This method performs logic similar to a compiler-bound call (in fact, basically identical logic) except using the target’s runtime type. One annoying pitfall of this technique is that since the return type cannot be known at compile time, a late-bound invoke necessarily returns an object. And, of course, to unbox a primitive you must perform an exact cast.

Since I didn’t unbox automatically I added a parenthetical cast operator to Affe so that late-bound return values can be unboxed or converted. (Note that boxing is automatic.)

So where something like Effect("fountain").Rotate = true; would make Affe choke, this can now be written as Effect("fountain")$Rotate = true;.

I am toying with the idea of flagging certain types to be intelligently bound. For example, if IEffect was so flagged, the compiler would try resolving the call and if it could not bind it, would convert the expression to a late-bound call. This would give all the speed of compile-time binding where possible, and fall back on runtime binding when that failed. Since I’m trying to make Affe basically a fast scripting language for .NET, this is optimal. It may make debugging harder since errors are not caught at compile time, but you’d have that problem with the $ operator anyway.

I got Kaffeeklatsch back out of the toy box the other day and started integrating the Affe compiler into it. The goal is to remove Lua entirely, as it’s an unmanaged dependency and has been giving some odd errors as of late, crashing mono after a few seconds.

The SuperScope effect has been completely converted over from Lua to Affe. (Keybindings and the Custom effect are next on the list.) To celebrate this achievement I have posted a teaser video on Google Video. The quality is pretty horrible and there is no audio, but you get the general idea:

There are a few effects you are seeing here:

• Clear screen is responsible for the slow fadeout to black.
• The flames, blue scope, and neon lines are all instances of the SuperScope effect with different Affe scripts.
• The multicolored star is a FountainScope effect.
• About 13 seconds in I turned the Laser effect on. This instance draws moving black rays from the center.

Every effect is a managed object; SuperScope is the only one in this video that uses user-supplied scripts; the others can have other parameters tweaked from the Gtk# preset designer.