Alternative VM implementation based on C++, LuaJIT and Qt?

[rochus-keller]

Is your feature request related to a problem? Please describe.
Maiko apparently works, but the code shows its age and the diversity of authors and the technologies introduced over the years. And there has been a lot of progress in different areas since the code was written. There may come a time (or maybe it's already here) when training new people for work on Maiko, maintaining the code or migrating it to new systems could become more expensive than building a new VM.

Describe the solution you'd like
In recent years, I have had good experiences with reusing LuaJIT and Qt as a platform-independent, reasonably fast backend for programming languages, and was able to use it to renovate several old systems and migrate them to current platforms.

I wonder if combining these technologies would not also be a good alternative solution for an Interlisp VM. The build and dependencies could be significantly simplified, and as a side effect, higher performance could be expected.

At the moment, I can't yet assess the feasibility and the effort for this very well, nor can I say how great the demand for such a solution is. But I think it would be an interesting project and I would be happy to invest some time in it.
The question is whether there is a specification for the bytecode and the other functions expected by the VM clients (i.e. Interlisp code), or whether one has to find out everything oneself through reverse engineering.

Describe alternatives you've considered
Maintaining the original VM would not be affected. Ideally, one could simply replace the executables.
Graal/Truffle would certainly be an interesting alternative technology, but it's not my area.

Additional context
Some of my projects where such a solution was applied: https://github.com/rochus-keller/Smalltalk, https://github.com/rochus-keller/SOM, https://github.com/rochus-keller/Oberon.

[masinter]

My temptation is to move this to a "discusssion" as a knd of research project that isn't immediately "actionable".
THere are some interesting ideas here but not really an actionable plan. And someone would have to take this up as a research project.

[rochus-keller]

"Discussion" is ok for me.

It is "actionable" in the sense that I have already started to do research. I already found out that all tgz files from the "Local Installations (for any Linux distro)" are identical up to the linux.aarch64, linux.x86_64 and linux.armv7l directories, which confirms my assumption that the challenge can be limited to the Maiko executable. Currently I analyze all file formats of the 6'252 files included in the tgz.

Are there specifications of the used file formats, e.g. DFASL, TEDIT, LCOM or SYSOUT?

[rochus-keller]

Today I started an experimental fork of Maiko (see https://github.com/rochus-keller/Gingko). I will use it to make the proposed experiments. Will keep this discussion updated when there are results. I'm already able to build a minimal working Maiko using qmake.