"Word up, dawg"
Before we can get into what computer programmers refer to as "higher-level" differences (the programming of software), we need to understand some very basic "low-level" differences. Yep, that's right, we're going back to the words, guys.
As I had explained before, a word is a group of information that is processed together. It can be some data from your program, or it might be an instruction that helps alter that data. Sometimes, instructions or data are too big and end up being spread over several words.
So if some instructions are too small and others too large, what decides the right size for a word? Well, some of it is just based on history, while another part of it is based on a very important factor called a processor register
A register is the largest chunk of data that a CPU can process at once, and will be flagged to denote its contents (which takes up a portion of the register). Since a register is the biggest that any data can get and be processed at once, it makes sense to make the size of a word equal. This way, the CPU can always handle the instructions that come at it.
If we have such a neat and tidy explanation there, where does the history come in? Well, historically, the x86 architecture was finalised with a 16-bit word length for the 8086. This meant that every instruction, every piece of data, and every memory address had to be exactly 16 bits.
Unlike today's computers, these more rudimentary processors did not allow for data to be spanned over multiple words, limiting the functions that could be done over the already sluggish clock speeds. If any data was larger than 16 bits it would end up truncated, and smaller would end up crashing (and so would need to be "padded" before processing).
Though processor speed has increased exponentially and the complexity of "bridged" words came into being, processors that comply with the x86 architecture are still required to have 16-bit words. So, in order to cope with our growing need for data space, those nifty computer engineers developed the concept of "segmenting" the pipeline, sending multiple 16-bit words through at once.
It is through this concept that we arrive at the computer terminology today, which we call 32- and 64-bit. A 32-bit processor handles "dwords" (short for double-words), which are actually two 16-bit words processed simultaneously. x86-64 computers function on "qwords," or quad-words - you guessed it, four 16-bit words.
So why maintain such an archaic principle when no processors today really have use for a 16-bit word? It's simple - backwards compatibility. The entire purpose of the x86 architecture was to create a standard that would need to be adhered to. A true
64-bit processor (such as the Itanium or SPARC station) would not know any more how to deal with a 16-bit word than a 16-bit processor could deal with a 64-bit word. The two are simply not compatible.
Ah, the memories
Now that we've touched on CPU registers, we can move on to what everyone thinks of when "64-bit" is spoken aloud: memory. See, one of the most important CPU register types is the memory address
- it is a single
word (note that, it cannot be bridged) that gives the last chunk of data a place to go outside of the CPU.
Sound confusing? It's really not - think of it like going over to someone's house via the train, tube, subway, whatever public transport you fancy. You travel to the station via roads to board the train. But the train you're on rarely gets you exactly where you want to go - sometimes you have to switch. How do you know which station? Or what time? Where do you go while at the station?
These things are what a memory address solves - it tells your data where to be held outside of the CPU until it's time to use it again. Data travels through the bus to the CPU where it gets manipulated, transformed, etc. But one trip through the CPU is rarely all that is necessary - so the data has to get moved to the RAM for future use.
Obviously, this is an over-simplification, but it points to where memory addresses come in. A register is passed along behind the data that tells the CPU where to shove it for a while until it's needed again. The bigger the word, the more possible combinations, or addresses, there can be.
It is this
limitation that people are thinking of when wondering why not all four gigs of RAM are showing up. A 32-bit operating system can only properly address exactly
four gigs, which must be shared between kernel and processes as well as holding further virtual memory addressing. Because of that, Windows XP users can never see the full 4GB of memory - it will always be approximately 3.2GB with Service Pack 2.