Is Powerlang-like ability to run different Kernels still a goal?

[shingarov]

:: Reading PR128 ::

My question is based on superficial reading of the diff, but given how people on the cuis list are right now excited about "let's document things better", I thought we might do as well — and in my experience, the far far best way is one-line-every-day.

So here is the actual question:

Back before Covid, we had the Kernel in https://github.com/powerlang/bee-dmr and we had Powerlang in https://github.com/powerlang/powerlang. To me this idea resonates with the ENVY/Image project we had at OTI near the turn of the millenium, to git rid of the implicit assumptions the image has about the internals of the VM, and those the VM has about the image; so a "universal VM" can run different Smalltalk systems. Now, in a DMR/LMR we of course don't have a VM, but still you could feed Powerlang whatever Kernel you had. Is this design goal removed from the list of design goals of Egg? And it's not really about the Kernel and Powerlang living in the same repo: this has been going on for a while, and I thought this was simply a version-control-related decision, something similar to how Chromium is one huge codebase in one repo. But this morning I am looking at one single PR, supposedly addressing one single aspect, and it cuts across the Kernel and the Powerlang. The memory of the old pain: any change, I have to do synchronously in the VM and in the image. Some places are obvious, such as CompiledMethod, or MethodDictionaryArray. Some are really annoying, e.g. any change in the GC potentially breaks the image-level implementation of #become:. Some make UVM/Language separation impossible, e.g. OMR GC makes assumptions which are simply false in Bee. And then some torpedo you from behind, e.g. you wouldn't expect the image to know details of how stack frames are laid out in memory.

Now: I thought this was a design goal in Powerlang to isolate all these mutual VM/image assumptions, make them explicit and express them in a machine representation, and place that representation in the definition of the Kernel. I am not that naïve to think we ever achieved it; but it's still a principal design goal in UMR.

Now the actual actual question: is this still a design goal in Egg? Fundamentally, can Egg run different Kernels, at least in principle?

[melkyades]

Hi Boris,

Short answer is no, it is not a goal in Egg to allow running different kernels. It may work, but we are not actively supporting nor encouraging it.

The goal with Egg is to just evolve the traditional st80 with added modularity to be able to have small systems for practical use, what we have called st2000 in the past. This is the reason why we have different VMs, to address different needs of different use cases in real-world scenarios.

Egg kernel tries to have not many ties with VMs because different platforms provide different features and limitations. While we are not against you trying, unlike at powerlang time, in egg is not a goal to allow different kernels. Our goal is to have a fully working modular st asap. The VMs just provide processing power, with no UI, events or anything. In that sense they are small, maybe not minimal. There are many different VMs (pharo, c++, js, LMR) and they all asume some stuff about the image (i.e. compiled method format, some structure of the meta layer, etc).

Would there be less assumptions if there was only an LMR runtime? maybe, but there are some things that come to my mind which take more work than desirable in that scenario:

• Our current LMR design is jit-only. We need an interpreter mode for small systems such as MCUs. JIT-only LMR consumes more memory than interpreter mode, but to have an interpreted LMR we would need to implement a pre-nativized interpreter.
• The idea behind the C++ VM is to support different archs with just changing a flag. This just works in C++ (modulo bullshit) while in the LMR jit, there's quite some more work to do before that starts looking possible, and we want to have Egg working asap.

Egg support for an LMR-based runtime is w.i.p. (see dir modules/LMR), it just requires more work, and right now I'm quite busy trying to make the team be able to launch an instance which loads a module for development, with a webside backend behind to be able to browse and change the code.