Can a CPU (such as the Intel i3/i5/i7/Xeon) with on-chip cache RAM use that as its only functional RAM, without any external memory banks attached?

Or must there be external RAM, and the cache cannot be accessed or used alone?

Modern desktop/server CPUs often have more internal cache RAM than many 1990's computers had in entire system memory, so there should be plenty enough there to run simple code.

CPUs from before cache existed such as the 6502 would be unable to do anything, as the internal CPU RAM only amounted to a few bytes for the address counter and accumulators.

This is not a question of running any sort of modern operating systems, but running simple code programmed into a custom ROM, or hand-entered with a hex input keypad.

  • 1
    \$\begingroup\$ Entirely depends on the CPU and what exactly you mean by "cache" as some CPUs have their ram built in and need no external chips. \$\endgroup\$
    – PlasmaHH
    Commented Jun 19, 2017 at 14:28
  • 42
    \$\begingroup\$ basically, if you include addressable memory in the processor itself, you build what we call a microcontroller. These exist. \$\endgroup\$ Commented Jun 19, 2017 at 14:41
  • 1
    \$\begingroup\$ Who says you need any RAM at all? \$\endgroup\$ Commented Jun 20, 2017 at 6:18
  • 1
    \$\begingroup\$ Depends on how you define "function". I bet an i7 is perfectly capable of producing heat with only a battery connected to it. \$\endgroup\$ Commented Jun 20, 2017 at 15:26
  • 2
    \$\begingroup\$ There are a number of things you can do with just a few registers and no additional RAM. For example, a function generator. \$\endgroup\$ Commented Jun 21, 2017 at 7:29

4 Answers 4


See this extremely detailed account of the PC boot sequence: http://www.drdobbs.com/parallel/booting-an-intel-architecture-system-par/232300699?pgno=2

Since no DRAM is available at this point, code initially operates in a stackless environment. Most modern processors have an internal cache that can be configured as RAM to provide a software stack. Developers must write extremely tight code when using this cache-as-RAM feature because an eviction would be unacceptable to the system at this point in the boot sequence; there is no memory to maintain coherency. That's why processors operate in "No Evict Mode" (NEM) at this point in the boot process, when they are operating on a cache-as-RAM basis. In NEM, a cache-line miss in the processor will not cause an eviction. Developing code with an available software stack is much easier, and initialization code often performs the minimal setup to use a stack even prior to DRAM initialization.

You can observe this by running a PC without RAM: it will play a series of beeps. The program that plays those is run from the BIOS Flash ROM.

I've also seen this behaviour on some ARM processors. There will be configuration registers inside the SoC that allow you to use the cache as RAM early on in the boot sequence, in order to run a program that finds, enumerates and configures the DRAM.

  • 1
    \$\begingroup\$ Let us continue this discussion in chat. \$\endgroup\$
    – user20088
    Commented Jun 20, 2017 at 17:05
  • 3
    \$\begingroup\$ More details on how x86's "cache-as-ram" (CAR) mode works, in an answer which brings it up as a use-case for INVD (when exiting CAR mode, invalidate cache instead of having useless data written to memory, potentially over something valuable). \$\endgroup\$ Commented Jun 23, 2017 at 6:15
  • \$\begingroup\$ What's wrong with evicting when DRAM isn't available? Isn't the problem reading from rather than writing to RAM? \$\endgroup\$
    – user541686
    Commented Jul 27, 2019 at 19:20
  • \$\begingroup\$ @user541686: The eviction itself isn't an immediate problem, but if that cache line wasn't just a tmp buffer then presumably you'll want to read it again later. If it was evicted, the data is gone. If the first access after eviction was a write (e.g. to use it as a tmp buffer again), that might be ok (in a hypothetical case where CAR without no-fill mode was possible, so allocations could happen.) But instead of hardware having per-cache-line controls on whether we can or can't evict (which would cost bits just to support this special case), there's one global control. \$\endgroup\$ Commented May 22, 2020 at 2:24

Generally, the cache memory is not addressable. A program cannot store or retrieve data intentionally from it.

  • 2
    \$\begingroup\$ +1 This is a very astute answer. Cachelines are loaded and retired at will from addressable accesses from main memory, in a nearly random way. \$\endgroup\$ Commented Jun 19, 2017 at 16:33
  • 18
    \$\begingroup\$ Yup, this is why it requires a special mode (as in pjc's answer), or some kind of special trickery. Another option (besides the accepted answer) might be to make the system think it has some DRAM, but actual memory writes just throw away the data, and reads produce all-zeros (or actual data from a ROM for some region of addresses). As long as all loads hit in cache, the system will behave correctly. IDK enough about how x86 boots to know if it's possible to get into 64-bit long mode without needing any real cache-flushes. \$\endgroup\$ Commented Jun 19, 2017 at 19:31
  • 4
    \$\begingroup\$ However, Skylake CPUs with in-package eDRAM cache use it as a memory-side cache (between the memory controller and everything else, unlike in Broadwell), so it can even cache DMA accesses from non-CPU system devices, or CPU loads/stores to "uncacheable" memory regions (which bypass L1/L2/L3). \$\endgroup\$ Commented Jun 19, 2017 at 19:38
  • 3
    \$\begingroup\$ @PeterCordes However the answer isn't "no" just because a special mode is needed - the question is then about whether the special mode exists. \$\endgroup\$ Commented Jun 20, 2017 at 0:05
  • 1
    \$\begingroup\$ The question is - what happens if you use the cache nevertheless and make sure it never misses or gets flushed - it becomes addressable the moment something is written to an address in nonexistent RAM, no? The actual write is dropped on the floor, but the read is served from cache anyway? \$\endgroup\$ Commented Jun 20, 2017 at 14:50

While this does not directly address the processor families specified in the question, the scheme below would work on the earlier x86 processors so, yes it is possible to operate without either RAM or cache, although this approach requires some creative programming skills.

Back in the 1980's I came across a design for a radio receiver that decoded the MSF time signals broadcast in the UK. This design used a Z80 processor and only had a ROM for the program storage. All of the processing and data storage was performed using the internal registers within the processor. This obviously meant that there could be no subroutine calls as there was memory available to hold the stack.

Back then the cost of RAM was high and as this was a hobby project, keeping costs down was important, quite apart from it being an interesting academic exercise. This was also before the days of widely available microcontrollers (an 8751 with eprom cost over £100 IIRC).

  • \$\begingroup\$ Restricting yourself to the data that can be kept in registers really limits the useful functions you can perform. I think the question was more about the cache memory in modern processors. \$\endgroup\$ Commented Jun 20, 2017 at 23:25
  • \$\begingroup\$ Of course it goes without saying that not using RAM limits the functionality that is possible. The application cited shows how much is possible with very limited data storage resources, a radio front end and an LCD display. \$\endgroup\$
    – uɐɪ
    Commented Jun 21, 2017 at 10:18

Typically a CPU will require an external clock. But with that, yes it can.

  • 1
    \$\begingroup\$ It would be appropriate to explain why and thoroughly answer the users question. This answer is on the weak side. \$\endgroup\$
    – Voltage Spike
    Commented Jan 5, 2018 at 16:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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