Skip to main content.

Archives

This is the archive for December 2007

Tuesday, December 11, 2007

I am beginning to feel very satisfied with the VM model as it is now. The only thing that IMHO needs a small refine is the concept of "sequence" and the iterator interfaces; in this way, List class instances could be directly provided as sequences under every condition (i.e. they may be used in functional evaluations), and there would be space for different kind of sequences as i.e. fixed size tuples.

What that doesn't satisfy me is API structure; the module loader, the streams, the error handlers and the runtime must be a bit finetuned to work be a little more smart in cooperating with the VM.

Since I am there, note to me: provide defaults for virtual base class "Stream" (stubs setting the "unsupported" error in the stream).

Other than that, I want to redesign and some of the function prototypes, namely pointers vs. reference parameters. The following convention must be used:

1) when passing or returning an instance always use by-reference, unless...
2) the called (or calling) function is directly interested in the memory area where the instance resides. In example, GC, memory management, table indexing and so on.

Other than that, a full review of naming convention is now in order. There's too much confusion between length and size, and there are too many places where a getXXXX() accessor should be simply XXXX().

One last step before blessing the engine and passing to the 0.9 stage (that is, pure optimization and code cleaning) may be the removal of RTL as a separate module and its integration in the ENGINE; I would still have it as a separate module object for better inspection/mangling, but having it in the engine DLL/SO would prevent the need for a FlcLoader? in pure embedded applications. It's size has become so small with respect to the engine that it is not anymore that important to have it in another file, and I plan to make it still smaller. OTOH, the assembler should now be removed from the engine, and turned into i.e. a static library just for usage in command line tools or in very specific applications willing to disassemble and reassemble some Falcon module.

The size of the assembler should be 1/3 to 1/2 of the RTL.

In the optimization step it is important to review the VM stack. The final stack should be multiframed (one small stack per frame level) rather than monolothic and undifferentiated as it is now. The time needed to copy a small portion of parameters during function calls should be more than balanced by easier access to local variables and parameters and less big-stack copies while growing-shrinking.