Hi.
I'm working with a prolog-vm atm that I plan to hook inito guile. The idea is to have one extra vm operation in guile-2.0 that simply hooks in custom vm's. The compilation of prolog code is to a specific vm targetted for prolog and logic programs. The need stems from very slow compilation currently and also a need to speed up the prolog code together with some experementation. Now the idea to enable a close interoperation between prolog and guile is to branch out all function calls, both tail and normal to guile. The amount to only one extra vm operation and therefore it is manageble to maintain a simple diff between guile and modded guile. I expect that it would be possible to have other VM's than just prolog to use this trampoline and therefore it could be of value to lift the suggestion to the mailing list. In the end we would like to have all this need solved by just using scheme. But currently I wan't all the powers that I can get from a C interface. One very interesting thing with my approach is that all my vm c code in scheme using c-lambda. It really feel schemish and I have benefitted quite alot from all the meta facilities that scheme as a c-macro processor get you, like everything returns a value, scheme list and match facilities simplified symbols and strings done effectively. clambda is under documented (no documentation) but there are some examples and you can also look at the vm.scm code in logic/guile-log/guile-prolog directory. For clambda see
https://gitlab.com/groups/clambda.
Currently I have only set upped logic around a scheme closure wrapper. The wrapper maintain specific state in the free variables. The idea is to maintain the actual custom
vm in free variable 0. The allocation of stack space in free variable 1 and the rest is custom
variables. The idea is that you call the custom vm with sp,fp,the free variables and an integer that in case it is true it will collect information about the jump table and in case it is false or 0 it will try to execute the new vm.
My own free variables objects are
1. Constant Array
2. Variable Array
3. Instruction Array
4. Extra stored stack state that is pushed to the stack at startup used extreemly seldom
5. Instruction index where the first execting instruction shall be
I could have constants inside the instruction stream, but I expect the constants to be reused heavilly between prolog functions and maintain one constant vector per module.
So then when we reach a predicate call in prolog we create a failure thunk which is typically
an execution unit like the above and a continuation execution unit add those to the arguments
of the call together with variables state information exactly how kanren is working, Then the
function arguments, adjust the sp to the end of the function argument list and return the sp. Now
the guile extra vm can adjust the stack space and issue a tail call. To really get a useful system
one need to be able to call scheme functions and interoperate the scheme stack - not sure to do that atm. This thing is in early state and I expect the interface to change.
Regards
Stefan