From kyle_hayes@speakeasy.net Fri Jul 12 02:30:37 2002 From: kyle_hayes@speakeasy.net (kyle) Date: Thu, 11 Jul 2002 18:30:37 -0700 Subject: [virtmach] parrot VM? Message-ID: <02071118303701.27130@nahuatl> There was a post here about a year ago that asked about the Parrot VM. There wasn't a lot of response. Parrot appears to be turning into a fairly "real" project now. There was a bit of Q&A posted about Parrot on the use Perl site and one of the questions was "register based?". The response indicated that a register-based VM is more efficient than a stack-based VM even on x86 (at least that is how I read it). The statement didn't make any real attempt to justify this. This doesn't really sound right to me and since I'm stuck with x86 for the forseeable future, I'd like to know. Is there any further info on the Parrot VM? The details seem to be relatively sparse still. Anyone have any more info? Are there some other, documented VMs that use registers instead of a stack as the primary workspace? Best, Kyle From anton@mips.complang.tuwien.ac.at Fri Jul 12 10:36:29 2002 From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Date: Fri, 12 Jul 2002 11:36:29 +0200 (MET DST) Subject: [virtmach] parrot VM? In-Reply-To: <02071118303701.27130@nahuatl> from "kyle" at Jul 11, 2002 06:30:37 PM Message-ID: <200207120936.LAA19082@a0.complang.tuwien.ac.at> kyle wrote: > There was a bit of Q&A posted about Parrot on the use Perl site and one of > the questions was "register based?". The response indicated that a > register-based VM is more efficient than a stack-based VM even on x86 (at > least that is how I read it). The statement didn't make any real attempt to > justify this. This doesn't really sound right to me and since I'm stuck with > x86 for the forseeable future, I'd like to know. This has been discussed several times on comp.compilers and elsewhere, e.g. in the thread including <01-01-124@comp.compilers>. Lots of arguments have been exchanged, but empirical evidence is missing (and it's a lot of work, and IMO one would need several cases to draw general conclusions). > Are there some other, documented VMs that use registers instead of a stack as > the primary workspace? The WAM, the Inferno VM, and the Tao VM come to mind. - anton From virtmach@iecc.com Fri Jul 12 22:28:57 2002 From: virtmach@iecc.com (Manoj Plakal) Date: Fri, 12 Jul 2002 16:28:57 -0500 Subject: [virtmach] parrot VM? In-Reply-To: <02071118303701.27130@nahuatl>; from kyle_hayes@speakeasy.net on Thu, Jul 11, 2002 at 06:30:37PM -0700 References: <02071118303701.27130@nahuatl> Message-ID: <20020712162857.A24761@cs.wisc.edu> kyle wrote (Thu, Jul 11, 2002 at 06:30:37PM -0700) : > Is there any further info on the Parrot VM? The details seem to be > relatively sparse still. Anyone have any more info? > Are there some other, documented VMs that use registers instead of a stack as > the primary workspace? There's a FAQ on parrotcode.org with some sketchy info. They mention the MacOS 68K emulator as a register VM. http://developer.apple.com/techpubs/mac/PPCSoftware/PPCSoftware-13.html Aren't the main advantages of stack VMs: (a) smaller (interpreted) code size, and (b) simpler compiler? Is there some other obvious reason to use a stack VM? Manoj From ian.piumarta@inria.fr Fri Jul 12 22:37:01 2002 From: ian.piumarta@inria.fr (Ian Piumarta) Date: Fri, 12 Jul 2002 23:37:01 +0200 (MET DST) Subject: [virtmach] parrot VM? In-Reply-To: <20020712162857.A24761@cs.wisc.edu> Message-ID: On Fri, 12 Jul 2002, Manoj Plakal wrote: > Aren't the main advantages of stack VMs: > (a) smaller (interpreted) code size Depends on the insn encoding. But in practice almost always. > and (b) simpler compiler? Yes. I imagine register allocation (done right) would be a significant complication in the bytecode compiler. > Is there some other obvious reason to use a stack VM? When dynamically translating to native code at runtime it's much easier to generate register-based native code off a stack-based bytecode than it is to do it off a register-based one (or even convert back to pure stack-based code for some architectures which have no registers). One reason for this is that the stack manipulation in the bytecode has lots of implicit information in it (e.g., lifetimes) that would be missing in register-based code. Ian From virtmach@iecc.com Fri Jul 12 22:42:05 2002 From: virtmach@iecc.com (Chris Lattner) Date: Fri, 12 Jul 2002 16:42:05 -0500 (CDT) Subject: [virtmach] parrot VM? In-Reply-To: Message-ID: > > and (b) simpler compiler? > Yes. I imagine register allocation (done right) would be a significant > complication in the bytecode compiler. Although the register allocator would give much better results than simple tree based heuristics used for stack machines. Linear scan register allocation isn't that hard, and gives quite reasonable results. > > Is there some other obvious reason to use a stack VM? One very significant drawback of stack-based VMs is that they are almost impossible to do meaningful optimizations on. If your VM performs any substation optimization, you will often find that you have to translate from a stack-based rep to a register based representation anyway, losing any advantages the stack based VM gives you. -Chris http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/ From virtmach@iecc.com Fri Jul 12 23:15:06 2002 From: virtmach@iecc.com (Manoj Plakal) Date: Fri, 12 Jul 2002 17:15:06 -0500 Subject: [virtmach] parrot VM? In-Reply-To: ; from ian.piumarta@inria.fr on Fri, Jul 12, 2002 at 11:37:01PM +0200 References: <20020712162857.A24761@cs.wisc.edu> Message-ID: <20020712171506.A25186@cs.wisc.edu> Ian Piumarta wrote (Fri, Jul 12, 2002 at 11:37:01PM +0200) : > When dynamically translating to native code at runtime it's much easier to > generate register-based native code off a stack-based bytecode than it is > to do it off a register-based one (or even convert back to pure > stack-based code for some architectures which have no registers). One > reason for this is that the stack manipulation in the bytecode has lots of > implicit information in it (e.g., lifetimes) that would be missing in > register-based code. That's interesting. But are you talking about extra information in the bytecode, or are you referring to simply popping a value off the stack as ending its lifetime? Registers get overwritten too, so that can convey the same information. Do you have a short example of strictly more information available in a stack-VM bytecode sequence than a register-VM sequence? Manoj From virtmach@iecc.com Fri Jul 12 23:26:08 2002 From: virtmach@iecc.com (Manoj Plakal) Date: Fri, 12 Jul 2002 17:26:08 -0500 Subject: [virtmach] parrot VM? In-Reply-To: ; from sabre@nondot.org on Fri, Jul 12, 2002 at 04:42:05PM -0500 References: Message-ID: <20020712172608.B25186@cs.wisc.edu> Chris Lattner wrote (Fri, Jul 12, 2002 at 04:42:05PM -0500) : > > > and (b) simpler compiler? > > Yes. I imagine register allocation (done right) would be a significant > > complication in the bytecode compiler. > > Although the register allocator would give much better results than simple > tree based heuristics used for stack machines. Linear scan register > allocation isn't that hard, and gives quite reasonable results. > > > > Is there some other obvious reason to use a stack VM? > > One very significant drawback of stack-based VMs is that they are almost > impossible to do meaningful optimizations on. If your VM performs any > substation optimization, you will often find that you have to translate > from a stack-based rep to a register based representation anyway, losing > any advantages the stack based VM gives you. True. I think that if you want a high-performance VM, then you probably want to do a register VM. But aren't there some portability issues with a register VM? Wouldn't you want to map the VM registers to real registers (since you want performance in the first place)? That might make it difficult to have a register VM that runs fast on both, say, x86 and MIPS. I'd say that a stack-based VM seems a good option if you want a portable VM and a simple compiler and code size is an issue. The Parrot folks (based on some browsing of the Perl lists) seem to opt for register VMs for performance and "easier debugging." Manoj From anton@mips.complang.tuwien.ac.at Sat Jul 13 08:45:03 2002 From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Date: Sat, 13 Jul 2002 09:45:03 +0200 (MET DST) Subject: [virtmach] parrot VM? In-Reply-To: from "Chris Lattner" at Jul 12, 2002 04:42:05 PM Message-ID: <200207130745.JAA21716@a0.complang.tuwien.ac.at> Chris Lattner wrote: > > > > and (b) simpler compiler? > > Yes. I imagine register allocation (done right) would be a significant > > complication in the bytecode compiler. > > Although the register allocator would give much better results than simple > tree based heuristics used for stack machines. What kind of results do you mean? The register allocator may reduce the number of VM instructions executed (although even that is not clear, given that it might produce explicit code for spilling, whereas spilling is implicit in stack-based code), but - in a VM interpreter this reduction has to make up for the increased decoding overhead of register-based instructions before gaining any speed. - a VM-to-native compiler will reallocate the registers anyway for best results, specific to the number of registers etc. on the target machine, so an earlier register allocation effort is probably wasted. > > > Is there some other obvious reason to use a stack VM? > > One very significant drawback of stack-based VMs is that they are almost > impossible to do meaningful optimizations on. Well, for some reason the architects of the Amsterdam Compiler Kit, the MIPS compilers, and the Garden Point compilers (Queensland) chose stack-based intermediate representations for their compilers, and optimized them, so it cannot be that bad. I would not use a stack-based VM for most optimizations, though, and neither would I use a register-based VM. VMs are for direct execution by an interpreter, or at least as a close-to-execution representation of a program; for most optimizations I would use data-flow graphs, SSA and such, and these can be created from stack-based code at least as easily as from register-based code. - anton From Stephen Pelc Sat Jul 13 11:49:08 2002 From: Stephen Pelc (Stephen Pelc) Date: Sat, 13 Jul 2002 11:49:08 +0100 Subject: [virtmach] parrot VM? In-Reply-To: References: Message-ID: <3D3013B4.4753.1CF9D8CA@localhost> From: Chris Lattner > One very significant drawback of stack-based VMs is that they are > almost impossible to do meaningful optimizations on. If your VM > performs any substation optimization, you will often find that > you have to translate from a stack-based rep to a register based > representation anyway, losing any advantages the stack based VM > gives you. Please explain this further. I ask because I have implemented optimising code generators for stack based token systems for six different CPU architectures, and my conclusion is that classical compiler technology works very well with stack-based VMs. Stephen -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 23 80 631441, fax: +44 23 80 339691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads From virtmach@iecc.com Sat Jul 13 18:26:31 2002 From: virtmach@iecc.com (Chris Lattner) Date: Sat, 13 Jul 2002 12:26:31 -0500 (CDT) Subject: [virtmach] parrot VM? In-Reply-To: <200207130745.JAA21716@a0.complang.tuwien.ac.at> Message-ID: > > > Yes. I imagine register allocation (done right) would be a significant > > > complication in the bytecode compiler. > > Although the register allocator would give much better results than simple > > tree based heuristics used for stack machines. > > What kind of results do you mean? The register allocator may reduce > the number of VM instructions executed (although even that is not > clear, given that it might produce explicit code for spilling, whereas > spilling is implicit in stack-based code), but The whole point over explicit register allocation, rather than using implicit allocation based on the stack, is that you actually have a decent chance of doing a good register allocation, regardless of how many registers your target architecture has. To be more concrete, lets consider two machines: one is x86like (~6 general purpose regs), one is mips/sparc'like (32 GPRs). From what I understand of register allocation for stack machines, you basically assign slots in the stack to different registers. For most stack machines, there is a very clear correspondence between the code as written by the human, and the stack code generated. For example: X = (A+B)*(C+D) would turn into: load A load B add load C load D add mul store X Or somesuch. Stack based register allocation would trivially assign three registers to that expression (one for each of the adds and the mul). Depending on the sophistication of the VM, the variables themselves may be in registers, but that's irrelevant for this discussion. This is a nice clean, simple approach to register allocation, for sure. The problem then is that you are depending on the human to do the register allocation for you, which means that you cannot do a good job for the machine you are targetting (you lose platform independence). For example, on the x86 type of machine, you will probably do a somewhat reasonable allocation, but there is almost no chance that you will do a good allocation for the sparc (the stack will rarely grow to 32 entries deep). One poster mentioned that a nice property of a stack machine is that you get explicit lifetime information from the stack properties (when a value is popped, it IS dead). This simplifies liveness analysis used for register based graph coloring as well as the simple stack case: The Latte JVM, for example, adds annotations to the registers when it converts from Java bytecode to its internal register based architecture. It then uses these annotations to make liveness analysis very easy. The only problem is that they must be tracked and updated when optimizing. > - in a VM interpreter this reduction has to make up for the increased > decoding overhead of register-based instructions before gaining any > speed. That's is certainly always a tradeoff faced by VMs: better optimizations must be paid for with repeated use of the generated code. Having lots of spills do to poor allocation is a very good way to slow down the application though. > - a VM-to-native compiler will reallocate the registers anyway for > best results, specific to the number of registers etc. on the target > machine, so an earlier register allocation effort is probably wasted. I'm not talking about earlier register allocation, and perhaps that's what's confusing things. I'm advocating an infinite register VM (for example see the SafeTSA paper, published in PLDI2001). Part of my point is that if you are going to convert your stack machine to a register based machine, then there is no reason to use a stack machine in the first place! > > One very significant drawback of stack-based VMs is that they are almost > > impossible to do meaningful optimizations on. > > Well, for some reason the architects of the Amsterdam Compiler Kit, > the MIPS compilers, and the Garden Point compilers (Queensland) chose > stack-based intermediate representations for their compilers, and > optimized them, so it cannot be that bad. I am honestly curious what types of optimizations you performed, and what transformations you applied to the stack to transform it. As I see it, optimizing a stack machine is effectively equivalent to optimizing an AST based representation, which is possible, but very painful. Simple optimizations like LICM and CSE seem reasonable on a stack machine, but how do you handle things like load/store motion, PRE, loop transformations, scalar replacement, etc... > I would not use a stack-based VM for most optimizations, though, and > neither would I use a register-based VM. VMs are for direct execution > by an interpreter, or at least as a close-to-execution representation > of a program; for most optimizations I would use data-flow graphs, SSA > and such, and these can be created from stack-based code at least as > easily as from register-based code. Again, when I say "register based", I mean in contrast to stack based... SSA is a perfect representation for many sparse optimization (my work is in the context of an SSA based infinite register VM, f.e.). So "register based" is already a great representation for optimization... -Chris http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/ From virtmach@iecc.com Sat Jul 13 18:28:34 2002 From: virtmach@iecc.com (Chris Lattner) Date: Sat, 13 Jul 2002 12:28:34 -0500 (CDT) Subject: [virtmach] parrot VM? In-Reply-To: <3D3013B4.4753.1CF9D8CA@localhost> Message-ID: > > One very significant drawback of stack-based VMs is that they are > > almost impossible to do meaningful optimizations on. If your VM > > performs any substation optimization, you will often find that > > you have to translate from a stack-based rep to a register based > > representation anyway, losing any advantages the stack based VM > > gives you. > Please explain this further. Please see my previous email... > I ask because I have implemented optimising code generators for > stack based token systems for six different CPU architectures, > and my conclusion is that classical compiler technology works > very well with stack-based VMs. Can you give some examples of the types of transformations that you are using? Are you converting the stack machine into some cannonical form before you optimize, or some other internal representation? -Chris http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/ From virtmach@iecc.com Sat Jul 13 18:30:23 2002 From: virtmach@iecc.com (Chris Lattner) Date: Sat, 13 Jul 2002 12:30:23 -0500 (CDT) Subject: [virtmach] parrot VM? In-Reply-To: <20020712172608.B25186@cs.wisc.edu> Message-ID: > > One very significant drawback of stack-based VMs is that they are almost > > impossible to do meaningful optimizations on. If your VM performs any > > substation optimization, you will often find that you have to translate > > from a stack-based rep to a register based representation anyway, losing > > any advantages the stack based VM gives you. > But aren't there some portability issues with a register VM? > Wouldn't you want to map the VM registers to real registers > (since you want performance in the first place)? That > might make it difficult to have a register VM that runs fast The idea is not to emit a certain number of registers (GNU lightning uses 6 always for example [I believe]), but to use an infinite number of registers, then run a register allocation pass as part of code generation, to convert it into the optimal number of registers for the actual machine... -Chris http://llvm.cs.uiuc.edu/ http://www.nondot.org/~sabre/Projects/ From virtmach@iecc.com Sat Jul 13 21:19:15 2002 From: virtmach@iecc.com (Norman Ramsey) Date: Sat, 13 Jul 2002 16:19:15 -0400 Subject: [virtmach] parrot VM? In-Reply-To: Message from kyle of "Thu, 11 Jul 2002 18:30:37 PDT." <02071118303701.27130@nahuatl> References: <02071118303701.27130@nahuatl> Message-ID: <20020713201915.5D38F54C805@mail.eecs.harvard.edu> The Lua implementors (www.lua.org) claim to have got a performance improvement by switching from a stack vm to a register vm (with effectively infinitely many registers). Norman From virtmach@iecc.com Sat Jul 13 22:03:13 2002 From: virtmach@iecc.com (Manoj Plakal) Date: Sat, 13 Jul 2002 16:03:13 -0500 Subject: [virtmach] parrot VM? In-Reply-To: ; from sabre@nondot.org on Sat, Jul 13, 2002 at 12:30:23PM -0500 References: <20020712172608.B25186@cs.wisc.edu> Message-ID: <20020713160313.B25313@cs.wisc.edu> Chris Lattner wrote (Sat, Jul 13, 2002 at 12:30:23PM -0500) : > > But aren't there some portability issues with a register VM? > > Wouldn't you want to map the VM registers to real registers > > (since you want performance in the first place)? That > > might make it difficult to have a register VM that runs fast > > The idea is not to emit a certain number of registers (GNU lightning uses > 6 always for example [I believe]), but to use an infinite number of > registers, then run a register allocation pass as part of code generation, > to convert it into the optimal number of registers for the actual > machine... So the VM has to run this register allocation pass on the platform-independent bytecodes before it executes them? Any examples (someone mentioned Lua?) of a register VM that does this? Manoj From virtmach@iecc.com Sat Jul 13 00:23:51 2002 From: virtmach@iecc.com (Reuben Thomas) Date: Sat, 13 Jul 2002 00:23:51 +0100 (BST) Subject: [virtmach] parrot VM? In-Reply-To: Message-ID: > > Is there some other obvious reason to use a stack VM? > > When dynamically translating to native code at runtime it's much easier > to generate register-based native code off a stack-based bytecode than > it is to do it off a register-based one (or even convert back to pure > stack-based code for some architectures which have no registers). One > reason for this is that the stack manipulation in the bytecode has lots > of implicit information in it (e.g., lifetimes) that would be missing in > register-based code. That's interesting, I came to the opposite conclusion, i.e. that register-based VMs have more useful implicit information. On the other hand, my VM Mite (www.mupsych.org/~rrt/research/) does have a rather curious register stack precisely in order to make some of this information easier to get at quickly in a JIT compiler. Indeed, whether you think my VM is register or stack-based is principally a matter of opinion. The instructions are conventional 3-operand register instructions, but you can think of them equally as referring to stack positions. -- http://www.mupsych.org/~rrt/ | competent, a. underpromoted From virtmach@iecc.com Sat Jul 13 00:26:45 2002 From: virtmach@iecc.com (Reuben Thomas) Date: Sat, 13 Jul 2002 00:26:45 +0100 (BST) Subject: [virtmach] parrot VM? In-Reply-To: <20020712172608.B25186@cs.wisc.edu> Message-ID: > But aren't there some portability issues with a register VM? > Wouldn't you want to map the VM registers to real registers > (since you want performance in the first place)? That > might make it difficult to have a register VM that runs fast > on both, say, x86 and MIPS. All this means is that you have to do register allocation. There are tricks that allow you to do most of the work at VM compile time, and leave little enough that a JIT compiler can still produce reasonable code fairly fast. See my PhD thesis on Mite (www.mupsych.org/~rrt/research/). > I'd say that a stack-based VM seems a good option if > you want a portable VM and a simple compiler and code size > is an issue. I'd agree. [Apologies to anyone who feels my replies on this subject are turning into a series of ads for Mite; I'm only repeating myself for the benefit of those who haven't read the whole thread!] -- http://www.mupsych.org/~rrt/ | free, a. already paid for (Peyton Jones) From virtmach@iecc.com Fri Jul 12 12:31:00 2002 From: virtmach@iecc.com (Ralph Corderoy) Date: Fri, 12 Jul 2002 12:31:00 +0100 Subject: [virtmach] Daily virtmach digest V2 #1 In-Reply-To: Message from virtmach-owner@lists.iecc.com of "Fri, 12 Jul 2002 05:20:25 EDT." <1026465676.206929.0@tom.iecc.com> Message-ID: <200207121131.g6CBV0k06391@blake.inputplus.co.uk> Hi Kyle, > There was a bit of Q&A posted about Parrot on the use Perl site and > one of the questions was "register based?". The response indicated > that a register-based VM is more efficient than a stack-based VM even > on x86 (at least that is how I read it). I haven't followed any Perl 6 stuff, but Bell Labs's Inferno OS used a VM which was register-based, IIRC. It was one of its many advantages over Java in that area. And they've published various papers on it, at least one of which covers the VM design. Google for Inferno, you might find the papers at the Vita Nuova site these days. Cheers, Ralph. From virtmach@iecc.com Sun Jul 14 07:06:26 2002 From: virtmach@iecc.com (Chris Lattner) Date: Sun, 14 Jul 2002 01:06:26 -0500 (CDT) Subject: [virtmach] parrot VM? In-Reply-To: <20020713160313.B25313@cs.wisc.edu> Message-ID: > So the VM has to run this register allocation pass > on the platform-independent bytecodes before it executes > them? Any examples (someone mentioned Lua?) of > a register VM that does this? Presumably (unless it's an interpreter, and then performance is not the issue), the platform-independant bytecodes will have to be translated to native code anyway. Register allocation is just one part of that... -Chris http://www.nondot.org/~sabre/os/ http://www.nondot.org/~sabre/Projects/ From anton@mips.complang.tuwien.ac.at Sun Jul 14 08:01:39 2002 From: anton@mips.complang.tuwien.ac.at (Anton Ertl) Date: Sun, 14 Jul 2002 09:01:39 +0200 (MET DST) Subject: [virtmach] parrot VM? In-Reply-To: <20020713201915.5D38F54C805@mail.eecs.harvard.edu> from "Norman Ramsey" at Jul 13, 2002 04:19:15 PM Message-ID: <200207140701.JAA22769@a0.complang.tuwien.ac.at> Norman Ramsey wrote: > > The Lua implementors (www.lua.org) claim to have got a performance > improvement by switching from a stack vm to a register vm (with > effectively infinitely many registers). I just looked through the site, and did not find that claim; http://www.lua.org/history.html is the only place I found that mentions the VM at all, and only in passing (and only the stack-based VM). Using google I found from April, which reports that lua has a stack-based VM. If you remember where you read about the Lua register VM, I would appreciate a reference. Thanks in advance, - anton From virtmach@iecc.com Sun Jul 14 11:50:41 2002 From: virtmach@iecc.com (Manoj Plakal) Date: Sun, 14 Jul 2002 05:50:41 -0500 Subject: [virtmach] parrot VM? In-Reply-To: <200207140701.JAA22769@a0.complang.tuwien.ac.at>; from anton@a0.complang.tuwien.ac.at on Sun, Jul 14, 2002 at 09:01:39AM +0200 References: <20020713201915.5D38F54C805@mail.eecs.harvard.edu> <200207140701.JAA22769@a0.complang.tuwien.ac.at> Message-ID: <20020714055041.A31103@cs.wisc.edu> Anton Ertl wrote (Sun, Jul 14, 2002 at 09:01:39AM +0200) : > Norman Ramsey wrote: > > The Lua implementors (www.lua.org) claim to have got a performance > > improvement by switching from a stack vm to a register vm (with > > effectively infinitely many registers). > > If you remember where you read about the Lua register VM, I would > appreciate a reference. Thanks in advance, From the lua mailing list archives: http://groups.yahoo.com/group/lua-l/message/4900 http://groups.yahoo.com/group/lua-l/message/4531 http://groups.yahoo.com/group/lua-l/message/4544 I browsed through the lua-4.0.1 sources. It does seem to be a register VM now. The instruction format allows specifying two integers in addition to the opcodes, and these are used to access local vars by indexing into the single execution stack, thus allowing effectively infinite regs as Norman pointed out. The HISTORY file mentions a 20% speedup due to the VM change and this might be because earlier local var access required extra instructions (as pointed out in one of the above messages). Manoj From Stephen Pelc Sun Jul 14 12:45:07 2002 From: Stephen Pelc (Stephen Pelc) Date: Sun, 14 Jul 2002 12:45:07 +0100 Subject: [virtmach] parrot VM? In-Reply-To: References: <3D3013B4.4753.1CF9D8CA@localhost> Message-ID: <3D317253.17039.52B2754@localhost> > Can you give some examples of the types of transformations that > you are using? Are you converting the stack machine into some > cannonical form before you optimize, or some other internal > representation? The code generators are one-pass (for speed/simplicity) and the major data unit is what we call the "working stack". This is a representation of the stack, from which code is generated and registers allocated as needed. Most of the classical optimisations are available. From the working stack you code generate, and the end of basic blocks you can then transform ("shuffle") the working stack to whatever canonical form you have chosen for the stack. So far the shuffle is the only code generation element I have found that is unique to stack machines. There are a couple of simplistic papers about the VFX code generator on our web site, but this *is* a commercial product ... Funny thing is, we didn't release the source code for VFX until after we had serious competition in performance, and we had about three years as clear performance leaders (3:1 and more) in the marketplace. Ho, hum - now back to improving it some more. Stephen -- Stephen Pelc, sfp@mpeltd.demon.co.uk MicroProcessor Engineering Ltd - More Real, Less Time 133 Hill Lane, Southampton SO15 5AF, England tel: +44 23 80 631441, fax: +44 23 80 339691 web: http://www.mpeltd.demon.co.uk - free VFX Forth downloads From virtmach@iecc.com Mon Jul 15 16:02:21 2002 From: virtmach@iecc.com (Norman Ramsey) Date: Mon, 15 Jul 2002 11:02:21 -0400 Subject: [virtmach] parrot VM? In-Reply-To: Message from Anton Ertl of "Sun, 14 Jul 2002 09:01:39 +0200." <200207140701.JAA22769@a0.complang.tuwien.ac.at> References: <200207140701.JAA22769@a0.complang.tuwien.ac.at> Message-ID: <20020715150221.356C954C551@mail.eecs.harvard.edu> > Norman Ramsey wrote: > > > > The Lua implementors (www.lua.org) claim to have got a performance > > improvement by switching from a stack vm to a register vm (with > > effectively infinitely many registers). > > I just looked through the site, and did not find that claim; > http://www.lua.org/history.html is the only place I found that > mentions the VM at all, and only in passing (and only the stack-based > VM). > > Using google I found > from > April, which reports that lua has a stack-based VM. > > If you remember where you read about the Lua register VM, I would > appreciate a reference. Thanks in advance, Roberto Ierusalimschy talked about it when he gave a talk here in February. Lua used to have a stack-based VM back when I had my hands on the code. Norman From virtmach@iecc.com Tue Jul 16 14:28:48 2002 From: virtmach@iecc.com (virtmach@iecc.com) Date: Tue, 16 Jul 2002 14:28:48 +0100 Subject: [virtmach] register vs. stack machines Message-ID: <94a65f3e88078822f964ee3720e0ff4e@vitanuova.com> see: http://www.cs.bell-labs.com/who/rob/hotchips.html From virtmach@iecc.com Tue Jul 16 14:41:46 2002 From: virtmach@iecc.com (Durchholz, Joachim) Date: Tue, 16 Jul 2002 15:41:46 +0200 Subject: [virtmach] register vs. stack machines Message-ID: > see: > http://www.cs.bell-labs.com/who/rob/hotchips.html The Dis papers tend to strongly state the advantages of the choices that were made for Dis, instead of presenting the full engineering trade-offs. Which makes them great for evangelisation, but not so great for preparing your own decisions. For example, the cited paper doesn't discuss the disadvantages of reference-counting garbage collection (increased memory traffic to keep the reference counts up-to-date, object reclamation as a possible and unexpected side effect of pointer assignments which makes it difficult to guarantee real-time deadlines). I don't know how far this sloppiness/marketing speak attitude transfers to their discussion of stack vs. register architecture. I'd rate the Dis literature as an interesting data point, but not as an authority. Just my 2c. Joachim From virtmach@iecc.com Tue Jul 16 15:05:27 2002 From: virtmach@iecc.com (virtmach@iecc.com) Date: Tue, 16 Jul 2002 15:05:27 +0100 Subject: [virtmach] register vs. stack machines Message-ID: <7099fda8277a891d147f5ad24981eb13@vitanuova.com> i was pointing to the paper because it had been mentioned; i'm not sure that the GC issues are germane to the point under discussion. Return-Path: Received: from punt-2.mail.demon.net by mailstore for rog@vitanuova.com id 1026826952:20:29287:53; Tue, 16 Jul 2002 13:42:32 GMT Received: from tom.iecc.com ([208.31.42.38]) by punt-2.mail.demon.net id aa2122324; 16 Jul 2002 13:42 GMT Received: (qmail 22450 invoked by uid 85); 16 Jul 2002 09:42:17 -0400 Received: (qmail 22436 invoked by alias); 16 Jul 2002 09:42:04 -0400 Received: (qmail 22432 invoked from network); 16 Jul 2002 09:42:03 -0400 Received: from unknown (HELO saturn.hactw) (212.102.229.162) by mail.iecc.com with SMTP; 16 Jul 2002 09:42:03 -0400 Received: by saturn.hactw with Internet Mail Service (5.5.2653.19) id ; Tue, 16 Jul 2002 15:41:47 +0200 Message-ID: From: "Durchholz, Joachim" To: "'virtmach@iecc.com'" Subject: Re: [virtmach] register vs. stack machines Date: Tue, 16 Jul 2002 15:41:46 +0200 MIME-Version: 1.0 X-Mailer: Internet Mail Service (5.5.2653.19) Content-Type: text/plain; charset="iso-8859-1" Precedence: bulk Sender: virtmach-owner@lists.iecc.com Reply-To: virtmach@iecc.com > see: > http://www.cs.bell-labs.com/who/rob/hotchips.html The Dis papers tend to strongly state the advantages of the choices that were made for Dis, instead of presenting the full engineering trade-offs. Which makes them great for evangelisation, but not so great for preparing your own decisions. For example, the cited paper doesn't discuss the disadvantages of reference-counting garbage collection (increased memory traffic to keep the reference counts up-to-date, object reclamation as a possible and unexpected side effect of pointer assignments which makes it difficult to guarantee real-time deadlines). I don't know how far this sloppiness/marketing speak attitude transfers to their discussion of stack vs. register architecture. I'd rate the Dis literature as an interesting data point, but not as an authority. Just my 2c.