Can a 32 bit OS run in a 64 bit processor?

Solution 1:

Your question is architecture specific. x64 is essentially an extension to x86 architecture. It supports a 64 bit address space. It provides some new instructions and new registers.

You can run 32-bit x86 Windows on an x64 machine. Note that you can't do this on Itanium 64-bit systems.

Solution 2:

A 64 bit processor can run both 32 and 64 OS (at least an x64 can). A 32 bit processor can run only 32 natively.

The difference is mostly about the size of a Pointer/Reference. On 64 bit machines, you can reference an address in a 64 bit address-range (thus giving you 2^64 bytes of memory). On 32 bit you can only address 2^32 bytes (=4 GB). Now if you look at current computers it is obvious why the world is moving to 64 bit: 32 bit can't easily address all the RAM anymore.

On x64 (AMD/Intel) you have additional benefits of 64 bit. The CPU has more registers and thus allows more efficient code.

On other architectures the differences between 64 and 32 bit are less obvious. For example the Nintendo 64 (remember that?) was a 64 bit machine but most of its code was 32 bit. So in that case 64 bit served more as a marketing trick.

Solution 3:

The currently-accepted answer is generally correct but not specifically so. There really isn't a single thing called a "32-bit CPU" or a ""64-bit CPU" - that's a description that refers to only one small part of the architecture of the CPU. In particular, it references the number of address selection lines between the CPU and the memory, i.e. the so-called address space available for memory operations.

In the days of yore when the CPU when people used to sit down and weave (wrap) the wires between a processor and the memory, you would have had to use either 32 or (theoretically, because it didn't exist at the time) 64 wires between the CPU and the memory controller that would be used to specify which memory address you wanted to access. For example, let's say we have a 2-bit memory architecture: sending 00 would select address 0, 01 would select address 1, 10 would select address 2, and 11 would select address 3. This 2-bit gives us 2^2 bytes of RAM (4 bytes).

If you take a 32-bit CPU and you add on 32 more wires between the CPU and the memory controller so that you're magically able to support more memory, you now have a "64-bit CPU" that can run 32-bit code or 64-bit code. What does this mean and how does this happen? Well, let's take our 2-bit CPU from the earlier part of this answer and add another wire, turning it into a 3-bit CPU, taking us from 4 bytes to 2^3 or 8 bytes of RAM.

Existing "2-byte" code will run, setting the values of the last 2 wires like indicated above (00-11). We'll wire the extra connection to be zero by default, so actually when the 2-byte code runs, when it selects 00, it's actually selecting 000 and when it selects 11 it's actually selecting 011. Easy.

Now a programmer wants to write "native" 3-byte code and writes her software to take advantage of the extra address space. She tells the CPU that she knows what she's doing and that she'll take manual control of the new, extra wires. Her software knows about the extra wire(s) and correctly sends out 000-111, giving her full access to the range of memory supported by the this new CPU architecture.

But that's not how it has to happen. In fact, that's normally not how things happen. When 64-bit CPUs were first introduced (and there were many), they all went with entirely new architectures/designs. They didn't just tack on an additional 32 wires and say "here you go, this is a 64-bit CPU you can use in 32-bit or 64-bit mode," but rather they said "This is our new CPU and it only takes programming in this entirely new machine language, behaves in this entirely new way, solves a bazillion different problems far more elegantly than the old x86/i386 32-bit CPUs ever did, and it's a native 64-bit architecture. Have fun."

That was the story of the Intel Itanium, now famously known as the "Itanic" because of how massively it sank. It was supposed to herald in the new 64-bit era, and it was something to behold. Variable length instructions, huge caches, 64-bit address space, tons of registers, super exciting, super cool, and super hard to convince everyone to recompile or rewrite 20 years of legacy code for. This was back when AMD and Intel were actually competing, and AMD had the brilliant idea of saying "let's forget all this 'solve all the world's problems' business and just add 32 more wires to the i386 and make a 32-bit compatible 64-bit CPU" and the x86_64 CPU architecture was born.

In fact, if you look at the kernel names and sources for major operating systems (Linux, Windows, BSDs, etc) you'll find them littered with references to AMD64 CPUs and AMD64 architecture. AMD came up with a winning strategy to get everyone to switch over to the 64-bit world while preserving compatibility with 32-bit applications, in a way that a 32-bit OS could run on 64-bit hardware or even 32-bit applications could run on a 64-bit OS on 64-bit hardware. Intel followed suite sooner rather than later with their "Intel EM64T" architecture (which was basically identical to AMD64) and x86_64 won out while the Itanic and others like MIPS64 and ALPHA64 were seen no more in the desktop/server market.

tl;dr amd64 aka x86_64 CPUs are designed to be compatible with both 32- and 64-bit kernel and code, but most 64-bit CPUs are decidedly not backwards compatible in the same way. A 32-bit CPU can access at most 4GiB of memory, while a 64-bit CPU can access a stunning 16 EiBs (16 × 1024^6 bytes, or 4 billion times as much memory as 4GiB).