[C] Temporary Register Allocation
Author
The compiler has the same compile-time constant, and can be changed just as easily; if necessary, the constant could be changed to a simple variable. So, the only solution would be to have a static register count?
Quote:Original post by EctaraThat is one approach.
So, the only solution would be to have a static register count?
The other is proposed above. Use a VM(2) with fixed register count which emits VM(1)-specific instruction set.
This is how JVM and most others work. Bytecode is fixed (in this case it would be 256 registers) but it's translated into actual hardware on the fly, or is just interpreted.
At which point you might just as well define that VM(1) has fixed 256 registers, and it's up to VM(1) implementation to do whatever it needs to do to actually run such code. This is, coincidentally, how today's x86 CPUs work. The "VM" is microcode which emulates various bits of functionality which have long become obsolete or which are not ideal for raw implementation.
Even more, IIRC, most of today's x86 CPUs are implemented in microcode, which allows certain patches to be applied later to avoid issues such as FDIV bug.
The whole point of virtualization is to pretend that hardware has certain features that it really does not, and VM emulates or masks them.
In systems architecture, the entire point of a register is that you have a known number of fast-access slots to store data in; if you need a variable number of slots, you use a stack or just access memory directly off the bus. Registers exist for two reasons: speed of access, and known quantities. They're there so that you know exactly how many items of data you can access quickly and how many you need to relegate to the memory system.
What you're doing is really totally counter to that. Why have a variable number of registers? As soon as your compiler can't rely on the register count, it has to do things like ask for available registers, invoke different code paths dependent on the number of registers available, and so on. Essentially you've removed both advantages of having registers in the first place: you don't know how many there are, so you can't schedule your most-often-accessed data into them; and you don't have any speed, because you have to ask the processing system (VM/etc.) what's there.
Worse, you have to store multiple code paths in your compiled binaries so that you can handle various situations; suppose you have a block of code that compiles very optimally to use 10 registers, but you don't know if you might be running on a VM instance with only 8. Now you have to have your compiler store a 10-register version and a less-than-10-register version so that you can use the optimal edition when the VM is available, versus the less optimal edition when the registers aren't there.
So in a nutshell: you're going against the entire purpose of registers here. I really don't see any possible benefit to having a variable register count in your architecture. Just set a static number and be done with it. If your compiler's register scheduling algorithm is robust, and your bytecode design is solid, and your VM is equally robust, you can simply tweak the register count to see what gets the best results, and then lock it down once you have a number to work with.
But this whole "uncertain architecture" thing just doesn't make sense. It's like trying to design a transmission when you don't know if you are driving one wheel (motorcycle) or four (heavy-duty truck).
What you're doing is really totally counter to that. Why have a variable number of registers? As soon as your compiler can't rely on the register count, it has to do things like ask for available registers, invoke different code paths dependent on the number of registers available, and so on. Essentially you've removed both advantages of having registers in the first place: you don't know how many there are, so you can't schedule your most-often-accessed data into them; and you don't have any speed, because you have to ask the processing system (VM/etc.) what's there.
Worse, you have to store multiple code paths in your compiled binaries so that you can handle various situations; suppose you have a block of code that compiles very optimally to use 10 registers, but you don't know if you might be running on a VM instance with only 8. Now you have to have your compiler store a 10-register version and a less-than-10-register version so that you can use the optimal edition when the VM is available, versus the less optimal edition when the registers aren't there.
So in a nutshell: you're going against the entire purpose of registers here. I really don't see any possible benefit to having a variable register count in your architecture. Just set a static number and be done with it. If your compiler's register scheduling algorithm is robust, and your bytecode design is solid, and your VM is equally robust, you can simply tweak the register count to see what gets the best results, and then lock it down once you have a number to work with.
But this whole "uncertain architecture" thing just doesn't make sense. It's like trying to design a transmission when you don't know if you are driving one wheel (motorcycle) or four (heavy-duty truck).
This topic is closed to new replies.
Advertisement
Popular Topics
Advertisement
