Anyone has a definite answer?
Someone says that on 32 bit OS a WORD means 16bit,true?
How many bits does a WORD contain in 32/64 bit OS respectively?
The question's specific context -
If by WORD you mean the Win32 type, then WORD is always 16bits, on Win16, Win32 and Win64 platforms. –
Return
@Goddart In what other context? Or do you realy think that open-ended questions have closed-form answers? –
Tong
related / possible duplicates, especially re: the x86 definition of "word = 16-bit" which dates back to 8086, and is now unrelated to modern CPU architectures: What's the size of a QWORD on a 64-bit machine? and Weird data sizes? –
Punic
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.
which is why you probably should be using
#include <stdint.h> and the int16_t type :) –
Darwinism @Qix: If you want integers of size exactly 16 bits, yeah, that's exactly what you'd do. Well,
<cstdint> according to this answer. If you're trying to align to the word size of the processor "for speed's sake" (which is what I am guessing the original intention of the WORD macro was), then you might want to do something else, like the int_fastX_t types. –
Square <cstdint> if you're using C++, <stdint.h> for C. Also, woah, never knew about int_fastX_t types. And they're c89 compliant :D Thanks for that, more reading to do. –
Darwinism Question: What does it mean for a program such as an OS or even a standard application to be 32 bit in terms of its operation? Meaning, what if the program is 32 bits and the OS is 64 bits? What does this mean? –
Headlight
@TeeSee That question is a second question, and is not on (strictly speaking) on topic for Stack Overflow - stackoverflow.com/help/on-topic. It also takes a lot longer to answer than "what does this macro in my system's C library mean?" –
Square
Intel / AMD's current x86 documentation still uses word = 16 bits, dword = 32 bits. Instead of rewriting all the documentation to redefine the meaning of
word when 386 was released, they simply kept the terminology, and there's been no reason to change it since. It's just a technical term with a specific meaning on x86; it's not intended to tell you anything about the microarchitecture or register width or bus width (all of which are different from each other anyway, e.g. 32-bit Pentium has a 64-bit wide bus). It's not "wrong", x86 just isn't a word-oriented ISA like MIPS for example. –
Punic @PeterCordes if you want to link to said documentation, I can add it to the answer. It has been and still seems to be a context-sensitive and architecture specific term. I mentioned the win32 context (which you could argue probably is related to the x86 context), so might make sense to mention the relevant x86 Intel+AMD docs as well. I'd go find the link myself, but you seem to have seen that specific doc before so I suspect you'll find it much faster than me. –
Square
It's all over the place in Intel's software.intel.com/en-us/articles/intel-sdm#three-volume. Presumably somewhere in vol.1 they actually define
word = 16 bits. It's used all over the place in instruction mnemonics and the syntax of most flavours of x86 assembly language, e.g. 8086 cbw sign-extends from byte to word from 8-bit AL into 16-bit AX. AVX2 vpcmpeqw does a SIMD compare of packed 16-bit "word" elements in a vector register. –
Punic Those links are HTML extracts from the vol.2 instruction set manual, where "word" / "16-bit word" and "32-bit dword" are all used. Anyway, obviously Microsoft's
typedef unsigned short WORD came from x86 asm, where MS's assembler (MASM) syntax foo WORD 1, 2, 3 is asm implementation of static uint16_t foo[] = {1,2,3}. For MS's header files, there's even more reason to not change: it would potentially break software / at least cause an ABI incompatibility. BTW, this is not "legacy", at least DWORD is still used. –
Punic Anyway, the degree to which x86 asm mnemonics and asm syntax use "word" everywhere to mean 16 bit, regardless of what mode the CPU is in, make it totally impractical for it to ever change. It's not some obscure thing in some corner of a manual, it's basically everywhere if you ever look at x86 asm. It's just a name for a size, it doesn't "mean" anything other than the original max width of integer registers before 386. x86 doesn't really have a "word size"; it can efficiently operate on 8, 16, 32, or 64-bit integers in the same program, and instructions are variable length from 1B to 15B. –
Punic
@PeterCordes nice! Seems legit. It sounds like you have a nice answer on your hands, if you'd prefer to write it up instead of me hijacking your contributions –
Square
I might at some point, but right now I'm not in the mood to go down the rabbit hole of fully answering this question, especially given that it's not tagged x86... (Although AFAIK x86 is the only modern mainstream case where the claim in the question is actually true; the other modern ISAs started out as 32-bit typically RISC (and do have a "word size") vs. x86 evolving from 16-bit.) Ugh, more than I want to write right now; and there already are SO answers on other questions that explain how nebulous a term "word size" is. –
Punic
@PeterCordes someone finally (after 8 years) downvoted me, so I decided to go ahead and try to expand the answer. Do you think the new version adequately covers the topic? –
Square
Bit improvement, and looks pretty good. I would have put more weight on the concept of "word" as the one size that's used for everything breaking down for 64-bit extensions of 32-bit ISAs. e.g. 64-bit MIPS has "word" = 32-bit, doubleword = 64-bit. e.g.
dadd = doubleword-add instruction. And more importantly the instruction width is still fixed at 32 bits. So we no longer have register width = all other widths in this heavily word-oriented ISA. Word-size != bitness of the ISA. Bitness usually = register width. –
Punic Also, MS Windows
WORD / DWORD / QWORD C types very clearly come from x86 asm documentation conventions. In early (16-bit) Windows days, it wasn't rare to write software in asm, so defining your programming ABI/API in terms that are directly understandable / meaningful in asm makes sense. (This is my guesswork on the history; I've never written a DOS program and mostly only pick up stuff about Windows when it's relevant for portability.) So implying it "doesn't make sense" in this day and age is missing the point, IMO. A WORD is still 16-bit in x86 terminology. –
Punic Your answer reads like it's a bad thing that
WORD = 16 bit. As soon as you fix a term into documentation, and let the ISA evolve, it becomes just a name, not a description with any CPU-architecture relevance. x86 started its evolution with 16-bit 8086, thus WORD = 16-bit. Arguably that was confusing in 32-bit days, but that's no more or less useful than calling it a halfword. These days if you care about how much work you can get done with one instruction, it depends on the mode you're in (64 vs. 32), not the hardware. Or if you use SIMD, 128, 256, or 512-bit. –
Punic x86 doesn't have a word size in the traditional CPU-architecture sense; it's not a word-oriented ISA. Byte / 16-bit / 32-bit / 64-bit loads/stores are all equally efficient (even byte stores can commit to cache without a read-modify-write of the containing word to update ECC bits, for example). Instructions are variable length. Instructions can use any operand-size from 8 to 64 bits, instead of only 32 or 64 for most 64-bit ISAs (i.e. with 64-bit registers). BTW, even Alpha which was 64-bit from the ground up calls its "word size" 32-bit. (It is word-oriented, unlike x86). –
Punic
@PeterCordes it sounds like I'm not going to be able to do this topic expert level justice. I recommend writing an answer for it. Let me know if you do, and I'll up-vote it –
Square
Turns out I did already write an answer like that on Weird data sizes? years ago. Also What's the size of a QWORD on a 64-bit machine?. Also related for x86: What comes after QWORD? –
Punic
@PeterCordes I meant an answer on this question. Your profile picture is too accurate, lol. I wrote this answer a decade ago. I never want to think about it again, haha. Want me to turn it into a community wiki? Or possibly vote for this Q to be merged with the other Qs? –
Square
I'll repost the links in comments under this question where it's better than nothing. And/or I might just edit links into this answer; you don't need to make this community wiki for me to edit. IDK if the questions are close enough to close this as a duplicates of the other; if I ever want to spend more time on it, I'll consider it. –
Punic
There is no definitive answer.
Traditionally the term "word" refers to the size of the processor's registers and main data path. By that definition a "word" would be 32 bit on your 32-bit system and 64-bit on your 64-bit system.
However when processor families were extended to add wider registers/operating modes the manufacturers and users of those processors sometimes continued to use "word" to refer to the word size of the original processor. The same can happen when software is ported from one processor family to another.
Intel x86 documentation uses the term "word"¹ to refer to a 16 bit quantity. This usage bleeds over into software environments that were originally developed for x86 such as the windows API and Borland-style pascal.
On the other hand arm documentation uses the term "word"² to refer to a 32-bit quantity.
¹ see section 4.1 in https://software.intel.com/sites/default/files/managed/a4/60/253665-sdm-vol-1.pdf
² see section A1.4 in https://static.docs.arm.com/ddi0487/db/DDI0487D_b_armv8_arm.pdf
One Word is the size of 16 bit DWord(double word) is double the size of word that is 32 bit when used in programing but...
The name Word in OS is the number shown nexto the OS so if it's saying 64 bit one word (adres for storege) is 64 bit's in this case
So it depends from what angle your looking at it from programing or the OS number
© 2022 - 2024 — McMap. All rights reserved.