<div dir="ltr"><div><div><div><div><div><div>Hi!<br><br></div>Just to get myself up to date on the latest. Is it still true, that we got three independent VMs?<br><br></div>1. Interpreter VM<br></div>2. Stack VM<br></div>3. Cog<br>


<br></div>So as I recall the Stack VM was planned to replace the 
Interpreter VM entirely. Or are there any cases were one only could use 
an Interpreter VM (or cog)? Or is the Stack VM the all versatile VM by 
now? What are the requirements for cog to run?<br>
<br><br></div><div>It might not come as a surprise, but I haven&#39;t looked
 into the VM code lately. But I recall that the linux VM at least uses 
the modules framework to have different display, sound, etc. plugins for
 the VM. I don&#39;t know how interleaved the VMs from above are, but would 
it be out of scope to have _one_ VM that could have different object 
engines as VM plugins? So the VM could check the architecture it&#39;s 
running on and the image that should be loaded and decide on that what 
object engine to load/use?<br>
<br></div><div>The obvious benefit for the enduser I see is: *There is only one VM !*<br><br></div><div>The
 benefit for VM developers might be that they only need to focus on the 
object engines and they would share a common VM frame.<br>
<br></div><div>This might be a &quot;well yes, but too much work&quot; thing, but nevertheless it&#39;s something I would like to share.<br><br></div><div>(If
 turns out that the energy would better invested into something 
different, there is also the possibility to use the package system on 
debian derived systems, that would take care to install the right VMs on
 such system, so that the enduser wouldn&#39;t need to worry about this. And
 I guess there is a similar mechanism for windows and mac)<br>
<br></div>Alex </div>