Hcfyk

The answer you reference describes benefits of 64-bit over 32-bit. As far as what's actually different about the program itself, it depends on your perspective.

Generally speaking, the program source code does not have to be different at all. Most programs can be written so that they compile perfectly well as either 32-bit or 64-bit programs, as controlled by appropriate choice of compiler and / or compiler options. There is often some impact on the source, however, in that a (C) compiler targeting 64-bit may choose to define its types differently. In particular, long int is ubiquitously 32 bits wide on 32-bit platforms, but it is 64 bits wide on many (but not all) 64-bit platforms. This can be a source of bugs in code that makes unwarranted assumptions about such details.

The main differences are all in the binary. 64-bit programs make use of the full instruction sets of their 64-bit target CPUs, which invariably contain instructions that 32-bit counterpart CPUs do not contain. They will use registers that 32-bit counterpart CPUs do not have. They will use function-call conventions appropriate for their target CPU, which often means passing more arguments in registers than 32-bit programs do. Use of these and other facilities of 64-bit CPUs affords functional advantages such as the ability to use more memory and (sometimes) improved performance.

A program runs on top of a given architecture (arch, or ISA), which is implemented by processors. Typically, an architecture defines a "main" word size, which is the size most of the registers and operations on those registers run (although you can design architectures that work differently). This is usually called the "native" word size, although an architecture may allow operations using different sized registers.

Further, processors use memory, and need to address that memory somehow -- this means operating with those addresses. Therefore, the addresses are typically able to be stored and manipulated like any other number, which means you have registers capable of holding them. Although it is not required that those registers to match the word size nor it is required that an address is computed out of a single register, in some architectures this is the case.

Throughout history, there have been many architectures of different word sizes, even weird ones. Nowadays, you can easily find processors around you that are not just 32-bit and 64-bit, but also e.g. 8-bit and 16-bit (typically in embedded devices). In the typical desktop computer, you are using x86 or x64, which are 32-bit and 64-bit respectively.

Therefore, when you say that a program is 32-bit or 64-bit, you are referring to a particular architecture. In the popular desktop scenario, you are referring to x86 vs. x64. There are many questions, articles and books discussing the differences between the two.

Now, a final note: for compatibility reasons, x64 processors can operate in different modes, one of which is capable of running the 32-bit code from x86. This means that if your computer is x64 (likely) and if your operating system has support for it (also likely, e.g. Windows 64-bit), it can still run programs compiled for x86.

Using software like Word/Excel/etc, the installers have the option for a 32bit or a 64bit installation. What is the difference?

This depends on the CPU used:

On SPARC CPUs, the difference between "32-bit" and "64-bit" programs is exactly what you think:

64-bit programs use additional operations that are not supported by 32-bit SPARC CPUs. On the other hand the Solaris or Linux operating system places the data accessed by 64-bit programs in memory areas which can only be accessed using 64-bit instructions. This means that a 64-bit program even MUST use instructions not supported by 32-bit CPUs.

For x86 CPUs this is different:

Modern x86 CPUs have different operating modes and they can execute different types of code. In the different modes, they can execute 16-, 32- or 64-bit code.

In 16-, 32- and 64-bit code, the CPU interprets the bytes differently:

The bytes (hexadecimal) b8 4e 61 bc 00 c3 would be interpreted as:

mov    eax,0xbc614e

ret

... in 32-bit code and as:

mov    ax,0x614e

mov    sp,0xc300

... in 16 bit code.

The bytes in the EXE file of the "64-bit installation" and of the "32-bit installation" must be interpreted differently by the CPU.

And a 64 bit program would make efforts to align instruction sets with 64 bit word sizes.

16-bit code (see above) can access 32-bit registers when the CPU is not a 16-bit CPU.

So a "16-bit program" can access 32-bit registers on a 32- or 64-bit x86 CPU.

mentions that word size refers to the bit size of a processor register

Generally yes (though there are some exceptions/complications)

• which I take to mean the number of bits that a computer processor operates on / i.e. the smallest 'indivisible' amount of bits that a processor operates on.

