How to use 1000 registers (1979) [pdf]
caltechconf.library.caltech.edu
How to use 1000 registers (1979) [pdf]
1–10 of 11 posts
Re: How to use 1000 registers (1979) [pdf]
#2If 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.
Re: How to use 1000 registers (1979) [pdf]
#3If 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.
That 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.
Re: How to use 1000 registers (1979) [pdf]
#4CPUs today have register renaming, but not at the level the programmer sees the machine. At the level where the machine is superscalar, x86 CPUs have far more registers than the few the user sees.
Having many registers at the programmer level turned out to not be all that useful. SPARC machines did that, but it wasn't a huge win.
Re: How to use 1000 registers (1979) [pdf]
#5It's worth noting that modern GPUs have several megabytes of register file. That translates to a ~million registers, if I did the math correctly.
Manageable parallelism is an answer to "how to use a bajillion registers."
Re: How to use 1000 registers (1979) [pdf]
#6If 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.
Sounds like the reverse problem is easier: pretending there are many registers and let the toolchain figure out how to spill them to memory.
Re: How to use 1000 registers (1979) [pdf]
#7If 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.
Sounds like the reverse problem is easier: pretending there are many registers and let the toolchain figure out how to spill them to memory.
There was an odd platform in the 80s/90s which did this called Taos. Its virtual machine had up to 5x65535 registers.
Re: How to use 1000 registers (1979) [pdf]
#8If 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.
That'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".
Re: How to use 1000 registers (1979) [pdf]
#9It's worth noting that modern GPUs have several megabytes of register file. That translates to a ~million registers, if I did the math correctly. Manageable parallelism is an answer to "how to use a bajillion registers."
It's a little different though. GPUs have all those registers because they (1) have a desperate need to optimize around pipeline stalls (because a texture read is many times slower than blocking on main memory) and (2) "know" that they have problem areas appropriate to tiny kernels of code that can work efficiently in fixed size register sets. So they arrange that a "context switch" can be done by changing one index register in a hardware scheduler.
They have a bajillion registers because that works to solve the problem they have, not because they're trying to find out "how to use" them. If you had the same amount of die area and a scalar-ish problem, you'd spend it on a traditional cache hierarchy just like CPUs do.
Re: How to use 1000 registers (1979) [pdf]
#10Any guesses for the typesetting system used to produce this paper? Is that troff or something even older?