Modular VM (outdated)
Last updated at 9:05 pm UTC on 22 June 2003
Outdated project information; see Squeak VM Plugins and VMMaker now.
Important: See Squeak VM Plugins for information on how some implementation details of this project is handled.
Since the system can now call code held in various OS forms of shared libraries, it is time to move all the 'unneccesary
' primitives out of the VM core and into plugins.This will:
- reduce the size of the vm executable
- allow fixing of bugs in plugins without changing the vm
- encourage more modular thinking by primitive implementors
- encourage modular image code to use those plugins
As a nice side effect it will also reduce the basic porting effort, since there will be a clear line demarcing what has to be done to get a port up and running as opposed to getting a complete release built.
How to do it
Move all the subsystems that are not essential to a basic vm into TestInterpreterPlugin subclasses, change the core vm to drop those subsystems and make sure to test thoroughly! I have made working 2.8a systems for my Acorn, for Mac PPC and Linux-686 (all the machine types I happen to have lying around) that work well enough to use Scamper, download midi files and play them, send mail etc. Andreas has made Windows sytems. The main changes were released as change updates 2146-2152 and some touchups are needed for module version information retrieval.
The only plugins that presented any particular problems were the sockets/resolver one and the sound player, since the Unix and Acorn machines need a hook from the event handling function in the vm to poll the socket state and Linux needs a similar construct for the sound player. If you go to Squeak VM Plugins you will see how that problem is handled - and the same technique can help with many other platform odities.
The basic release encompassed plugins for:-
- Joystick and Tablet interface
- Socket and Resolver
- Sound mixing prims (FMSound>mixSample.... etc)
- Asynchronous Files
Eventually it should be practical to have the execution machinery and memory manager as plugins so that different capabilities can be provided as suited to the need at hand. For example, Ian has made the jitter (J3) stuff as a plugin, so the bytecode interpreter could also be moved out and only used for platforms where the jitter is not ready. A trivial memory manager that does no garbage collection might be adequate for a situation where short scripts are being run and the only garbage collection required is returing the program's memory when it exits. You get the picture.