38 ms·
If you created a runtime virtual machine these days, I wouldn't use stacks or registers... address virtual/virtualized memory directly and let the CPU &| compil
by meanonme 8y ago
If you created a runtime virtual machine these days, I wouldn't use stacks or registers... address virtual/virtualized memory directly and let the CPU &| compiler || LLVM sort out register placement... registers are basically another layer in the storage hierarchy, from registers/L0 file all the way down to tape, or eww, hard copy.
- ychen306 8y agoThat would not be a good idea. The amount of analysis effort to analyze something in memory is significantly higher than keeping things in (virtual) registers.
- kccqzy 8y agoSounds like the reverse problem is easier: pretending there are many registers and let the toolchain figure out how to spill them to memory.
- rwmj 8y agoThere was an odd platform in the 80s/90s which did this called Taos. Its virtual machine had up to 5x65535 registers. https://news.ycombinator.com/item?id=9806607 https://news.ycombinator.com/item?id=9806607
- ajross 8y agoThat's the way JVM and .NET work. Dalvik moved the other direction and has explicit registers. Honestly the distinction is mostly a wash. The representations are essentially 1:1, any reasonable optimizer will be able to move stuff around regardless of whether it's a "register" or "local variable".
- FartyMcFarter 8y agoWhy not go all the way with this idea and pretend everything is a hard copy? Your program's statements would all be printing the result of something into paper, or scanning that paper. And then you just let the compiler and CPU figure out which pieces of paper can be put into registers. The answer is that this is too cumbersome and hard to deal with. So is memory, in a smaller way - when things are in memory they can be affected by other threads, the outputs of different instructions can overlap, etc etc.