What's The Relation Between 32/64-Bit Application, Os and Processor

What is the difference between a 32-bit and 64-bit processor?

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.

There are other consequences as well, but these are the two that comes to mind.

What does it mean for a program to be 32 or 64 bit?

Word size is a major difference, but it's not the only one. It tends to define the number of bits a CPU is "rated" for, but word size and overall capability are only loosely related. And overall capability is what matters.

On an Intel or AMD CPU, 32-bit vs. 64-bit software really refers to the mode in which the CPU operates when running it. 32-bit mode has fewer/smaller registers and instructions available, but the most important limitation is the amount of memory available. 32-bit software is generally limited to using between 2GB and just under 4GB of memory.

Each byte of memory has a unique address, which is not very different from each house having a unique postal address. A memory address is just a number that a program can use to find a piece of data again once it has saved it in memory, and each byte of memory has to have an address. If an address is 32 bits, then there are 2^32 possible addresses, and that means 2^32 addressable bytes of memory. On today's Intel/AMD CPUs, the size of a memory address is the same as the size of the registers (although this wasn't always true).

With 32 bit addresses, 4GB (2^32 bytes) can be addressed by the program, however up to half of that space is reserved by the OS. Into the available memory space must fit program code, data, and often also files being accessed. In today's PCs, with many gigabytes of RAM, this fails to take advantage of available memory. That is the main reason why 64-bit has become popular. 64-bit CPUs were available and widely used (typically in 32-bit mode) for several years, until memory sizes larger than 2GB became common, at which point 64-bit mode started to offer real-world advantages and it became popular. 64 bits of memory address space provides 16 exabytes of addressable memory (~18 quintillion bytes), which is more than any current software can use, and certainly no PC has anywhere near that much RAM.

The majority of data used in typical applications, even in 64-bit mode, does not need to be 64-bit and so most of it is still stored in 32-bit (or even smaller) formats. The common ASCII and UTF-8 representations of text use 8-bit data formats. If the program needs to move a large block of text from one place to another in memory, it may try to do it 64 bits at a time, but if it needs to interpret the text, it will probably do it 8 bits at a time. Similarly, 32 bits is a common size for integers (maximum range of +/- 2^31, or approximately +/- 2.1 billion). 2.1 billion is enough range for many uses. Graphics data is usually naturally represented pixel by pixel, and each pixel, usually, contains at most 32 bits of data.

There are disadvantages to using 64-bit data needlessly. 64-bit data takes up more space in memory, and more space in the CPU cache (very fast memory used by the CPU for short-term storage). Memory can only transfer data at a maximum rate, and 64-bit data is twice as big. This can reduce performance if used wastefully. And if it's necessary to support both 32-bit and 64-bit versions of software, using 32-bit values where possible can reduce the differences between the two versions and make development easier (doesn't always work out that way, though).

Prior to 32-bit, the address and word size were usually different (e.g. 16-bit 8086/88 with 20-bit memory addresses but 16-bit registers, or 8-bit 6502 with 16-bit memory addresses, or even early 32-bit ARM with 26-bit addresses). While no programmer ever turned up their nose at better registers, memory space was usually the real driving force for each advancing generation of technology. This is because most programmers rarely work directly with registers, but do work directly with memory, and memory limitations directly cause unpleasantness for the programmer, and in the 32-bit to 64-bit case, for the user as well.

To sum up, while there are real and important technological differences between the various bit sizes, what 32-bit or 64-bit (or 16-bit or 8-bit) really means is simply a collection of capabilities that tend to be associated with CPUs of a particular technological generation, and/or software that takes advantage of those capabilities. Word length is a part of that, but not the only, or necessarily the most important part.

Source: Have been programmer through all these technological eras.

Is bit (32 or 64 bit) of a processor an hardware or software context?

