Skip to main content.

Tuesday, July 12, 2011

A funny thing about the orgainc VM is that it has several way to do things:
* You can push a PStep to the code stack. -- that's the most direct way.
* You can push a PCode, which is a list (in reverse order) of PSteps to be evaluated by the VM in "one step".
* You can push a Statement, which is a special PStep (with a little of self-awareness).
* You can push a SynTree, or a derived class, which is a list of statements to be executed in the given order.
* Finally, you can "call a function", which is generally performed in a single step. If the function is a Falcon source function, then the VM pushes a new call frame in the call stack, adds the syntree which embodies the function code to the code stack and starts executing that.
* Or, if you really want to go fancy, you can add your own call stack frame and push psteps, pcodes, statements or syntrees that will be interpreded as executed in a new function.

Despite the fact that I have been bitten back today by this variety, I still like it. I have been bitten back while working at the generation of automatic code for initialization. I went through several tries, including that of creating psteps, syntrees, functions, pcodes... more or less I have tried all the possible combinations of code to generate the wished result:
* For Falcon classes, invoke the base class constructor (tree-wise) without creating a new object;
* For hyperclasses or prototypes, invoke the base class op_create which creates an instance (and constructs it), as the hyperclass instance holds pointers to all the instances of subclasses.

At the end, I came out creating an ad-hoc statement to initialize the subclasses in a FalconClass, and resolved to use a PCode for hyperclasses. In the latter case, each PStep in the PCode will invoke the op_create of its own mother class, and when all the instances are created they will be copied in the HyperClass instance vector. Prototypes will work the same way.

Although this seems like a code duplication, it is actually needed to exploit the different structures, purposes and performance balances between HyperClass/Prototypes on one side and FalconClasses on the other. We MIGHT have just one class type, and handle everything with that, but this would be a sub-optimal solution in many cases. Since most of the language classes will be pure FalconClass, that can be handled very easily by the VM and require minimal bookkeeping, it is important to give them proper attention in the code that serves them. OTOH, having to integrate seamlessly foreign code, we need more flexible structures so that, even if that requires a bit more bookkeeping at engine side, the integration effort at user side is minimal.

And, minimal integration effort means maximum performance in the transit between the engine and the userland 3d party software; which has always been the aim of this project.

In short; no, it's not duplicated code. It's just better suited code. The point is just that I myself must learn to use it properly and understand the various implications, so that I can communicate them on the outside.


No comments yet

Add Comment

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