VM artefacts
Locked
 
|
Hi! Just to get myself up to date on the latest. Is it still true, that we got three independent VMs?It might not come as a surprise, but I haven'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'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's
running on and the image that should be loaded and decide on that what
object engine to load/use? The obvious benefit for the enduser I see is: *There is only one VM !* 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. This might be a "well yes, but too much work" thing, but nevertheless it's something I would like to share. (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't need to worry about this. And
I guess there is a similar mechanism for windows and mac) Alex |
|
|
On 4 February 2013 21:08, Alexander Lazarević <[hidden email]> wrote:
> Hi! > > Just to get myself up to date on the latest. Is it still true, that we got > three independent VMs? > > 1. Interpreter VM > 2. Stack VM > 3. Cog > > 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? If you have a 64 bit machine and no way to install 32 bit libraries (Heroku, say), then Interpreter VM is your only choice. (Or, 32 bit libs are a requirement for Cog.) > It might not come as a surprise, but I haven'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'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's running on and the image that should be > loaded and decide on that what object engine to load/use? I'll leave it to others to answer definitively but I suspect the answer is that while you can share the codebase to a large extent, you can't have a cross-platform binary. Squeak does run on at least OS X, Linux, FreeBSD, Windows, RISC OS. frank > The obvious benefit for the enduser I see is: *There is only one VM !* > > 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. > > This might be a "well yes, but too much work" thing, but nevertheless it's > something I would like to share. > > (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't need to worry about this. And I guess > there is a similar mechanism for windows and mac) > > Alex > > > |
|
|
Thanks, Frank. Maybe I wasn't that clear. I wanted to know if it would be possible to have one vm for linux, Windows, Mac, ..., that could use an interpreter object engine, stack object engine or a cog object engine. 2013/2/4 Frank Shearar <[hidden email]>
|
|
|
Hi Alex
On Mon, Feb 4, 2013 at 1:52 PM, Alexander Lazarević <[hidden email]> wrote:
I'm still not sure I understand the question. Yes, you can run "one" VM on the three platforms, in fact any one. Cog runs on all three. The Interpreter runs on all three. The StackVM runs on all three. No, you can't have _just one_ VM because each VM executable is specific to a given OS/processor combination.
So what are you really asking? Do you want the "all-in-one" which has three VMs hidden inside it? Do you want a universal binary? Or what?
best, Eliot
|
|
|
On 04-02-2013, at 2:05 PM, Eliot Miranda <[hidden email]> wrote: > I'm still not sure I understand the question. Yes, you can run "one" VM on the three platforms, in fact any one. Cog runs on all three. The Interpreter runs on all three. The StackVM runs on all three. No, you can't have _just one_ VM because each VM executable is specific to a given OS/processor combination. > > So what are you really asking? Do you want the "all-in-one" which has three VMs hidden inside it? Do you want a universal binary? Or what? I suspect the thought is that having a 'single' VM that can choose an appropriate core at runtime is desirable. I'm not sure what benefits he is after here; after all if the cog vm can run on your machine, why use either of the others? On the other hand, I've been trying to interest people in a modular pluggable vm core since I talk to Schiffman about it in '88. It's not a slam-dunk that it is actually worth it these days, since the idea was to allow loading up a simple, slow but fast to start vm and allow cleverer modules to take over if a policy decided that it was worth swapping to a translator (ie this isn't a three seconds and quit script) or a different GC (ie this is a long running job and the machine has oodles of memory or this one has relatively little memory with no virtual mem but it is very fast access). I think it was a more interesting idea in the days when the CPU space wasn't so small. tim -- tim Rowledge; [hidden email]; http://www.rowledge.org/tim Strange OpCodes: RJT: Read and Jam Tape |
|
|
In reply to this post by Alexander Lazarević
On Mon, Feb 04, 2013 at 10:08:35PM +0100, Alexander Lazarevi?? wrote:
> Hi! > > Just to get myself up to date on the latest. Is it still true, that we got > three independent VMs? > > 1. Interpreter VM > 2. Stack VM > 3. Cog That's more or less right for any given operating system. > > So as I recall the Stack VM was planned to replace the Interpreter VM > entirely. Currently the Stack VM (and Cog) is developed in a separate branch of both the Smalltalk (VMMaker) and the platform support code. Much of the Smalltalk code for StackInterpreter and related classes has been merged into the "trunk" VMMaker, but this is not complete and at the present time a Stack VM cannot be generated from that code base. The platform support code remains in separate branches at this time. > 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? You would use a standard interpreter VM (not stack) if you want to be able to run an older image format (Squeak 3.6 or 3.8), if you want a VM compiled in 64 bit mode, if you want to run the experimental 64-bit object image, or if you need a VM for an architecture not yet supported by Cog. You would use Cog for any Intel-like platform, especially if you care about performance. > > > It might not come as a surprise, but I haven'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'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's running on and the image that should be > loaded and decide on that what object engine to load/use? I'm not sure that I understand the question, but one of the things that Eliot introduced in Cog is a better separation of the interpreter from the object memory in VMMaker. If you now look at the "trunk" VMMaker (for in interpreter VM), you will find that this organization has been adopted there as well. In principle (if not in practice) different kinds of object memories might be paired with different kinds of interpreters. The VM plugins are Ian Piumarta's mechanism for loading VM subsystems in the Unix VM (which would include both Cog and the interpreter VM). Presumably it would be possible to use this mechanism to load different variations of object memory or interpreter, although I would not expect any of this to be a trivial amount of work. > > The obvious benefit for the enduser I see is: *There is only one VM !* For unix VMs (and possibly others), by far the simplest way to achive this for the end user is by means of a shell script that selects an appropriate VM based on the image format. If you look at Ian's most recent start script (usually installed as /usr/local/bin/squeak if you have installed the interpreter VM) you will find that much of this is already in place, including hooks for Cog. > > 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. > > This might be a "well yes, but too much work" thing, but nevertheless it's > something I would like to share. > > (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't need to worry about this. And I > guess there is a similar mechanism for windows and mac) > > Alex > |
|
|
Hi! I was under the impression, that new folks, who would be interested in Squeak, could be driven away by a challenge to find the right Squeak VM. To make their life's easier I thought "that having a 'single' VM that can choose an appropriate core at runtime" would be a good thing (especially "if [they] want to be able to run an older image format").Thanks for the clarification and the detailed replies. Alex
2013/2/5 David T. Lewis <[hidden email]>
|
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |