Initial changes
20 views
Skip to first unread message
Giancarlo Niccolai
Dec 24, 2017, 8:16:27 AM12/24/17
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 !
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 !
Giancarlo Niccolai
Dec 24, 2017, 9:43:48 AM12/24/17
to FalconPL
Clarification on point 1, as it looks like it’s now.
1) Notice the prospicient absence of an item type. The item shall be solely defined by its class pointer.
2) the fact that the class will handle not just the data pointer, but the whole item, means it can now access the flags, the function pointer and eventually the lock in case of need.
3) point 1 and 2 together mean that the class must handle the item as a raw item or as a method itself. In other words, the class must be able to handle also its methods.
4) this means we will not have anymore a methodification process rolled in when a method is extracted, and rolled back when the method is actually invoked through the evaluation of a method class instance. The evaluation of the item itself will have the class do something with the invoked item if there is no function attached (the default being doing nothing as now), or invoke the function with a “self” enabled context; similarly, printing “method xyz on abc” instead of just “abc” will be responsibility of the class (can easily be handled int the base Class).
5) a method class will be still there, and used when we are doing something interesting on the method itself, (I.e. invoking a method of the method class), if necessary. However, none of its features will be vital to any part of the language or virtual machine as they are now.
1) Notice the prospicient absence of an item type. The item shall be solely defined by its class pointer.
2) the fact that the class will handle not just the data pointer, but the whole item, means it can now access the flags, the function pointer and eventually the lock in case of need.
3) point 1 and 2 together mean that the class must handle the item as a raw item or as a method itself. In other words, the class must be able to handle also its methods.
4) this means we will not have anymore a methodification process rolled in when a method is extracted, and rolled back when the method is actually invoked through the evaluation of a method class instance. The evaluation of the item itself will have the class do something with the invoked item if there is no function attached (the default being doing nothing as now), or invoke the function with a “self” enabled context; similarly, printing “method xyz on abc” instead of just “abc” will be responsibility of the class (can easily be handled int the base Class).
5) a method class will be still there, and used when we are doing something interesting on the method itself, (I.e. invoking a method of the method class), if necessary. However, none of its features will be vital to any part of the language or virtual machine as they are now.
Reply all
Reply to author
Forward
0 new messages