Skip to main content.

Archives

This is the archive for July 2011

Saturday, July 30, 2011

I have been enlightened by a Great Truth(TM) today. Programming (without adjectives) may be something else, but Good Programming (TM(tm)) is all about giving names to things, or, I may say, "dubbing".

I've been struggling to reintroduce auto-operators (+=, ++, postfix ++ & family) in the Organic Virtual Machine for a couple of days; and a couple of "my" days, so, something 16 work hours per day.

Thursday, July 28, 2011

After a couple of days of work, I have found that the only sensible way to allow dynamic loading of modules is that to create references for static data and let those to be separately managed by the garbage collector.

Consider strings, arrays of flat items or even user-defined classes that might go in the static data of a dynamically loaded module. If some item is take from by the user of the loaded module and sent around, it must stay alive as long as needed. If necessary, it must even keep alive the module that is hosting it, otherwise it should just stay around even after the module has died. I wouldn't love to keep a plugin around just because it has returned "OK" from inside a function it exposes, and that OK is kept somewhere for future records...

Adding the requirement that anything that goes or may ever go outside the dynamic module boundaries must reference the module back would be a nightmare. It may make sense for (some) classes and functions (and I think we can lower this requirement to the external/native code ones) but it's totally unreasonable for i.e. strings. Also the reverse requirement, that is, that a module must stays alive 'till all the data born from it are gone is pretty heavy.

So, the only sensible way to handle plugin-based dynamic (dischargeable) modules is that of making their static data references as soon as the module is linked dynamically in a virtual machine. When the module is gone, the reference items might still be around and keeping alive the related data.

For this reason, re-introducing the references was in order before completing the module loading system.

In the process, I also improved the usability of references that was somewhat limited in the old engine. Here follows a talk about it in our #falcon chan at irc.freenode.net:

Thursday, July 21, 2011

One of the main reasons to rewrite the Falcon engine was to fully support Functional programming at parser level.

There are some extensions, or we may call them "dialect", that greatly rely on functional programming, up to the level of writing entire modules of several hundred lines in functional sequences. Of course, it is necessary to have full compiler support into those long sequences, so that an error in the sequence body gets pinpointed and the compilation can proceed in search for further errors.

Wednesday, July 20, 2011

Well, the A register still exists; but now it's completely ruled out from the inner (new) function management, and it doesn't play any role in the call frame.

I took the occasion to get rid of other minor details in the generation of the call frame and in return routine.

As a result, I achieved another 5-10% performance increase in the non-optimized recursive fib test with respect to the old engine. Now it's consistently 20%-33% faster than ever before. And the VM model is now even simpler and more linear.

Tuesday, July 19, 2011

Today, I have completed the OOP model constructs in the Falcon new engine. Some details (for instance, Class states, or a direct way to generate a sub-classed prototype via a single call) remain yet to be dealt with, but they are largely things that I can complete later or that I can leave to be completed by the other developers in the project.

What I want to talk about in this entry is 1) the findings about the engine that I have discovered, and 2) the short term plan.