32-bit Vs 64-bit Processor

[Adah Orhenkowski]

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 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.

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).

Both a 32 and 64 bit OS can run on a 64 bit processor, but the 64 bit OS can use full-power of the 64bit processor (larger registers, more instructions) - in short it can do more work in same time.A 32 bit processor supports only 32 bit Windows OS.

I have been trying to read up on 32-bit and 64-bit processors ( -bit_processing). My understanding is that a 32-bit processor (like x86) has registers 32-bits wide. I'm not sure what that means. So it has special "memory spaces" that can store integer values up to 2^32?

All calculations take place in the registers. When you're adding (or subtracting, or whatever) variables together in your code, they get loaded from memory into the registers (if they're not already there, but while you can declare an infinite number of variables, the number of registers is limited). So, having larger registers allows you to perform "larger" calculations in the same time. Not that this size-difference matters so much in practice when it comes to regular programs (since at least I rarely manipulate values larger than 2^32), but that is how it works.

Also, certain registers are used as pointers into your memory space and hence limits the maximum amount of memory that you can reference. A 32-bit processor can only reference 2^32 bytes (which is about 4 GB of data). A 64-bit processor can manage a whole lot more obviously.

Since microprocessor needs to talk to other parts of computer to get and send data i.e. memory, data bus and video controller etc. so they must also support 64-bit data transfer theoretically. However, for practical reasons such as compatibility and cost, the other parts might still talk to microprocessor in 32 bits. This happened in original IBM PC where its microprocessor 8088 was capable of 16-bit execution while it talked to other parts of computer in 8 bits for the reason of cost and compatibility with existing parts.

Imagine that on a 32 bit computer you need to write 'a' as 'A' i.e. in CAPSLOCK, so the operation only requires 2 bytes while computer will read 4 bytes of data resulting in overhead. This overhead increases in 64 bit computer to 6 bytes. So, 64 bit computers not necessarily be fast all the times.

Processor calls data from Memory i.e. RAM by giving its address to MAR (Memory Address Register). Selector electronics then finds that address in the memory bank and retrieves the data and puts it in MDR (Memory Data Register) This data is recorded in one of the Registers in the Processor for further processing. Thats why size of Data Bus determines the size of Registers in Processor. Now, if my processor has 32 bit register, it can call data of 4 bytes size only, at a time. And if the data size exceeds 32 bits, then it would required two cycles of fetching to have the data in it. This slows down the speed of 32 bit Machine compared to 64 bit, which would complete the operation in ONE fetch cycle only. So, obviosly for the smaller data, it makes no difference if my processors are clocked at the same speed. Again, with 64 bit processor and 64 bit OS, my instructions will be of 64 bit size always... which unnecessarily uses up more memory space.

The definition of 32-bit and 64-bit are not well defined or regulated by any standards body. They are merely intuitive concepts. The 32-bit or 64-bit CPU generally refers to the native word size of the CPU's instruction set architecture (ISA). So what is an ISA and what is a word size?

The old definition of word size would be the number of bits the CPU can compute in one instruction cycle. In modern context the word size is the default size of the registers or size of the registers the basic instruction acts upon (I know I kept a lot of ambiguity in this definition, but it's an intuitive concept across multiple architectures which don't completely match with each other). Example:

Interesting point to note here is that in olden days (70s and 80s) there were CPU architectures whose ALU word size was very different from it's memory access size. Also note that we haven't even dealt with the quirks in non-general purpose instructions.

Contrary to popular belief, x86_64 is not a 64-bit architecture in the truest sense of the word. It is a 32 bit architecture which supports extension instructions which can do 64 bit operations. It also supports a 64-bit logical address size. Intel themselves call this ISA IA32e (IA32 extended, with IA32 being their 32-bit ISA).

The main difference between 32-bit processors and 64-bit processors is the speed they operate. 64-bit processors can come in dual core, quad core, and six core versions for home computing (with eight core versions coming soon). Multiple cores allow for increase processing power and faster computer operation. Software programs that require many calculations to function operate faster on the multi-core 64-bit processors, for the most part. It is important to note that 64-bit computers can still use 32-bit based software programs, even when the Windows operating system is a 64-bit version.

3a8082e126