No, most processor architectures can work on values smaller than their native word size. A better (but not perfect) definition would be the largest piece of data that the processor can process (through the main integer datapath) as a single unit.

In general on modern 32-bit and 64-bit systems pointers are the same size as the word size, though on many 64-bit systems not all bits of said pointer are actually usable. It is possible to have a memory model where addressable memory is greater than the system's native word size and it was common to do so in the 8-bit and 16-bit eras, but it has fallen out of favour since the introduction of 32-bit CPUs.

Since the computer architecture is fixed

While the physical architecture is of course fixed, many processors have multiple operating modes with different instructions and registers available to the programmer. In 64-bit mode, the full features of the CPU are available, in 32-bit mode, the processor presents a backwards compatible interface which limits the features and the address space. The modes are sufficiently different that code must be compiled for a particular mode.

As a general rule, an OS running in 64-bit mode can support applications running in 32-bit mode but not vice-versa.

So a 32-bit application runs in 32-bit mode on either a 32-bit processor running a 32-bit OS, a 64-bit processor running a 32-bit OS or a 64-bit processor running a 64-bit OS.

A 64-bit application on the other hand normally runs only on a 64-bit processor running a 64-bit OS.

The information you have is a good part of the picture, but not all of it. I'm not a processor expert, so there are likely some details that my answer will be missing.

The 32 bit vs 64 bit is related to the processor architecture. An increase in word size does a few things:

• Larger word size enables more instructions to be defined. For instance, and 8-bit processor that does a single load instruction can only have 256 total instructions, where a larger word size allows more instructions to be defined in the processors micro-code. Obviously, there is a limit to how many truly useful instructions are defined.


• More data can be processed with a single instruction cycle as there are more bits available. This speeds up execution.


• Like you stated, it also allows access to a larger memory space without having to do things like multiple address cycles, or multiplexing high/low data words.

When the processor architecture moves from 32-bit to 64-bit, the chip manufacturer will likely maintain compatibility with the previous instruction set, so that all the software that was developed previously will still run on the new architecture. When you target the 64-bit architecture, the compiler will have new instructions available and memory addressing schemes with which to process data more efficiently.

Short answer: This is a convention based solely on the width of the underlying data bus

An n-bit program is a program that is optimized for an n-bit CPU. Said otherwise a 64-bit program is a binary program compiled for a 64 bit CPU. A 64 bit CPU, in turn, is one taking advantage of a 64-bit data bus for the exchange of data between CPU and memory.

That's as simple, but you can read more below.

The definition actually redirects to understanding what is a 32/64 bit CPU, indirectly to what is a 32/64 bit operating system, and how compilers optimize binaries for a given architecture.

Optimization here encompasses the format of the binary itself. 32 bit and 64-bit binaries for a given OS, e.g. a Windows binary, have different formats. However, a given 64 bit OS, e.g. Windows 64, will be able to read and launch a 32-bit binary file written for the 32-bit version and a 32-bit wide data bus.

32/64 bit CPU, first definition

The CPU can store/recall a certain quantity of data in memory in a single instruction. A 32-bit CPU can transfer 4 bytes (32 bits) at once and a 64-bit CPU can transfer 8 bytes (64 bits) at once. So "32/64 bit" prefix comes from the quantity of RAM transferred in a single read/write cycle.

This quantity impacts the execution time: The fewer transfer cycles are required, the less the CPU waits for the memory, the program executes faster. It's like carrying a large quantity of water with a small or a large bucket.

The size of the bucket (the number of bits used for data transfer) is used to indicate how efficient the architecture is, hence for the same CPU, a 32-bit application is less efficient than a 64-bit application.

32/64 bit CPU, technical definition

Obviously, the RAM and the CPU must be both able to manage a 32/64-bit data transfer, which in turn determines the number of wires used to connect the CPU to the RAM (system bus). 32/64 bit is actually the number of wires/tracks composing the data bus (usually named the bus "width").

^{(Wikipedia: System bus - The data bus width determines the prefix 32/64 bit for a CPU, a program, an OS, ...)}

