Skip to main content.

Tuesday, July 12, 2011

Ammitedly the model is complex, but not convoluted.

The compiler generates FalconClass instances out of the language "class" keyword. A user, from C++ code, might synthesize a FalconClass as well, but that's usually not what you'll want to do.

If one of the base classes declared in the inheritance at language level (or added in the inheritance list if synthesized from C++) is not a FalconClass instance, then a HyperClass holding the master FalconClass and its dependencies is created. Instance of the two things are different both at creation and at runtime, but they are seen by the engine as the same thing (actually, any user class is seen exactly the same by the engine).

It was a damn lot of work; just this two class implementation required about 2000 code lines, and this excluding the code in the compiler to parse the source structures. And we're still a bit incomplete (especially the HyperClass needs testing and finetuning).

And about 20 work hours. Not cheap meat.

BUT OTOH, I have learned to use the best of the new VM in the process, and fixed some conceptual problems in the definition of foreign entities (i.e. entities imported from remote modules). Last but not least, I have improved the performance of the VM raw loop by removing a pair of useless operations at each PCode execution (PCode = precompiled PStep); as PCodes are used by all the statements (including the basic AutoExpression), even when a single expression has to be executed, this means an interesting performance increase. Which I still did not care to measure; we're anyhow faster than the fisrt tests that gave the VM raw loop 5% faster than in the old engine.

But the most interesting thing is how I discovered that inefficiency. To keep compatibility with the extension functions of the old engine, we kept the A register in the VM context (which is used as generic return value in the old engine). The new engine uses the top of the data stack to pass data around.

I didn't remember that, to equalize function return values and expressions, I extracted the topmost item from the stack and set it as A at each PCode completion. That was because, in the first version of the new VM, functions always returned values in the A register (even the new functions), and some expressions might have been composed of just functions...

I have then solved that problem by working on the return frame and having the A register pushed in the stack after function returns. In the next days I want to address the issue completely and remove the usage of the A register except for the old extension functions.

However, I was already convinced of the fact that PCode would have gently pushed all the results of the expressions it accepted during the pre-compilation step in the stack, and so I used the PCode construct to generate the parameters for the initialization call (Init statement). But, actually, PCode was sucking out the topmost expression before getting back to the init call.... causing weird results in the property initialization...

The moral is that this heavy work I am performing in this days is not just limited at the problem at hand (completion of the new class model), but is also going in the direction of creating a better set of tools in the new VM, and in general in the new engine; a set of tools that is able to exploit the power of the three-stack-VM concepts with minimal development efforts.

And it's coming out pretty well :-)

Comments

No comments yet

Add Comment

This item is closed, it's not possible to add new comments to it or to vote on it