I'm designing a custom VM and am curious about how many registers I should use. Initially, I had 255, but I'm a little concerned about backing 255 pointers (a whole KB) on to the stack or heap every time I call a function, when most of them won't even be used. How many registers should I use?
+1
A:
This generally depends on how many you think you'll need. I question 255 registers' usefulness in practical applications.
The last register machine I built was aimed at supporting a small programming language, and when mapping things out, I looked at the types of applications, the design methodologies I wanted to guide people to use, balancing all that with performance concerns when designing the register file.
It's not something that can easily be answered without more details, but if you stop and think about what it is you're trying to do, and balance it all out with whatever aspects you find important, you'll come to a conclusion you can live with, and that probably makes sense.
jer
2010-06-01 10:01:30
+4
A:
You might want to look into register windows, which are a way of reducing the number of "active" registers available at any one time, while still keeping a large number of registers in core.
Having said that, you may find that using a stack-based architecture is more convenient. Some major virtual machines intended to be implemented in software (JVM, CLR, Python, etc) use a stack architecture. It's certainly easier to write a compiler for a stack rather than an artificially restricted set of registers.
Greg Hewgill
2010-06-01 10:06:12
AFAIK the Parrot VM is register based. Those are rumored to be more optimizable, but for a first implementation, I'd also go to the stack based architecture.
AProgrammer
2010-06-01 12:11:32
I'm not so sure about "most". Especially if you look at the more modern ones: Lua recently switched from stack-based to register-based, Parrot is register-based, Dalvik (the VM for Android) is register-based, BESEN (the only existing implementation of ECMAScript 5) is register-based, at least one other JavaScript VM is register-based (Nitro, I think? I'm not sure which). And a couple of smaller ones: tinyrb is register-based, RubyGoLightly is register-based, Potion is register-based. The tinypy Python VM is register-based.
Jörg W Mittag
2010-06-01 12:49:06
@AProgrammer: thanks for the info about [Parrot](http://docs.parrot.org/parrot/latest/html/docs/intro.pod.html), I've removed that from the list.
Greg Hewgill
2010-06-01 19:46:03
@Jörg W Mittag: that's interesting. I wonder whether those decisions have been made for performance reasons?
Greg Hewgill
2010-06-01 19:47:26
Dalvik did it for power efficiency, I believe. Lua, Parrot and Nitro/SquirrelFish did it for performance. Potion, tinyrb and tinypy are based on Lua (so, they basically did it because Lua did it) and RubyGoLightly is a Go port of tinyrb, so *it* does it because tinyrb does, which does it because Lua does it. BESEN was written by a guy from the demoscene, who is used to hack CPU registers by hand, maybe he was just trying to transfer his knowledge.
Jörg W Mittag
2010-06-01 21:35:31
A:
Sorry guys. I made a stupid on this one. Turns out that I already had a vector of registers to optimize access to the stack, which I totally forgot about. Instead of duping them, I just set the registers in the state to be a reference to the stack's registers. Now all I need to do is specialize pushing to push straight to a register, and problem solved in a nice efficient fashion. These registers will also never need backing, since there's nothing function-dependent about them, and they'll grow in perfect accordance with my stack. It had just never occurred to me that I could push values into them without pushing an equivalent value into the stack.
The absolutely hideous template mess this is turning into for simple design concepts though is making me extremely unhappy. Want to buy: static if and variadic templates.
DeadMG
2010-06-01 20:06:23