(Another bus is the address bus, which is usually wider, but the address bus width is irrelevant in naming a CPU as 32 or 64 bit CPU. This address bus width determines the total quantity of RAM which can be reached / "addressed" by the CPU, e.g. 2 GB or 32 GB. As for the control bus, it is a small bus used to synchronize everything connected to the data bus, in particular, it indicates when the data bus is stable and ready to be sampled in a data transfer operation).

When bits are transferred between the CPU and the RAM, the voltage on the different copper tracks of the data bus must be stable prior to reading data on the bus, else one or more bit values would be wrong. It takes less time to stabilize 8 bits than 64 bits, so increasing the data bus width is not without problems to solve.

32/64 bit program: A compiler matter

Programs don't always need to transfer 4 bytes (32-bit data bus) or 8 bytes (64-bit data bus), so they use different instructions to read 1 byte, 2 bytes, 4 bytes, and 8 bits, for performance reasons.

Binaries (native assembly language programs) are written either with the 32-bit architecture in mind, or the 64-bit architecture, and the associated instruction set. So the name 32/64 bit program.

The choice of the target architecture is a matter of compiler/compiler options used when converting the source program into a binary. Most compilers are able to produce a 32 bit or a 64 binary from the same source program. That's why you'll find both versions of an application when downloading your preferred program or tool.

However, most programs rely on ready-made libraries written by other programmers (e.g. a video editing program may use FFmpeg library). To produce a fully 64-bit application, the compiler (actually the link editor, but let's keep it simple) needs to access a 64-bit version of any library used, which may not be possible.

This also applies to operating systems themselves, as an OS is just a suite of individual programs and libraries. However, an OS is itself a kind of big library for the user programs, acting as a gateway between the computer hardware and the user programs, for efficiency and security reasons. The way OS is written car prevent the user programs to access the full potential of the underlying CPU architecture.

32-bit program compatibility with 64-bit CPU

A 64-bit operating system is able to run a 32-bit binary on a 64-bit architecture, as the 64 bit CPU instruction set is retro-compatible. However, some adjustments are required.

In addition of the data bus width and read/write instructions subset, there are many other differences between 32 bit and 64 bit CPU (register operations, memory caches, data alignment/boundaries, timing, ...).

Running a 32-bit program on a 64-bit architecture:

• is more efficient than running it on an older 32-bit architecture (almost solely due to CPU clock speed improvement compared to older 32/64 bit CPU generations)


• is less efficient than running the same application compiled into a 64-bit binary to take advantage of the 64-bit architecture, in particular, the ability to transfer 64 bits at once from/to memory.
  
  When compiling a source into a 32-bit binary, the compiler will still use small buckets, instead of the larger available with the 64-bit data bus. This has the largest impact on execution speed, compared to the same application compiled to use large buckets.

For information, the applications compiled into 16 bit Windows binaries (earlier versions of Windows running on 80-286 CPU with a 16-bit data bus) are not fully supported anymore, though there is still a possibility on Windows 10 to activate NTVDM.

The case of .NET, Java and other interpreted "byte-code"

While until recent years, compilers were used to translate a source program (e.g. a C++ source) into a machine language program, this method is now in regression.

The main problem is that machine language for some CPU is not the same than for another (think about differences between a smartphone using an ARM chip and a server using an Intel chip). You definitely can't use the same binary on both hardware, they are not talking the same language, and even if this were possible it would be inefficient on both machines due to the huge differences in how they work.

The current idea is to use an intermediate representation (IR) of the instructions, derived from the source. Java (Sun, sadly now Oracle) and IL (Microsoft) are such intermediate representations. The same IR file can be used on any OS supporting the IR.

Once the OS opens the file, it performs the final compilation into the "local" machine language understood by the actual CPU and taking into account the final architecture on which to run the program. For example, for Microsoft .NET, the universal version is executed by a CoreCLR virtual machine located on the final computer. There is usually no notion of data bus width in such intermediate languages, hence less and less application will have this n-bit prefix.

However we cannot forget the actual architecture, so there will be still 32 and 64 bit versions produced for the CoreCLR to optimize the final code, even if the application itself, at the IR level, is not optimized for a given architecture (only one IR version to download and install).