How many bits does a WORD contain in 32/64 bit OS respectively?
Anyone has a definite answer?
Someone says that on 32 bit OS a WORD means 16bit,true?
Answer
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.