Thinking about the a modern smalltalk VM
Locked
 
|
Hi,
I don't know if this is the place to discuss this issues, but... just let me know if I'm "out of order". I was thinking about VM's (a lot, lately), mainly because some complications I found in my work with native interfaces (The Mars/Deimos project)... of course, my work is on Pharo, so not all the VM's around will have the same problem. What are the problems I'm finding? No callback logic. In fact, the new VM (4.2+) has a callback mechanism, but as the VM is not thought this way originally, is a little bit hacky. This is my main problem, but I can find other huge problems present: 1) No native multithreading/multicore (the hydravm solves this problem, but it is not "standarized") 2) Lack of modularization, which makes a lot difficult to add things like a JIT 3) squeakvm is very slow if compared with other smalltalk vms (most of the time it does the job, but who doesn't want better performance?). I know, Eliot is working in order to add performance to squeakvm (and fixing a lot of issues at the same time), but I'm beginning to think if it is not time to think in "the next level vm for smalltalk"... So, my discussion is: How can we build the next vm? I think, of course, that next vm should address the problems I mentioned, and maybe a lot of other problems. And I want to discuss also the way the squeakvm is built now: using SLANG and VMMaker... I think that was a big improvement at it's time, but now I'm not so sure... of course the ability to run the vm inside a squeak environment is very powerful, but... I don't know if a C translator is a good idea right now! why not build a VM in an object oriented language, like (that would be my choice) ObjectiveC... in case of using a translator language like e.g. ObjectiveSLANG, the translation would be much clearer and we could count with all the benefits of an object oriented approach... Of course, I'm not saying that I will do anything of that, unfortunately, I don't have the time :(... but I want to discuss it's pros and cons... Cheers. Esteban |
Re: Thinking about the a modern smalltalk VM
|
|
Hi people!
Esteban, I'm writing an open source VM in C# (it could be ported to Java, or compiled in Mono, I guess, I didn't try), that can access and manipulates native CLR objects and .NET framework library, as others .NET dlls. You can access sockets, multithreading, etc... It could be invoked from a .NET program. I should post more about my work in progress. Some ideas: implements remote objects, transparently to language and VM, write an ASP.NET handler that uses that VM with Smalltalk, implements a Message Passing mechanism (that is, send a one-way (no wait for reply) message to an object), traits, etc.... Any other VM written with C#? One point I'm discussing with myself: abandon bytecode, and uses directly an interpreter pattern (each object in the three has something like .Execute method). It's not clear to me, what is callback for you, or in Smalltalk environment. Any example? Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez On Mon, Feb 15, 2010 at 1:22 PM, Esteban Lorenzano <[hidden email]> wrote: Hi, |
Re: Thinking about the a modern smalltalk VM
|
|
On Feb 15, 5:53 pm, Angel Java Lopez <[hidden email]> wrote: > Any other VM written with C#? VMs or languages? As far as I know is C# kind of the new standard inside of Microsoft and all the Iron* languages are build using it. But they don't build VMs. Instead the try to utilize the CLR where ever possible and have the 'dynamic language runtime' to facilitate the needs of the Iron* languages. > One point I'm discussing with myself: abandon bytecode, and uses directly an > interpreter pattern (each object in the three has something like .Execute > method). That is an interesting thought. However, for instance Ruby abolished the AST-base interpreter because it was to slow. On the other hand, there is no research which states that there is a fundamental problem with that approach, and some properties of todays systems, and the switch to many-core might give rise to that idea again. An article on that topic: Are Bytecodes an Atavism? http://www.springerlink.com/content/p22p573q75123061/ and a recording of the talk: http://www.tele-task.de/archive/lecture/overview/3624/ Best regards Stefan |
Re: Thinking about the a modern smalltalk VM
|
|
Hi people!
Thanks, Stefan, interesting info/links (nice to read BCPL mentioned, I still remember my experience with that language/VM) (and nice to see those ideas related to S3) I just remember, IronSmalltalk, but apparently, it's frozen: http://ironsmalltalk.codeplex.com/ using DLR, as IronPython, IronRuby, Clojure-CLR, and I saw an Iron Common Lisp or something alike.. One doubt: if my interpreter produce bytecodes, and executed them, is it a VM? And if it use the interpreter pattern, without bytecodes, is it a VM? Angel "Java" Lopez http://www.ajlopez.com http://twitter.com/ajlopez On Mon, Feb 15, 2010 at 4:09 PM, Stefan Marr <[hidden email]> wrote: VMs or languages? As far as I know is C# kind of the new standard |
Re: Thinking about the a modern smalltalk VM
|
|
On Feb 16, 12:17 am, Angel Java Lopez <[hidden email]> wrote:
> One doubt: if my interpreter produce bytecodes, and executed them, is it a > VM? And if it use the interpreter pattern, without bytecodes, is it a VM? Well, you're asking for a definition of VM? Cannot remember a good one... Personally, for high-level language VMs, I would go with what we see in Smalltalk, JVM, and CLR alike systems. To call it a VM, it should have some form of memory management (usually with a GC), an execution engine (interpreter, JIT, ...), a compiling or loading component (to load code for execution), and probably some kind of system interface to interact with underlying OS. If your 'interpreter' produces bytecode, why not call it a compiler instead? And interpreters also are interpreters if they work on abstract syntax trees, I wouldn't insist on bytecodes ;) However, maybe there is a nice language agnostic book about high-level language VMs out there, with a nice definition. Haven't found it yet, so any hints are welcome :) Best regards Stefan |
Re: Thinking about the a modern smalltalk VM
|
|
Hi,
On Tue, Feb 16, 2010 at 12:37 AM, Stefan Marr <[hidden email]> wrote: > On Feb 16, 12:17 am, Angel Java Lopez <[hidden email]> wrote: >> One doubt: if my interpreter produce bytecodes, and executed them, is it a >> VM? And if it use the interpreter pattern, without bytecodes, is it a VM? > Well, you're asking for a definition of VM? Cannot remember a good > one... oh, *that* one again. :-] I tend to make it simple for myself: if it provides an execution substrate (a machine) that is not really there (virtual), it's a virtual machine. Of course, this is debatable as well, but it makes (my) life easier, and it works quite well (for me). > Personally, for high-level language VMs, I would go with what we see > in Smalltalk, JVM, and CLR alike systems. > To call it a VM, it should have some form of memory management > (usually with a GC), an execution engine (interpreter, JIT, ...), a > compiling or loading component (to load code for execution), and > probably some kind of system interface to interact with underlying OS. So Potato (http://potatovm.sourceforge.net/) ain't a VM since it ain't got no memory manager; the underlying JVM does it all. Nah. I'd say Potato is a VM as well. :-) SOM (http://www.hpi.uni-potsdam.de/hirschfeld/projects/som/index.html) does the same, and its offspring CSOM only relied on malloc() for memory "management" - still I'd call those VMs, yup. > If your 'interpreter' produces bytecode, why not call it a compiler > instead? What would you call an interpreter that applies direct threading, possibly with selective inlining? ;-) > However, maybe there is a nice language agnostic book about high-level > language VMs out there, with a nice definition. > Haven't found it yet, so any hints are welcome :) Smith/Nair comes to mind. Craig's book takes a formal approach, but is also nice. They probably don't provide anything you'd accept as a definition, though. ;-) Best, Michael |
Re: Thinking about the a modern smalltalk VM
|
|
On Feb 16, 8:36 am, Michael Haupt <[hidden email]> wrote:
> > Personally, for high-level language VMs, I would go with what we see > > in Smalltalk, JVM, and CLR alike systems. > > To call it a VM, it should have some form of memory management > > (usually with a GC), an execution engine (interpreter, JIT, ...), a > > compiling or loading component (to load code for execution), and > > probably some kind of system interface to interact with underlying OS. > > So Potato (http://potatovm.sourceforge.net/) ain't a VM since it ain't > got no memory manager; the underlying JVM does it all. Nah. I'd say > Potato is a VM as well. :-) system, allocate something, and then don't care about it anymore. But maybe Potato is just an interpreter? > > If your 'interpreter' produces bytecode, why not call it a compiler > > instead? > > What would you call an interpreter that applies direct threading, > possibly with selective inlining? ;-) What I was aiming at is, if you implement a language by doing ahead-of- time compilation to bytecode and then have some kind of runtime libraries, I do not see that much of a difference to C++, and I would argue that it might be just a compiler. > Smith/Nair comes to mind. Craig's book takes a formal approach, but is > also nice. They probably don't provide anything you'd accept as a > definition, though. ;-) Haven't read Craig's book, but I looks interesting on google books. Can you borrow me a copy when you are in Brussels ;) Best regards Stefan |
Re: Thinking about the a modern smalltalk VM
|
|
Hi,
On Tue, Feb 16, 2010 at 10:17 AM, Stefan Marr <[hidden email]> wrote: >> So Potato (http://potatovm.sourceforge.net/) ain't a VM since it ain't >> got no memory manager; the underlying JVM does it all. Nah. I'd say >> Potato is a VM as well. :-) > 'Some form of memory management' could also be read like: go to the > system, allocate something, and then don't care about it anymore. > But maybe Potato is just an interpreter? I really object to separating that. In my little world, an interpreter can be a component of a VM if the design choice is to apply some form of interpretation (as opposed to, say, JIT compilation to the native code of the underlying platform). So, Potato has one component that is an interpreter. It *applies* interpretation, but it is *not* an interpreter. It *is* a VM. :-) Nitpicker, me. > What I was aiming at is, if you implement a language by doing ahead-of- > time compilation to bytecode and then have some kind of runtime > libraries, I do not see that much of a difference to C++, and I would > argue that it might be just a compiler. Ah, gcj, for instance. Interesting question. Yes, it might be a compiler. Still, it would run in a virtualised environment that creates the illusion of being an execution substrate for whatever source language is involved. > Haven't read Craig's book, but I looks interesting on google books. > Can you borrow me a copy when you are in Brussels ;) Nopes, sorry; I need that during Summer term. :-) Best, Michael |
«
Return to English
|
1 view|%1 views
| Free forum by Nabble | Edit this page |