OSDev.org

I understand that for most personal computers, a byte is an octet: a collection of 8 bits.
Yet I do not know what a word is, because its definition seems to change depending on where you read about it.

Is it two bytes? inw() dealing with unsigned short comes to mind.

Is it the operand size of the target machine? For instance, 32 bits on a Pentium?

Hi,

http://en.wikipedia.org/wiki/Word_(comp ... hitecture)
Cheers,
Adam

For NASM, a word is 2 bytes. for everything else, a word is the natural size of the processor.

Thank you for the quick replies.

Wikipedia wrote:For example, Microsoft's Windows API maintains the programming language definition of WORD as 16 bits, despite the fact that the API may be used on a 32- or 64-bit x86 processor, where the standard word size would be 32 or 64 bits, respectively. Data structures containing such different sized words refer to them as WORD(16 bits/2 bytes), DWORD(32 bits/4 bytes) and QWORD(64 bits/8 bytes) respectively. A similar phenomenon has developed in Intel's x86 assembly language – because of the support for various sizes (and backward compatibility) in the instruction set, some instruction mnemonics carry "d" or "q" identifiers denoting "double-", "quad-" or "double-quad-", which are in terms of the architecture's original 16-bit word size.

According to the above quotation, saying "word" is ambiguous because it could refer to either the natural word of the machine, or the 16-bit legacy word.

I now wonder how I should rewrite my uint16_t inw(uint16_t); or if I should write multiple variants.

Eh, search the web.

I normally call it native machine words (to avoid confusion by just saying 'word'). I would deeply and truly avoid using any data type called word and just replace it with proper stdint.h macros, size_t, or whatever else is suitable. As an example of how not to do it, see the Windows API and it's useless 'DWORD' datatype. If you are using a sensible ABI, you can use unsigned long to mean machine machine word, this is what Linux does. It's not entirely ideal as I think sizeof(long) will remain constant on 128-bit register machines when they appear. Perhaps size_t or uintptr_t is more suitable.

CocaCola wrote:According to the above quotation, saying "word" is ambiguous because it could refer to either the natural word of the machine, or the 16-bit legacy word.

In practice, this ambiguity rarely arises---not just because of context. The computer architecture term is not used much because it's so fuzzy: Who is to decide what the natural unit of data on some architecture is? It's similiar to saying some CPU is 32- or 64-bit; this gives the listener some insight, but not very much since these terms are also informally defined: What is 32- or 64-bit, really? If you want to carry a conversation with an engineer, you will need to use better words (pun intended).

Here's the history... Once upon a time, x86's words were 16-bit. Without extensibility in mind, Intel, Microsoft, and others started releasing software and documentation using the term "word" to mean contiguous 16-bit quantities. They also derived other terms, such as "doubleword" and "quadword." By the time the 80386 had extended the GPR size to 32 bits (the new CPU word, presumably), it was already too late to change the terminology without causing even more confusion, so linguistic backwards compatibility prevailed. MIPS suffered a similar fate.

CocaCola wrote:I now wonder how I should rewrite my uint16_t inw(uint16_t); or if I should write multiple variants.

C already supports a better, and more portable, abstraction for I/O ports (yours is hardly an abstraction at all). See TR 18037 (updated by N1351 and N1386).

A collection of letters.