I reworked the compiler to perform some limited optimization with compares and jumps. I refactored the short circuited boolean and/or operators to be modeled in the AST as CondExpr using a list of operands - this makes it simple to share the same load true/false instruction when chained together like "a||b||c||d". Furthermore I optimized if statements so that when the condition is a CondExpr it skips loading true/false onto the stack and branches to the true/false block directly. These optimizations remove the ugliest cases of crud like "LoadTrue/JumpTrue" from the fcode.
I didn't take this optimization to the extreme like javac will do - for example "a&&b||c&&d" will still generate a lot of useless load true/false code. But for now I'm not going to complicate the assembler to optimize these more advanced cases.
Another thing I really wanted to do was to create special opcodes to coalesce comparisons and branches so that the Java/IL emit code could skip loading a Bool onto the stack, then having to perform the Bool.val field access. But I already handle this in the Java emit code by peeking if the next opcode is a JumpTrue or JumpFalse. Looks like you copied this code for .NET too Andy. The peek is pretty efficient - just a bit complicated. So effectively we already have implemented this optimization it's just at emit time versus assembly time - so I'm going to just leave it the way it is.
brian Sat 16 Dec 2006
I reworked the compiler to perform some limited optimization with compares and jumps. I refactored the short circuited boolean and/or operators to be modeled in the AST as CondExpr using a list of operands - this makes it simple to share the same load true/false instruction when chained together like "a||b||c||d". Furthermore I optimized if statements so that when the condition is a CondExpr it skips loading true/false onto the stack and branches to the true/false block directly. These optimizations remove the ugliest cases of crud like "LoadTrue/JumpTrue" from the fcode.
I didn't take this optimization to the extreme like javac will do - for example "a&&b||c&&d" will still generate a lot of useless load true/false code. But for now I'm not going to complicate the assembler to optimize these more advanced cases.
Another thing I really wanted to do was to create special opcodes to coalesce comparisons and branches so that the Java/IL emit code could skip loading a Bool onto the stack, then having to perform the Bool.val field access. But I already handle this in the Java emit code by peeking if the next opcode is a JumpTrue or JumpFalse. Looks like you copied this code for .NET too Andy. The peek is pretty efficient - just a bit complicated. So effectively we already have implemented this optimization it's just at emit time versus assembly time - so I'm going to just leave it the way it is.