when i write a program in assembly and i define a variable of "word" size.....is it truly the natural word size of my processor? for example on an i7 64bit processor will it be the size of 64bits.....or will it be defined as how microsoft defines the size of a words "A WORD is a 16-bit unsigned integer" ?
Posted on 2011-07-11 11:25:31 by dougfunny
As you already demonstrated, it entirely depends on the context... and the x86 makes it even more complex because of the co-existence of different operating modes.

Even for an x86-64 processor, some definitions for a word may mean 16-bit, 32-bit or 64-bit.

x86 assembly language, as a general/de-facto notation, defines a WORD to be 16-bits.

So no, a word-sized data type in x86 assembly language generally will not be the natural word size of your processor, but it may be the natural word size of the operating mode (e.g. 16-bit Real Mode) that your processor is currently in.
Posted on 2011-07-11 11:57:49 by SpooK
Posted on 2011-07-11 12:02:42 by SpooK
I think the short version is just this:
On the original 8086, a word was 16-bit, the natural word size of the processor.

Since all x86 processors since have remained backward-compatible, the definition of 'word' remained the same, to avoid ambiguities.
Posted on 2011-07-11 15:59:00 by Scali
As SpooK already said, it depends on context; when speaking assembly with x86 (assembly) programmers, 'word' will usually mean a 16-bit quantity (but there's probably some of the gnu guys who'll insist otherwise).

When reading compiler theory and whatnot, a term like 'machine word' will usually mean the native size... and to confuse matters even further, on x86, 'native size' depends on the mode you're running in, not just your CPU. An x64 CPU can run in 16-bit real and protected modes, 32bit protected mode, and 64bit (long) protected mode.
Posted on 2011-07-13 17:06:11 by f0dder
or 32 bit real mode!

okay, okay, i'm leaving :)

btw, never looked much into x86-64.
I wonder if there exists the possibility of unreal style full 64 bit mode, i mean, no paging, no protection, no tasks, 64b data seg and 64b code and stack segs.
Posted on 2011-07-16 16:05:39 by HeLLoWorld

When reading compiler theory and whatnot, a term like 'machine word' will usually mean the native size... and to confuse matters even further, on x86, 'native size' depends on the mode you're running in, not just your CPU. An x64 CPU can run in 16-bit real and protected modes, 32bit protected mode, and 64bit (long) protected mode.


I guess that depends on your meaning of the word 'native'.
I'd say that for a 64-bit capable CPU, the 'native' mode is 64-bit, because I believe that the original meaning of the term 'word' is to refer to hardware capabilities, so you need to look at ALU and register levels, not the actual execution environments that the CPU may offer.
Posted on 2011-07-16 16:56:43 by Scali

I wonder if there exists the possibility of unreal style full 64 bit mode, i mean, no paging, no protection, no tasks, 64b data seg and 64b code and stack segs.


Paging is a prerequisite to enter 64-bit Long Mode, my best guess is due to the 52-bit physical address space limitation of the architecture (perhaps to save on design complexity?) and the variable/canonical virtual address space (scalable upgrade path) that may approach full 64-bit some day.

None-the-less, it would be interesting to know if a true flat/physical 64-bit mode is feasible within the x86-64 architecture... even if the address space was truncated to 52-bit. My guess is no, as the chances are great that we would have seen it in action by now if it were possible.

The closest way to achieve this is via identity mapping, which should be more than feasible with 2MB and 1GB pages, but speaks nothing about the caches and whatnot.
Posted on 2011-07-16 18:13:29 by SpooK