When you first turn on your computer, is the fetch/execute cycle first set up to fetch instructions from the BIOS chip directly to the instruction register in the CPU or is there automatic circuitry set up so that when power on is detected, the instructions in the BIOS chip are automatically loaded into RAM?


I think I found my answer here:

After the reset signal turns off, the CPU begins to operate. Code in RAM cannot be executed since the RAM is empty. The CPU manufacturers pre-program the processor to always begin executing code at address "FFFF:0000" (usually the ROM BIOS) of the ROM.

So the CPU is physically set up to go to fetch and execute the memory address FFFF:0000 in ROM as soon as it's on.

  • 1
    If you find an answer yourself, do post it as an answer below, instead of editing it into the question. (You can accept your own answers after some time.) Sep 15, 2011 at 17:39
  • The book Upgrading and repairing PCs it mentions a memory location the first one the CPU reads from.. And there's a process old CS teachers teach that may still apply, called bootstrapping, as in pulling yourself up by your bootstraps, which is how (the foundation of) an OS gets loaded.
    – barlop
    Sep 15, 2011 at 20:20

2 Answers 2


Most boards used to have an option in the BIOS to configure this behavior. It was typically called shadowing, and it was usually enabled by default. I don't think many boards bother giving you the option these days and just always shadow. The reason is because RAM is faster than ROM, so it speeds things up to copy it to RAM and run it from there.

Note that the copy isn't done by some magic circuitry, it is just done by the bios itself when it starts executing out of ROM initially, it just copies itself to RAM and then continues executing from there.

  • So from what I understand of what you said, upon coming to life, the CPU reads instructions from ROM, which instructions say "Copy all the startup instructions here in ROM to RAM and then set the program counter to such-and-such beginning address in RAM." Is that about right?
    – mring
    Sep 15, 2011 at 17:42
  • @psusi Do you have some links explaining what you're talking about? CPU shadowing isn't getting me much, and how it could be configured. And when are you talking about? When did motherboards have this option? Can you point to any models of motherboard that would've had this option?
    – barlop
    Sep 15, 2011 at 20:15

This is another case where the received folk wisdom on the subject, as unfortunately exemplified by psusi's answer and indeed part of the question, is stuck in the world as it was around 1991, despite the wealth of technical references available explaining how it is now otherwise.

In the world of the late 1980s, the machine firmware — one of two things called "the BIOS" in the world of the IBM PC compatible — was indeed in a ROM chip on the ISA bus; and CPUs did indeed start executing code at physical address 000FFFF0, a location in "conventional memory" accessed via the real mode pointer F000:FFF0 This world is long gone.

(The world that the author of the WWW page that you pointed to, S. Ebrahim Shubbar, erroneously lives in, despite writing in 2002, is even older. CPUs haven't started with the CS:IP combination FFFF:0000 since the 8086. The 80286 changed this to F000:FFF0. But the 80286 world itself is the highly out of date world of the late 1980s that folk wisdom still circulates.)

Your "BIOS chip" is RAM; and your CPU is not 16-bit.

In modern PCs, the machine firmware is held in non-volatile RAM. The NVRAM chip is connected to the LPC bus (or to a dedicated "firmwware hub" interface), and the LPC/FWH bridge in the "chipset" normally disables write cycles to it. "Flashing" the firmware involves setting chipset registers that enable writes to the NVRAM and then writing to the NVRAM. (In the Intel ICH10, for example, the chipset register bit that allows write cycles through is named BIOSWE, "BIOS Write Enable". There are some additional details that I'll skip over here, but that's the gist of it.)

x86 processors haven't begin execution at location 000FFFF0 since the days of the 80286. 32-bit CPUs start up in what is colloquially known as unreal mode. Even though the initial value of the CS register after reset is F000, the segment descriptor associated with that register initially holds FFFF0000 as its base address. So the physical address that initially corresponds to the the 16:16 CS:IP address F000:FFF0 is in fact, and has been since the days of the 80386, FFFFFFF0.

And that's where the machine firmware is principally mapped into physical address space on 32-bit and 64-bit x86 machines. There's a 128KiB window onto the firmware down in the "conventional memory" area, but the NVRAM holding the machine firmware can be up to 16MiB (although this varies by chipset) on modern PCs and is principally mapped into the 16MiB of physical address space immediately below the 4GiB line — i.e. physical addresses FF000000 to FFFFFFFF. (To use the ICH10 as an example again: How much of this address space is mapped to the NVRAM is controlled by a chipset register known as the FWH_DEC_EN, "Firmware Hub Decode Enable", register. The firmware is coded to re-program the FWH_DEC_EN register according to the size of the actual NVRAM chip that is installed on the mainboard. But the top 512KiB of the NVRAM is always mapped, to physical addresses FFF80000 to FFFFFFF, and cannot be disabled.) The code initially executed by the processor immediately after reset lives in the top 64KiB of this 16MiB address range.

As for BIOS ROM shadowing (which is what it's called — quite why barlop thinks that the CPU is being shadowed is a mystery): Yes, access to NVRAM on the LPC bus or the firmware hub still isn't as fast as access to main system (volatile) RAM. But the reasons that shadowing is important greatly diminished with the advents of operating systems such as OS/2 and Windows NT — again in the late 1980s and early 1990s. Real mode operating systems such as MS-DOS, PC-DOS, DR-DOS and so forth were layered on top of I/O functionality provided by the machine firmware. So the firmware's code and read-only data ended up being accessed a lot at run-time. Protected mode operating systems such as OS/2 and Windows NT rely far less upon firmware-provided services at run-time. So the fact that code executing out of the NVRAM, and read-only data in the same, come to the processor more slowly than when shadowed into system RAM is less of a problem than it used to be.

Moreover, what firmware code and data they do rely upon don't necessarily live in the part of NVRAM mapped to the portion of physical address space, the aforementioned 128KiB "conventional memory" window, that is necessarily even shadowable in the first place. Protected mode firmware services don't all need to live below the 1MiB line in physical address space as real mode firmware services do, and some do not. (And of course it would only be possible to do the same trick with the area of physical address space that they do live in if there's at least 4GiB of system RAM.)

Ironically, a more accurate source for information on this than S. Ebrahim Shubbar writing in 2002 is Phil Croucher's book The BIOS Companion from a year before in 2001. M. Croucher observes that Unices, Linux, Windows NT, and "presumably (95/98)" "derive no benefit from shadowing". It's not necessarily entirely no benefit, but it is comparatively very little with respect to the world of people running MS-DOS, PC-DOS, and DR-DOS in real mode on 16-bit 80286 machines in 1989.

  • I'd guess that CPU caches make shadowing even less relevant for BIOS code that has to run during bootup. If the memory regions containing the BIOS are marked cacheable (e.g. in the MTRR in an early stage of booting), loops and frequently-called functions don't need to re-fetch instructions off-chip each time. Unless there's some obstacle to caching for addresses that have to go to the system agent (not DRAM), like there is for MMIO regions. (Mapping MMIO region write-back does not work) Aug 12, 2022 at 21:40
  • Anyway, if caching does work, Intel CPUs since Nehalem (with inclusive L3 cache) might sometimes evict a line from L1i cache / uop-cache if touching a lot of data evicts the line from the unified L3, e.g. during a memory test, but that'd be rare. I'd expect that usually an L3 cache of a few MiB would cover most of the data+code footprint of everything firmware does, maybe even including modern UEFI firmware menus with mouse support. (Although I could also imagine that code+data for fancy menus might get decompressed into RAM so it could take less space in flash memory.) Aug 12, 2022 at 21:44

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .