The compiler is currently at a stage where syntax of program basic structures need to be validated. This pass involves parsing and data gathering, from which the first refers to syntax cheking of classes/functions/constants etc, and the latter is basically forming the Token Table for the program. There are 9 data structures to do: constants, enumerations, program flow, jumps, structures, variable definition, functions, operators and classes.

There is no “properties” in this list. While this is something that would be exciting to implement, I’ve decided not to – just yet. Properties are part of classes that involve usually two functions: getters and setters for certain attributes. Traditionally programmers used to have these two separate functions, but it’s more elegant to have normal assignments and values in spite of they actually perform more code under the hood. You could use something like this:

myClassVariable.SetMyPropertyValue(myValue)
variable = myClassVariable.GetMyPropertyValue()

However, the following way is cleaner:

myClassVariable.myProperty = value
variable = myClassVariable.myProperty

Both of these would still perform a function within the class. I’ll keep this item on my TODO-list, but let’s try to establish the core first 🙂

Back to the analysing process. So those 9 keyword statements need to be parsed in order for CoolBasic to be able to compile a list of all token names. Naturally, each token must have additional data assigned to them such as access modifiers, inheritance modifiers, overriding modifiers and certain flag values. I don’t want to attach all these fields to every token data because not all of them is never needed at the same time and this would only munch unneeded memory for large programs. So it’s quite challenging task to create any “optimal” way to store this kind of data that could bend to all needs at once.

The programming tool I’m using to create CoolBasic V3 compiler doesn’t really support classes and inheritance properly (woot! why can’t you just use Visual Studio?! – It’s not fast enough ^^). I’m using allocated memory blocks to store only the most relevant data. This will make my code somewhat uglier than I had hoped, but at least it’s memory efficient. Note to self: Just remember to maintain the clean-up functions accordingly, mmkay…

And finally, some good news. The consants are already done 🙂

Many present compilers try to simplify mathematical expressions during compile time in order to ease the burden of the final executable. Naturally this results in faster runtime code execution in some cases and even the size of the executable may shrink a bit. I’ve been working on some similar mechanics for CoolBasic V3 compiler, and at this point in time I’ve grown pretty satisfied with it. Most constant expressions will now be pre-calculated, meaning that statements get shorter before the actual syntax checks begin. All of this will help me to establish as bug-free development as possible. Compilation based on very very strict rules, in the end, tends to prevent exceptions in the algorithms. Simplicity is beautiful.

This kind of optimization is, however, very hard to carry out perfectly. An an example of this matter would be the following expression to optimize well:

1 + 2 + a [into] 3 + a

But grouping is a bit trickier:

1 + a + 2 [into] 3 + a

For now, I decided to leave as it is i.e. only the first example remains in effect.

Another funny part of this implementation of pre-evaluation is that the compiler’s source code almost doubled just by adding this feature. You can’t really say it wasn’t worth it, though. As a result, you gain:

• Faster runtime execution
• Faster compilation
• Smaller executable
• False conditions (like If/Until/While 0) can be stripped from the final executable