自定义VM中有多少个寄存器？
我正在设计一个自定义虚拟机，并且很好奇我应该使用多少个寄存器。最初，我有 255 个，但我有点担心每次调用函数时将 255 个指针（一整 KB）备份到堆栈或堆上，而其中大多数指针甚至不会被使用。我应该使用多少个寄存器？
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?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（4）
您可能需要查看注册窗口，这是减少“活动”数量的一种方法“寄存器在任何时候都可用，同时仍然在核心中保留大量寄存器。
话虽如此，您可能会发现使用基于堆栈的架构更方便。一些旨在以软件（JVM、CLR、Python 等）实现的主要虚拟机使用堆栈架构。为堆栈编写编译器肯定比为人为限制的寄存器集编写编译器更容易。
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.
这通常取决于您认为需要的数量。我质疑 255 寄存器在实际应用中的用处。
我构建的最后一个寄存器机旨在支持小型编程语言，在进行规划时，我研究了应用程序的类型，我想指导人们使用的设计方法，在设计寄存器时平衡所有这些与性能问题文件。
如果没有更多细节，这不是一个可以轻易回答的问题，但是如果您停下来思考一下您正在尝试做什么，并将其与您认为重要的任何方面进行平衡，您就会得出一个结论一起生活，这可能是有道理的。
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.
无论您选择多少个寄存器，对于大多数子例程来说可能会太多，而对于少数子例程来说可能会太少。 （这只是一个猜测。但是，考虑到编程中有多少东西遵循幂律分布——对对象、模块、类的传入引用，来自对象、模块、类的传出引用，子例程的圈复杂度，子例程的 NPath 复杂度，子例程的 SLOC 长度、对象的生命周期、对象的大小 – 只有合理地假设子例程的寄存器数量也是如此，特别是如果您认为复杂性/长度和数量之间可能存在相关性 。
Parrot VM 找到了一个解决这个难题的非常简单的方法：它们有无限数量的寄存器 显然，这些寄存器不是存储在无限数组中，而是懒惰地为任何单个子例程实现了足够的寄存器。这样，它们就永远不会用完寄存器，也不会浪费任何空间。
Whatever number of registers you choose, you are probably going to have way too many for most subroutines and way too few for a few subroutines. (This is just a guess. However, considering how many things in programming follow a Power Law Distribution – incoming references to objects, modules, classes, outgoing references from objects, modules, classes, cyclomatic complexity of subroutines, NPath complexity of subroutines, SLOC length of subroutines, lifetime of objects, size of objects – it is only reasonable to assume that the same is true for the number of registers for a subroutine, especially if you consider that there is probably a correlation between complexity/length and number of registers.)
The Parrot VM has found quite a simple way out of this conundrum: they have an infinite number of registers. Obviously, those registers aren't stored in an infinite array, rather they lazily materialize just enough registers for any single subroutine. That way, they never run out of registers, and they never waste any space.
对不起各位。我在这件事上犯了一个愚蠢的错误。事实证明，我已经有了一个寄存器向量来优化对堆栈的访问，但我完全忘记了。我没有欺骗它们，而是将状态中的寄存器设置为对堆栈寄存器的引用。现在我需要做的就是专门推动直接推送到寄存器，并以一种高效的方式解决问题。这些寄存器也永远不需要支持，因为它们与功能无关，并且它们将完全按照我的堆栈增长。我只是从未想过我可以将值推入其中而不将等效值推入堆栈。
对于简单的设计概念来说，这绝对是可怕的模板混乱，这让我非常不高兴。想买：静态if和可变参数模板。
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.