[Pharo-project] Parrot VM
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. Thanks for the answers -- Miguel Cobá http://miguel.leugim.com.mx
"Miguel" == Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> writes:
Miguel> "Parrot is a virtual machine aimed at running all dynamic languages.". Parrot's GC suffers from having many different kinds of mixed objects. http://wknight8111.blogspot.com/2010/01/boehm-in-parrot.html They apparently didn't learn from the mistake of ST80 having a mixed object for CompiledMethod. They made more of them. It's more likely that Perl6 can target Squeak's VM in the long run, except that Perl6 wants a VM with prototype inheritance, not class inheritance. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
"Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> Parrot's GC suffers from having many different kinds of mixed objects. Randal> http://wknight8111.blogspot.com/2010/01/boehm-in-parrot.html And worse, having untyped data blobs on a stack... that's probably the worst thing there. If you can't tell what live pointers you have for sure, you can't GC, and if you can't GC reliably, you lose. -- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
2010/1/20 Randal L. Schwartz <merlyn@stonehenge.com>:
"Randal" == Randal L Schwartz <merlyn@stonehenge.com> writes:
Randal> Parrot's GC suffers from having many different kinds of mixed objects.
Randal> http://wknight8111.blogspot.com/2010/01/boehm-in-parrot.html
And worse, having untyped data blobs on a stack... that's probably the worst thing there.
If you can't tell what live pointers you have for sure, you can't GC, and if you can't GC reliably, you lose.
Boehm GC is conservative one. Not a good way to achieve good performance. Mixing object pointers and non-object pointers on stack/object contents is different story. If you providing a good way to determine if given memory chunk cointains oops, or just raw bytes (like compiled method or bytearray etc), then this is not a problem, since you still can use precise GC.
-- Randal L. Schwartz - Stonehenge Consulting Services, Inc. - +1 503 777 0095 <merlyn@stonehenge.com> <URL:http://www.stonehenge.com/merlyn/> Smalltalk/Perl/Unix consulting, Technical writing, Comedy, etc. etc. See http://methodsandmessages.vox.com/ for Smalltalk and Seaside discussion
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Best regards, Igor Stasenko AKA sig.
2010/1/19 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com>
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 Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
In parrot site languages section there is "chitchat<https://trac.parrot.org/languages/browser/chitchat/trunk>â An implementation of Smalltalk" <http://en.wikipedia.org/wiki/Smalltalk> Anybody know what is it?
El mar, 19-01-2010 a las 22:02 -0800, Eliot Miranda escribió:
2010/1/19 Miguel Enrique Cobá Martinez <miguel.coba@gmail.com> 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.
Oh, in base of your explanation it is clear to me now that a generic VM for "every dynamic" language is it not something easy or possible to create. Thanks -- Miguel Cobá http://miguel.leugim.com.mx
On 20 Jan 2010, at 06:12, Miguel Enrique Cobá Martinez wrote:
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. Well, as someone mentioned, there seems to be Smalltalk implementation...
But, probably it is hard to get it fast. Parrot uses a very unique approach. Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. It will be interesting to see, how they can get their JIT fast with this strategy. Best Stefan
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.
Thanks for the answers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
stefan do you know how this is linked with pypy? Stef On Jan 20, 2010, at 8:50 AM, Stefan Marr wrote:
On 20 Jan 2010, at 06:12, Miguel Enrique Cobá Martinez wrote:
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. Well, as someone mentioned, there seems to be Smalltalk implementation...
But, probably it is hard to get it fast. Parrot uses a very unique approach. Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html
Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. It will be interesting to see, how they can get their JIT fast with this strategy.
Best Stefan
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.
Thanks for the answers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
You mean how their approaches compare? (I would guess, there is no direct involvement of people in both projects.) PyPy is a generator approach, your language specification i.e. the interpreter is used to generate a VM. You use a high-level language i.e. RPython to implement a classic interpreter, which is then transformed by a powerful tool-chain to your C implementation (and a JIT). Stuff like GC is just generated for you. The result is one specific VM, which is generated for your language. With Parrot it is much like with a classic VM like JVM or CLR/.NET. You are using one existing VM. Language developers use the Parrot Assembly language (PASM) or the Parrot Intermediate Representation (PIR) which can then be compiled to the bytecode set. Furthermore, they can extend the bytecode set with their own instructions (primitives). So, you are basically compiling your target language while using all the runtime features of the Parrot VM. So, here the 'power' is in the VM, not in a transformation tool chain. Best Stefan On 20 Jan 2010, at 09:02, Stéphane Ducasse wrote:
stefan
do you know how this is linked with pypy?
Stef
On Jan 20, 2010, at 8:50 AM, Stefan Marr wrote:
On 20 Jan 2010, at 06:12, Miguel Enrique Cobá Martinez wrote:
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. Well, as someone mentioned, there seems to be Smalltalk implementation...
But, probably it is hard to get it fast. Parrot uses a very unique approach. Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html
Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. It will be interesting to see, how they can get their JIT fast with this strategy.
Best Stefan
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.
Thanks for the answers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
ok so this is totally different then. Stef On Jan 20, 2010, at 9:20 AM, Stefan Marr wrote:
You mean how their approaches compare? (I would guess, there is no direct involvement of people in both projects.)
PyPy is a generator approach, your language specification i.e. the interpreter is used to generate a VM. You use a high-level language i.e. RPython to implement a classic interpreter, which is then transformed by a powerful tool-chain to your C implementation (and a JIT). Stuff like GC is just generated for you. The result is one specific VM, which is generated for your language.
With Parrot it is much like with a classic VM like JVM or CLR/.NET. You are using one existing VM. Language developers use the Parrot Assembly language (PASM) or the Parrot Intermediate Representation (PIR) which can then be compiled to the bytecode set. Furthermore, they can extend the bytecode set with their own instructions (primitives). So, you are basically compiling your target language while using all the runtime features of the Parrot VM. So, here the 'power' is in the VM, not in a transformation tool chain.
Best Stefan
On 20 Jan 2010, at 09:02, Stéphane Ducasse wrote:
stefan
do you know how this is linked with pypy?
Stef
On Jan 20, 2010, at 8:50 AM, Stefan Marr wrote:
On 20 Jan 2010, at 06:12, Miguel Enrique Cobá Martinez wrote:
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. Well, as someone mentioned, there seems to be Smalltalk implementation...
But, probably it is hard to get it fast. Parrot uses a very unique approach. Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html
Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. It will be interesting to see, how they can get their JIT fast with this strategy.
Best Stefan
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.
Thanks for the answers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
El mié, 20-01-2010 a las 09:20 +0100, Stefan Marr escribió:
You mean how their approaches compare? (I would guess, there is no direct involvement of people in both projects.)
PyPy is a generator approach, your language specification i.e. the interpreter is used to generate a VM. You use a high-level language i.e. RPython to implement a classic interpreter, which is then transformed by a powerful tool-chain to your C implementation (and a JIT). Stuff like GC is just generated for you. The result is one specific VM, which is generated for your language.
With Parrot it is much like with a classic VM like JVM or CLR/.NET. You are using one existing VM. Language developers use the Parrot Assembly language (PASM) or the Parrot Intermediate Representation (PIR) which can then be compiled to the bytecode set. Furthermore, they can extend the bytecode set with their own instructions (primitives). So, you are basically compiling your target language while using all the runtime features of the Parrot VM. So, here the 'power' is in the VM, not in a transformation tool chain.
Best Stefan
Very interesting, thanks for the info.
On 20 Jan 2010, at 09:02, Stéphane Ducasse wrote:
stefan
do you know how this is linked with pypy?
Stef
On Jan 20, 2010, at 8:50 AM, Stefan Marr wrote:
On 20 Jan 2010, at 06:12, Miguel Enrique Cobá Martinez wrote:
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. Well, as someone mentioned, there seems to be Smalltalk implementation...
But, probably it is hard to get it fast. Parrot uses a very unique approach. Actually, they try to provide a language runtime for all kinds of languages, and the right tools to build them: http://www.linux-mag.com/cache/7373/1.html
Eliot mentioned primitives, well, there is no concept of a primitive in Parrot. Instead, they have a unification of bytecodes and primitives. The idea is, to give you the tools to develop the bytecode you need for your language, which can be loaded dynamically during execution. It will be interesting to see, how they can get their JIT fast with this strategy.
Best Stefan
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.
Thanks for the answers
-- Miguel Cobá http://miguel.leugim.com.mx
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 3956 Fax: +32 2 629 3525
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
_______________________________________________ Pharo-project mailing list Pharo-project@lists.gforge.inria.fr http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project
-- Miguel Cobá http://miguel.leugim.com.mx
participants (9)
-
Denis Kudriashov -
Eliot Miranda -
Igor Stasenko -
Martin McClure -
merlyn＠stonehenge.com -
Miguel Enrique Cobá Martinez -
Stefan Marr -
Stephen Taylor -
Stéphane Ducasse