Kdtyjb

Two factors work against your idea:

• the optimal chip production processes for (D)RAM and logic (CPU) are different. Combining both on the same chip leads to compromises, and the result is far less optimal than what can be achieved with separate chips, each built with their own optimal process.




• fast memory (registers) takes more die area and consumes more current (energy) than slow memory. Consequently, when the CPU die is filled with really fast memory (CPU speed), the size of that memory would be nowhere near the GB's you mention. It would be more like the current size of the fastest on-chip caches.

There is insufficient room on the CPU die to fit such a vast amount of memory, current RAM memory relies on DIMMs with multiple chips.

The cost is also an issue, CPU die space is more expensive because of a different manufacturing process.

We currently have CPU caches (memory on the die) for this purpose and they are as big as possible. For most purposes there is no need to make this cache directly addressable.

Here is the die of an i7-5960X with a 20 MB L3 Cache:

source: https://www.anandtech.com/show/8426/the-intel-haswell-e-cpu-review-core-i7-5960x-i7-5930k-i7-5820k-tested

I think the main reason it hasn't been done is because the performance might not be improved as much as one would think.

1) A CPU with a huge register set would probably need to run at a lower clock rate than one with a smalle register set.

a) Memories are essentially very large muxes. The larger the mux the more transistors need to be involved to perform an access. The more transistors you need the slower its going to run either because there is more levels of logic or because there is more transistors connected to the same node (so higher capacitance). There is a reason that memories don't run at the same speed as CPU logic.

b) Implementing that much memory takes a lot of silicon space. It takes time for signals to physically propagate across a larger piece of silicon (routing delay). Just because its larger its unlikely that the device would be able to run at the same speed as a physically smaller CPU.

2) The binary encodings of the machine instructions would get a lot less efficient if you add more registers.
For example if your CPU has 4 registers then you need 2 bits to encode a register selection.
If your CPU has 4 billion 64-bit registers (making 32GB) then you need 32 bits to select each register.

Lets take for example an instruction that computes the logical OR of two registers and stores the result in a third register.

For a CPU having 4 registers you need to reserve 6 bits to encode the operand and destination selections.

For a CPU having 4 billion registers you need ot use 96 bits of operand space to encode the register selections.

Instructions that used to take 16 bits might now take 128 bits. The size of the programs would get a lot larger in terms of memory useage without necessarily adding to their functionality.

One could of course be clever and create some instruction encodings that just use the first X register locations to save bits. But then we are just back to the original register concept.





There are devices that have single cycle memory access but they are micro-controllers or system on a chip and typically have much lower clock rates than the CPU in a PC. They are usually limited to a few 10s to 100s of MHz for single cycle memory access. And even in those cases the memory sizes are usually not GB.

As you add more registers to a CPU, the access time gets slower and slower, because you need logic to pick say one of 1024 register instead of one of 16.

And registers are fast because they are connect directly to various things input and output of ALUs mostly). You can do that with 16 registers, not with 1024.

L1 cache is about as fast as registers, but loses speed because of the issues selecting the right data and transferring data. L1 cache also gets slower with size. And then there is cost, of course. Look at the prices of CPUs with 20MB of L3 cache; that lets you guess how much 64GB of L3 cache would be.

In some ways it depends what you mean by "registers". There are natural trade-offs between:

• Cost - fast access is more expensive


• Heat - fast access produces more heat


• Size - larger blocks of data are slower to access -- so even ignoring cost, you can't scale the registers bigger and expect them to keep the same speed, as you have to go and "get the data" from wherever it is stored on the chip.

One of the first CPUs, the Intel 4004, could be (and often was) used with no RAM, and had no cache, so the CPU you want exists (although it still used a ROM to store the program).

Optimization.

Of course would it be really nice to have an infinite amount of fast registers for storage. But the reason that registers are so fast is the proximity to the other parts of the CPU, so limiting the amount of registers makes them faster. The choice is between a few really fast registers, or more registers that are slower.

Also, registers are built with expensive transistors on the main die. RAM is also very fast but cheaper, but not so cheap that you can implement all your storage needs in RAM.

Even registers are not all the same. It pays off to have a few really fast registers that are closed to the core and can be addressed with just a few bits, and have the other registers a bit slower.

It's the Pareto (17th century) Rule that 80 percent of the work might get done in just 20 percent of the registers, so you better make sure that those are the fastest registers you have.

Between registers and RAM there are several categories of storage in terms of speed and cost and by carefully dimensioning the L1, L2 and L3 caches you can improve the performance to cost ratio of your supercomputer.

We use HD or SSD for Giga/Tera byte storage, but also here we need more storage than we can affort to pay, so some really big archives that are not needed that fast must be offloaded to tape.

Summary: spreading your money over this hierarchy of storage options gives you the most bang for your buck:

registers, L1/2/3 caches, RAM, SSD, HD, Tape

There is no need to make "all memory as registers". Registers are a programming concept and deeply embedded in the processing core. A CPU with a million registers would be ludicrously complicated, and not very efficient. You see, which registers a program uses is actually "hardcoded" in the program. It's the compiler that decides what goes in which register when it compiles the program. With memory you can just dynamically allocate as much as you need. Got a file that is 10MB large? Reserve that much RAM to read it in. You can't do that with registers. You've got to know which ones you are going to use in advance. Registers aren't meant to be used like that.

No, what you really want is RAM - just a fast RAM. RAM that is built with the same technology used in registers and CPU caches. And that... actually exists.

There's this nice old article which was written 12 years ago, but still relevant, I think. I strongly advise you to read it, it explains nicely how the computer memory works. Although it does go into deep detail, so it gets a bit dry.

Anyways, in it the author describes two principal ways of making memory - DRAM and SRAM.

DRAM is based on capacitors - "1" is represented by a charged capacitor and "0" by a discharged capacitor. This is simple and cheap to make and is what RAM is based on today. It's also the source of all its disadvantages and slowness - charging/discharging takes time.

SRAM is based on several transistors and what state they are in. It's vastly faster but also much more complicated to make (wires need to cross for every bit) - hence more expensive. It's also way more power hungry. This is what is used for CPU caches (and I suspect registers).

The thing is - there are devices where the RAM is based on SRAM rather than DRAM. But the price is just through the roof. So more commonly this type of RAM is found in small quantities in specialized devices (like network switches) and as CPU caches.

Btw - there's also a reason why CPU caches are so small (just a few MB). The larger the cache, the longer it takes to find the necessary bytes.

Cost. Fast memory is less dense than slow memory, requiring more die area for a given amount of storage. And die area is expensive.