2010/1/19 Miguel Enrique Cobá Martinez <[email protected]> > Parrot has just been released: > http://www.parrot.org/news/2010/Parrot-2.0.0 > > I would like to know, from the VM experts from the community, if this VM > can be used to run Smalltalk. > The site says that > > "Parrot is a virtual machine aimed at running all dynamic languages.". > > but I don't know anything about VM so this sounds to me a bit like black > magic. > > Is there something in the squeak vm that is specific to the way > smalltalk works or a generic virtual machine (maybe with a upper layer > understanding Smalltalk specifics) can be used. >
The four things that most distinguish Smalltalk VMs from most others are the bytecode and primitives set, contexts, immediate objects and the class hierarchy with each class having a method dictionary. The method lookup mechanism that searches the class hierarchy has traditionally been part of the VM but in a well-modularised VM one could imagine adding it on as an extra (*1). Immediate objects are of course SmallInteger (a.k.a. fixnums) and in some implementations Character and SmallDouble. They're the implementation encoding value objects within a pointer so that these values can be synthesized without object allocation. To be a Smalltalk these must be objects to whose classes you can add methods, and pragmatically they need to be space and time efficient. You can implement them as boxed objects but performance will be poor. You can't implement them as e.g. Java integers without a lot of difficulty; they need to be objects. A well-factored VM may well allow one to implement some immediate types; I would be surprised if Parrot didn't have support for fixnums. Contexts are the most distinctive features of Smalltalk implementations. Few languages have a reification of method/function activation. I doubt very much that Parrot supports anything like contexts. One can attempt to do without them, but then lots of the exception system is in the VM and there are major restrictions (Seaside's continuations must be implemented differently, the debugger needs to be reimplemented, persisting processes is difficult, etc, etc). All this is possible (VisualAge doesn't have contexts) but for Squeak and VisualWorks eliminating contexts is a lot of work. Finally the bytecode and primitive set, encapsulated in methods, are pretty distinctive. These are the target of the compiler and known to the image indirectly by the debugger, by the browsing functions (senders scans methods bytecode, inst var refs scans bytecode, etc), and so on. So if a VM specifies the bytecode set, rather than allows one to specify one's own there is a lot of work involved in targeting that VM. In practice none of these four features is fixed. One wants to be able to evolve the implementation. My closures implementation adds a few bytecodes, a few primitives and changes how MethodContext works (to support block activations; BlockContext is history). But these are small changes from Squeak and, clearly, support existing Squeak semantics with relatively little work. Targetting Parrot is likely to require much more effort. primitives are a can of worms. For example, does the VM allow one to enumerate all instances of a class? This is great for doing instance mutation when a class definition changes, but many VMs will disallow this kind of thing on security grounds. You can always try and do without but at what stage does it no longer remain Smalltalk? Smalltalk is more than syntax. And of course a different VM may be perfectly acceptable for certain kinds of deployed applications. One may live with the restrictions involved in compiling Smalltalk to JavaScript in return for browser ubiquity. So you've asked an interesting question that overs a large space of implementation approaches and levels of effort. In my experience you never know how hard or easy something really is until you try doing it. *1 and some VMs such as the Mushroom Smalltalk VM and Ian's Cola have virtualized method lookup, so it doesn't have to be part of the core and so is the least distinctive of the three features. > Thanks for the answers > > -- > Miguel Cobá > http://miguel.leugim.com.mx > > > _______________________________________________ > Pharo-project mailing list > [email protected] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list [email protected] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
