Giancarlo Niccolai
unread,Dec 24, 2017, 8:16:27 AM12/24/17Sign in to reply to author
Sign in to forward
You do not have permission to delete messages in this group
Either email addresses are anonymous for this group or you need the view member email addresses permission to view the original message
to FalconPL
I have been thinking at the changes that are most needed in the engine to start building around it, or in other words, the first piec s of code we shall work on.
I am posting it here for comment and suggestions.
1) the ITEM class should have the following elements:
Atomic lock (4 bytes)
Flags (4 bytes)
Class/handler (pointer)
Data/pointer (64 bits)
Function (pointer)
It’s 32 bytes on a modern machine, and it comfortably fills an aligned cache line.
2) I am still in love with the term Class for the item handlers, and instead of disposing of it, it’s better to bring all the concepts previously reserved for the FalconClass and maybe hyper class as well, down to the base. Initially, I wanted to provide module writers and embedded with a very lightweight structure that they could use to exchange data between Falcon and external programs, it it tu ns out that the preferred usage pattern wa that of providing a set of dynamic prope try and methods, a feature that I delegated to a structure halfway between Class and FalconClass. This made reflection of classes a bit clumsy, and delegation simply impossible for anything not below FalconClass.
In short, I think we should give Class all the powers of... a class, and rather than driving from it, we should have instances of it all around the engine. Even the MetaClass should be nothing but a Class instance, with its callbacks and methods properly configured.
2.1) this would also provide the occasion for full optimization of the class callbacks: instead of having the base as fast as possible (as fast as it can be with virtual calls all around) and introducing incremental slowdowns for classes that can be overloaded, delegated, dynamically given new properties etc, we can have a solid model that can work for everything and even be very efficient at that (eg LUA table of callback function pointers).
3) for the same purpose as the above mentioned “coding for 3d party” all class methods received a void* as the object they needed to work on. This caused the problem of handling differently flat items— which was ok as long as base expressions were handled directly in the engine, but caused problems with derivation from base classes (I.e. class MyNum from Integer), with hybrid-flat items as strings and mostly with flat and hybrid-flat items introduced by third parties.
I am now convinced all the data to and from the engine must be passes through items.
4) Pstep callbacks received an extra parameter with the pointe to their code stack. I think it’s superfluous.
5) the code stack items had place for an integer that the pstep could use to record a status and act differently at different iteration. I think now that all the state change in the pstep behaviour should be handled by different pstep callbacks.
6) this requires changing the Pstep concept so that it encompasses:
6.1) The information about the source line where it was generated (if any)
6.2) The grammar construct it represents
6.3) the callbacks (1 or more) it must push on the vm context to operate.
Of course, writing psteps and pstep callbacks must be an easy matter, possibly simple than what is now.
7) this requires changing the code stack item to a pair of pstep and callback.
8) we must do a little bit better for symbol resolution, but I still didn’t have the time to think about that.
How do this changes feel?
P.s. merry Xmas to everyone !