Modern x86 processors have at least 512K of L2 cache. There are applications which would fit entirely into this amount of memory. Can you run these chips with no RAM attached? If so, is there a way to do it that eliminates the writeback timing penalty when the CPU attempts to maintain RAM coherency?

I don't have a specific application in mind, it's just idle curiosity. I'm certain that somewhere there is a niche application where this would be useful though.


Yes you can. By faking reads from consecutive (non-existant) physical memory locations, you set the tags in the cache. Then you switch off further filling of the cachelines and enter writeback, thus confining reads/writes to the cache and it will behave as a normal RAM.

Some of the bios-replacement projects do this because then you can spend much more code on the chipset and chipset memory controller setup, so you can write it in C for example.

This practice is widely used for embedded-class CPUs as well for handling bootloaders. The methods to turn the cache into a RAM-like mode vary a bit.

For a brief low-level introduction you can check out this presentation.

Note that as others have pointed out you still need to load the boot-code from somewhere obviously.

  • \$\begingroup\$ In fact, I think pretty much all modern BIOSes use this and pretty much all modern x86 CPUs has official support for it for that reason. \$\endgroup\$ – Yuhong Bao Apr 28 '13 at 2:41

When the CPU comes out of reset, cache is turned off. The BIOS is what initially configures and clears out the cache. So no, you can't run it RAM-less because there is no RAM to boot the thing up in the first place.

  • 1
    \$\begingroup\$ Couldn't the first few instructions from ROM initialize and turn on the cache, without using RAM? \$\endgroup\$ – Mark Ransom Jul 7 '11 at 20:43
  • 1
    \$\begingroup\$ @Mark Ransom Modern Intel processors (and many other CPU's) use Serial Flash to store the BIOS. But it cannot execute code from serial flash. Instead the CPU copies this serial flash to RAM and then executes it. \$\endgroup\$ – user3624 Jul 7 '11 at 20:57
  • \$\begingroup\$ Hah, my ignorance is showing - you can see how many years it's been since I've done hardware design. So the CPU copies the flash automatically before the first instruction is executed? That would be a nasty chicken/egg problem to overcome. \$\endgroup\$ – Mark Ransom Jul 7 '11 at 21:05
  • \$\begingroup\$ @David Strictly speaking it's not 'serial' flash but 'Firmware Hub'. This differs from 'serial' in that it transfers 4 bits at a time instead of 1. \$\endgroup\$ – Majenko Jul 7 '11 at 21:07
  • 1
    \$\begingroup\$ @Mark Ransom There are many CPU's/MCU's/DSP's that will boot over a serial link (Serial Flash, RS-232, SPI, etc.). They all accomplish this by having a small ROM inside the CPU that it boots from, and that code will load the "real" code from wherever. Running a RAM-Less system could, in theory, be possible by having Intel modify this code to use the cache instead of external RAM. But I doubt Intel will do this. \$\endgroup\$ – user3624 Jul 7 '11 at 21:20

I don't know how accurate this is, but these are my thoughts:

I don't think there is any way you can get programmatic access to the cache. You cannot guarantee from one instruction to the next what would be in the cache, and where it would be located, so you cannot use it reliably as RAM even if you could access it directly.

You could run an x86 without RAM, but you wouldn't be able to get it to do very much useful. You'd be restricted to purely using the internal registers for data storage.

  • 2
    \$\begingroup\$ The cacheline fill and flush protocols are thoroughly documented and configurable in most CPUs including the x86. Cacheline contents is not flushed in a random way between instructions. See my answer on how you typically set it up to behave as linear RAM. \$\endgroup\$ – Bjorn Wesen Jul 7 '11 at 23:03
  • \$\begingroup\$ I've written a hex loader utility for an 80x86 clone which would work correctly without any RAM; IIRC, I implemented a one-level call stack using SP to hold return address. Since the ROM was on the same bus as the RAM, it wasn't terribly likely that there'd be a problem that would let the ROM work when the RAM didn't, but in such a case the loader could diagnose the problem. On some other micros with external code buses but a small amount of internal code space, being able to run code on a system with a broken bus was a useful diagnostic tool. \$\endgroup\$ – supercat Aug 1 '11 at 17:44
  • \$\begingroup\$ @I could be mistaken but is RAM not for binary code and for read and writes by the processor ? \$\endgroup\$ – Victor Mehta May 27 '16 at 1:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.