Your ISO image should have said "this ISO image is for 64 bit OSes". (Or hopefully more specifically x86-64 OSes, because x86 isn't the only ISA in the world.)

• A 64-bit kernel (long mode) can run 64-bit user-space (long mode) or 32-bit (compat mode). This can only run on hardware that supports long mode (i.e. 64-bit capable).
• A 32-bit kernel (legacy mode) can only run 32-bit user-space (legacy mode). It can also use vm86 mode to run 16-bit software, but a 64-bit kernel can't (without full virtualization like VirtualBox).

So a 32-bit OS can limit your 64-bit CPU to only ever running in 32-bit mode.

---

AFAIK those bullet points are generally true even outside of x86 (except for the names of the modes), although I'm not sure 64-bit MIPS and PowerPC are even different modes. (i.e. there might have been room in the instruction-set to add 64-bit instructions without changing the meaning of existing instruction encodings the way x86-64 does).

64-bit ARM is a bit like x86-64: AArch64 is a new ISA, but some CPUs that support it can run ARM32 user-space processes (and maybe run ARM32 OSes, too). But some newer Apple chips drop hardware support for 32-bit ARM mode entirely. (AArch64 is a radical enough change that this is worth doing. Unlike AMD64, where AMD was very conservative and barely cleaned up any of x86's warts in terms of things that make it hard to decode and run efficiently. (e.g. shifts leave flags unmodified with count=0). This saves transistors in the decoders and elsewhere because more can be shared with 32-bit mode.)

---

Before 32-bit OSes were fully obsolete, you'd sometimes see an ad for a computer that came with 64-bit Windows vs. 32-bit.

Computer ads like you're talking about are always for systems including an OS, so what the CPU supports is only relevant for the OEM; they can choose to sell a 64-bit capable machine with a 32-bit OS (and actually still do on netbooks, because 64-bit Windows takes more space because it includes libraries for both, while 32-bit Windows has no use for 64-bit libraries).

With Linux, you could do a pure 64-bit install, but few PCs are sold with Linux. And it wouldn't save much space, because a normal Linux install only has a few key 32-bit libraries, not a 2nd copy of everything. Still, a 64-bit install does tend to take more space than a purely 32-bit install. Code-size is usually somewhat larger for x86-64, even when instruction counts are lower.

x86-64 also takes more RAM for programs with pointer-heavy data structures (unless you use an ABI like x32: 32-bit pointers in long mode), which is another reason you still see some low-end computers with 32-bit Windows being sold. A 32-bit OS may actually run better than a 64-bit one with 2GB or less of RAM.

Can 32 bit and 64 bit work together?

In short: You can't link a 32-bit app to a 64-bit library.

You can run a 32-bit application, using 32-bit shared libraries on a 64-bit OS (at least all the popular 32-/64-bit processors such as AMD, Intel and Sparc). But that doesn't involve any libraries.

Longer answer: I was involved (on the outskirts) of some of the teams that designed the 64-bit Linux kernel for x86. There were briefly (compared to the whole project, the discussions lasted quite a few hours) some discussion as to how you could technically make this work. The short summary of this is that in 64-bit there are registers that aren't available in 32-bit. There is also the problem of memory addresses and the extra 32-bits in registers. All of these CAN be solved supposing the library itself "knows" that it's a 32-bit compatible library. But then we basically have a 64-bit library that is written to be a 32-bit library, and we've kind of lost the point.

The "more registers" may not apply to some processors, but the bigger address/bit-range of registers definitely apply to ALL 32- and 64-bit compatible processors. And I'm not aware of any single processor that allows a 32-bit code calling a 64-bit shared library or static library. It just doesn't work unless the code is specifically written to cope with that, which defeats the purpose of having a generic 64-bit library to support 32-bit apps.

Edit:

The above discusses linking one executable unit, e.g. an executable file, a shared library or a static library. That has to be all "one bitness", either 32 or 64 - no mixing.

When a process that talks to another process (e.g. a GUI app which displays status from a non-GUI process that), as long as the two processes use the same protocol [and typically, IPC doesn't allow passing of pointers anyway, so 32-/64-bit conversion isn't as big an issue], you can have one process that is 32-bit and another that is 64-bit.

What is the difference between x86 and x64

x86 is for a 32-bit OS, and x64 is for a 64-bit OS

Differences between 32 and 64-bit .NET (4) applications

Some differences:

1. 32-bit and 64-bit applications can only load DLLs of the same bitness. This can be an issue for managed projects if your platform target is "Any CPU" and you reference or P/Invoke 32-bit native DLLs. The issue arises when your "Any CPU" program runs on a 64-bit machine, since your application runs as a 64-bit process. When it tries to load the 32-bit native DLL dependency, it will throw an exception (BadImageFormatException) and likely crash.

2. There are also filesystem and registry issues. A WOW64 process that tries to read from C:\Program Files will end up getting redirected to C:\Program Files (x86) unless it first disables Windows filesystem redirection (see Wow64DisableWow64FsRedirection). For versions of Windows before Windows 7, there were also registry reflection issues that were similar to the filesystem redirection issues mentioned above. The MSDN article Registry Reflection explains it well.

3. Platform-specific types like IntPtr will have different sizes. This could be an issue in code that assumes a fixed size (serialization, marshaling).

4. There are separate physical directories for the 32- and 64-bit files in the GAC. For my system, they are at C:\Windows\Microsoft.NET\assembly\GAC_32 and C:\Windows\Microsoft.NET\assembly\GAC_64.

5. The virtual address space size of 32- and 64-bit applications is different. For 32-bit applications, the size is either 2 GB (default) or 3 GB (with 4GT enabled). For 64-bit applications, the size is 8 TB. The 32-bit address space can be a limitation for very large applications.

6. A little more obscure, but a lot of interprocess Win32 calls won't work between a 32- and 64-bit process. For example, a 32-bit process can fail when trying to call ReadProcessMemory on a 64-bit process. The same goes for WriteProcessMemory, EnumProcessModules, and a lot of similar methods. This can be seen in C# applications if you try to enumerate the modules of a 64-bit application from a 32-bit application using the System.Diagnostics.Process.Modules API.

How many bits does a WORD contain in 32/64 bit OS respectively?

The concept of a "word" has several meanings. There's 3 meanings embedded in the question.

• The generic term "processor word", in context of CPU architectures
• The "bit size" of software/OS, vs the "bit size" of hardware
• The all-caps term WORD, meaning a 16 bit value - This is a part of the Windows "Win32" C language API

When describing the Win32 WORD type definition, this also comes up:

• The Intel/AMD instruction set concept of a "Word", "Doubleword", and "Quadword"

The generic term "processor word", in context of CPU architectures

In common/generic usage, a "processor word" refers to the size of a processor register. It can also refer to the size of CPU instruction, or the size of a pointer (depending on which exact CPU architecture). In simple cases, a 32 bit processor will have a 32 bit "word" size (and pointer size). A 64 bit processor will have a 64 bit "word" size (and pointer size).

There is a wikipedia article on this "processor word" concept, which details all the generic uses of the term, and the sizes for several current and historical CPU architectures.

"Bit size" of software/OS vs the "bit size" of hardware

A "64 bit" CPU and a "64 bit" OS are necessary in order to run "64 bit" software. This much is probably obvious.

"64 bit software" uses 64 bit instructions (e.g. adding 64 bit numbers together, or copying 64 bits of data from a processor register to RAM at the same time). It also can use a 64 bit pointer size. This means that instead of only being able to use a maximum of 4 Gigabytes of RAM (like "32 bit software"), it can theoretically use about 17 Billion Gigabytes of RAM (16 Exabytes).

A "64 bit" x64/x86 CPU can also run "32 bit" (or even "16 bit") software. It can do this without any changes to the code, and without having to rebuild the software. This is because all the old CPU instructions still exist on new CPUs, and they are backwards compatible.

These concepts aren't strictly the same as the generic concept of a "processor word", but are closely related.

Note: This concept starts getting slightly more complicated when you talk about older and more specialized processors (especially older video game systems), but the question wasn't really about those so I won't go into detail. Those tend to be talked about as "64 bit" or "8 bit" systems, but the truth is a bit more complicated than that. See the "processor word" wiki article I linked above, or an article about the specific system in question.

The question's specific context - WORD, in all-caps

The capitalization and the specific sizes in the question (16 bit for WORD, on a 32 bit OS) imply something different than the generic term "processor word".

In legacy Windows programming (the Win32 API), there is a macro defined called WORD, the size of which is 16 bits. This made sense when processors were 16 bit. However, even when you compile code that contains this macro for a 32 bit or 64 bit target, it will still be 16 bits. A DWORD in the Win32 API is 32 bits, and a QWORD is 64 bits.

This is because Microsoft really tries very hard in their Win32 API to support backwards compatibility without having to do any changes to code. For the most part you can compile the Win32 samples from the Windows 95 era without changes, and they'll still work exactly the same way today.

Microsoft very likely inherited this naming scheme from Intel (and possibly AMD) documentation.

The Intel/AMD instruction set concept of a "Word", "Doubleword", etc

In Intel docs, a "Word" (Win32 WORD) is 16 bits. A "Doubleword" (Win32 DWORD) is 32 bits. A "Quadword" (Win32 QWORD) is 64 bits. The related assembly instruction names also reflect this naming scheme (e.g. MMX Add Packed Integers PADD instructions: PADDW, PADDD, PADDQ).

For some examples, you can check this wikipedia article on the x86 instruction set, or the Intel software development manuals.

This naming scheme doesn't necessarily make sense in terms of the general concept of a "processor word", since these concepts only address a part of a register. However they do make sense in terms of creating a stable programming interface for x86 programs. This is a big part of why you can use "32 bit" (and 16 bit) programs on top of a "64 bit" OS.

is it possible to run 64 bit code in a machine with 32 bit processor?

Is it possible to run 32-bit code in a machine with 64-bit processor?

Yes. This is handled in Windows via WOW64, for example.

Now my question is vice-versa, Is it possible to run 64-bit code in a machine with 32-bit processor?

No. 64bit code would require a 64 bit instruction set, which won't be available on a 32 bit processor.

According this, it is possible to compile 64-bit code on a 32-bit machine.

You can compile code for other architectures, but not execute it. This lets you build code for different platforms than the currently executing platform, but executing it will not work.

---

Related Topics