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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
>>>>> "Miguel" == Miguel Enrique Cobá Martinez <[hidden email]> 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 <[hidden email]> <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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Randal L. Schwartz wrote:
> Parrot's GC suffers from having many different kinds of mixed objects. Could you explain (or give a pointer) to what you mean by "mixed objects"? Steve _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Stephen Taylor wrote:
> Randal L. Schwartz wrote: > >> Parrot's GC suffers from having many different kinds of mixed objects. > > Could you explain (or give a pointer) to what you mean by "mixed objects"? Basically, an object with both pointer and non-pointer contents. -Martin _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Randal L. Schwartz
>>>>> "Randal" == Randal L Schwartz <[hidden email]> 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 <[hidden email]> <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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Miguel Cobá
2010/1/19 Miguel Enrique Cobá Martinez <[hidden email]> Parrot has just been released: 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.
_______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In parrot site languages section there is "chitchat — An implementation of Smalltalk"
Anybody know what is it? _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Miguel Cobá
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 > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
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 >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] 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 >>> [hidden email] >>> 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 >> [hidden email] >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > _______________________________________________ > Pharo-project mailing list > [hidden email] > 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 [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Randal L. Schwartz
2010/1/20 Randal L. Schwartz <[hidden email]>:
>>>>>> "Randal" == Randal L Schwartz <[hidden email]> 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 > <[hidden email]> <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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Best regards, Igor Stasenko AKA sig. _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stefan Marr-4
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 >>>> [hidden email] >>>> 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 >>> [hidden email] >>> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project >> >> >> _______________________________________________ >> Pharo-project mailing list >> [hidden email] >> 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 > [hidden email] > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Eliot Miranda-2
El mar, 19-01-2010 a las 22:02 -0800, Eliot Miranda escribió:
> > > 2010/1/19 Miguel Enrique Cobá Martinez <[hidden email]> > 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 _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
In reply to this post by Stefan Marr-4
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 > >>> [hidden email] > >>> 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 > >> [hidden email] > >> http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > > > > > > _______________________________________________ > > Pharo-project mailing list > > [hidden email] > > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project > -- Miguel Cobá http://miguel.leugim.com.mx _______________________________________________ Pharo-project mailing list [hidden email] http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-project |
Free forum by Nabble | Edit this page |