Why is a word on x86 only 16 bits instead of 32 bits?

The x86 family of CPUs originated in 1978 with the 8086 processor. That architecture defined a WORD as 16 bits (two bytes). A DWORD (double-word) was 32 bits (two words, or 4 bytes), and a QWORD (quad-word) was 64 bits (four words, or 8 bytes).

For backward compatibility with source code, in assembly language and in high-level languages, these data type name definitions have been retained through the generations of the Intel x86 architecture.

The word size of a CPU architecture is typically (but not always) chosen based on the size of the data bus (i.e., the number of bits that can be loaded fro

The x86 family of CPUs originated in 1978 with the 8086 processor. That architecture defined a WORD as 16 bits (two bytes). A DWORD (double-word) was 32 bits (two words, or 4 bytes), and a QWORD (quad-word) was 64 bits (four words, or 8 bytes).

For backward compatibility with source code, in assembly language and in high-level languages, these data type name definitions have been retained through the generations of the Intel x86 architecture.

The word size of a CPU architecture is typically (but not always) chosen based on the size of the data bus (i.e., the number of bits that can be loaded from memory or stored into memory in one shot). The 8086 had a 16-bit external data bus, so that’s what drove its word size. Not long after, the 8088 processor was introduced. It had a 16-bit internal data bus, but had only an 8-bit external data bus. However, the goal was to allow all software written for the 8086 to run on the 8088, even if it took twice as long to move 16 bits of data between the CPU and memory. For compatibility with existing software, the word size remained 16 bits, regardless of the the external data bus width.

To this day, even in the 64-bit Intel world, a WORD remains 16 bits, a DWORD remains 32 bits, and a QWORD remains 64 bits.

You will find similar backward-compatibility artifacts in the assembly languages of other CPU architectures, as well.

When you’re working with 32-bit data, just use DWORD.

Because that was the limit defined by silicon and cost in 1974. If we could have done better, we would have.

The term word has two meanings :

  • A word is two bytes, a byte is eight bits or two nibbles - doubleword and quadword refer to 32 and 64 bits respectively
  • A machine word is the width of the data type that a CPU can process in one instruction

So a word usually means 16 bits regardless of the architecture, unless they say “machine word”

A word is is an ambiguous term but is usually the same size as the register so on a 32 bit x86, 32 bits and 64 bits on a 64 bit x86. Don't be complacent though as this rule does not always follow, one example being a 16 bit processor that had a 20 bit register, and hence word.

The easier way to explain is, because the registers of the x86 are only 16 bits.

so you cannot load any bigger into just one instruction like the simplest instruction to move that is mov ax, #memory position (where memory position is that an address of some memory place)

on x86 this puts that memory position into ax, there is no way to do something bigger in just one instruction.

and if you ask why they make it that size, possible because it was the technology of the time

same as why their predecesors where only 8 bits.

I think there are two basic reasons. The first is a basic cost/benefit analysis.

Cost vs. Benefit

It’s not clear to me that real mode consumes enough chip area that eliminating it would reduce chip area noticeably at all. Back in the MS-DOS days, a fair number of use played around with (and sometimes made real use of) something often called “unreal” or “flat real” mode. You basically switched to protected mode, changed the segment descriptors to allow access to all 4 Gigabytes of address space, and then switched back to real mode. After you did, you still had access to all 4 gigabytes of address

I think there are two basic reasons. The first is a basic cost/benefit analysis.

Cost vs. Benefit

It’s not clear to me that real mode consumes enough chip area that eliminating it would reduce chip area noticeably at all. Back in the MS-DOS days, a fair number of use played around with (and sometimes made real use of) something often called “unreal” or “flat real” mode. You basically switched to protected mode, changed the segment descriptors to allow access to all 4 Gigabytes of address space, and then switched back to real mode. After you did, you still had access to all 4 gigabytes of address space. As such, it appears that real mode is *largely* just a matter of initializing the segment registers to approximate an 8086/8088/80186’s view of memory. There is also a little bit that deals with addressing at boot which changes as soon as you do a far jump. But again, this looks (at least to me) pretty trivial (probably something like a register with a bit-mask that’s changed as soon as you execute a far jump).

So, the benefit would be extremely minimal. On the cost side, the story is somewhat different. A processor that supported only protected mode would require substantial rewriting of essentially every BIOS and the boot portion of essentially every OS. This would probably involve *removing* some code, so the ultimate result would be boot code that was slightly smaller and simpler—but being at all honest, the difference would be pretty small. It doesn’t really take a huge amount of code to switch from real mode to protected mode (or back), so eliminating that code wouldn’t save much.

Market Analysis

The other obvious argument is that it’s been tried and simply didn’t go very far in the market when it was. Back in the 386 era, there was a 80376, which was a 386, but with real-mode support remove. It was designed primarily for embedded systems, where even fairly minor cost savings can be significant,and at that time real mode support would almost inescapably have occupied a larger percentage of the chip area (nowadays, a chip is typically ~75-80% cache, so at best you’re more removing some part of 20–25% that’s actual processor). So while it may not have been exactly a massive flop, the 80376 doesn’t seem to have had much impact on the market either. In fact, even among “computer people”, few seem to be aware that it ever even existed.

Summary

Removing real mode support would appear to provide almost no benefit.

Reference

http://bitsavers.trailing-edge.com/components/intel/80376/240182-004_Intel_80387_High_Performance_32-bit_Embedded_Processor_Data_Sheet_Dec1990.PDF

If you install 64 bit Windows on a system with 4GB of RAM, run benchmarks, format it and then run 32 Bit Windows on that same system, the 64bit version will always run slower.

I have done this several times and is one of the reasons I hate Acer.

Think of 64Bit Windows as a car with a V8 engine, and 32bit Windows as a car with a 4-cylinder.

In order to install that V8 engine, the car needs to be bigger and have more structural integrity to accommodate that big, heavy and powerful engine.

The 4-cylinder doesn’t require as much from the car’s body.

Both cars will get you where you need to go. But, tha

If you install 64 bit Windows on a system with 4GB of RAM, run benchmarks, format it and then run 32 Bit Windows on that same system, the 64bit version will always run slower.

I have done this several times and is one of the reasons I hate Acer.

Think of 64Bit Windows as a car with a V8 engine, and 32bit Windows as a car with a 4-cylinder.

In order to install that V8 engine, the car needs to be bigger and have more structural integrity to accommodate that big, heavy and powerful engine.

The 4-cylinder doesn’t require as much from the car’s body.

Both cars will get you where you need to go. But, that V8 is going to require more fuel when sitting at a traffic light, idling, as opposed to the 4-cylinder.

And that is the same thing with 64Bit Windows vs 32Bit Windows.

64Bit Windows requires more than 1.5–2.0GB of RAM, depending on the system configuration at idle - meaning, you just turned on the pc and left it there. But, 32Bit Windows will run very well on 4GB of RAM, because it can only handle up to 4GB of RAM. Anything more than that, you will require 64bit Windows.

So, on comparable hardware, 64Bit will feel slower, because it requires more resources than the 32Bit version.

But if you want to get the most out of more hardware, the old advice that technicians give (“you need to install more RAM”) is valid and when you cross into more than 4GB of RAM, you will need 64bit Windows.

And that’s why I hate Acer. On their budget builds, I have had numerous clients bring in their machine, complaining that they’re running slow AF. When I check them, they’re running between 2–4GB of RAM and 64 Bit Windows. I usually “downgrade” them to 32Bit Windows and send them on their way. I know people who are still running their machines with 32Bit Windows quite happily. BUT, I always tell them that if they plan on upgrading the RAM, bring it back, because I know that it will require 64bit Windows IF they move past 4GB.

TLDR: If your machine has 4GB of RAM or less, use 32bit Windows. If your machine has more than 4GB of RAM, use 64bit Windows.

answered as: Why didn't Intel introduce the original 8086 as a 32-bit CPU, and had they done so, would there have been a 640k limit and real mode vs protected mode?

Before I begin my answer, I need to be exquisitely clear, while I currently work for Intel, these are my opinions and I was not at Intel at the times discussed.

As Petr, correctly points out the first 32-bit processor was the Intel iAPX 432 - Wikipedia, which was in 1981. This was to be the original follow on after the 80xx series from Intel and used a modern capability-based system and was programming in a high-level language. It is

answered as: Why didn't Intel introduce the original 8086 as a 32-bit CPU, and had they done so, would there have been a 640k limit and real mode vs protected mode?

Before I begin my answer, I need to be exquisitely clear, while I currently work for Intel, these are my opinions and I was not at Intel at the times discussed.

As Petr, correctly points out the first 32-bit processor was the Intel iAPX 432 - Wikipedia, which was in 1981. This was to be the original follow on after the 80xx series from Intel and used a modern capability-based system and was programming in a high-level language. It is a very cool chip, however, it was slow and expensive. But I’m a little ahead of myself.

I’ll not repeat the first part of Tom’s excellent answer which tracts the history of the 8080/8085/8086/8088 processors. Unfortunately, he left out a little about Motorola’s history which explains some of the Intel’s later behavior/design choices to counter the Motorola products in the market place.

As Tom points out the 8-bit register size and 16-bit address space were what the Intel 8080/8085, the Zilog Z80, MOS 6501/6502 and (its sort of sibling) the Motorola MC6800 all used (I’m going to ignore the Moto vs. MOS Tech story for this answer).

The important point is that Intel had a regular cadence and the ‘20-bit’ address space of the 8086/8088 made logical sense for them to follow the ‘16-bit’ addressing of the chips that they and their competitors had all made previously.

What is interesting was Motorola’s strategy at that time (the mid to late 1970s). Compared to the Intel and Zilog chipsets, the MC6800 and MOS6502 were considered a lot easier to both program and to interface hardware too. The other thing to remember is that at the time as these microprocessors are being manufactured and sold, the minicomputers such as DEC’s PDP-11 and the DG Nova were 16-bit systems, although the minis could support an alternate MMU that allowed larger address spaces such as 18/22/24 bits for the PDP-11.

From an ISA standpoint, the Motorola marketing team chose to stay at a mix of 8-bits & 16-bit registers but limited to 16-bits of address in their 1978 processor the MC6809, which was Moto’s follow on to the MC6800. It turns out there was an unofficial, so-called ‘skunk-works’ processor project going on in Austin in the back of one of the Motorola development labs, which had started about a year or so after the official (fully funded) MC6809 work had begun.

This underground project proposed to build a new 16-bit processor as it was designed by a bunch of ex-Schlumberger folks (Les Crudele, Tom Grunner, Nick Trudennick). Remember the logic family and process technology, i.e. the number of gates, etc. was much less than what we have today, but the team thought they could create something like the PDP-11 on a single chip (they had been PDP-11 hackers at Schlumberger and in grad school). This was extremely risky and a lot people did not think that the current technology could support it. Thus, this was not an official project and mostly ignored or not even known about at the highest levels of Moto management.

According to my discussions with Les, the team did not even have a budget for things like getting a mask made. The one mask that did get made was snuck through the system. But what they did do was built a TTL prototype, Nick started to write microcode and Les and friends started to lay the gates in the Motorola process of the time. When they got the TTL system working and the logic guys thought they had a chip, they got one chance to make a mask to prove their point.

The other important part of the story is as they were doing this work, DEC had a lawsuit they would win against Cal-Data for cloning the PDP-11 and the Unibus. So with this experimental architecture, the Moto engineers were very careful to have a different bus and not be exactly like the DEC PDP-11 (A registers and D registers as an example).

As I said, they got one shot at making a chip and it actually worked pretty well with what Intel calls the ‘A-step.’ They made a few of the chips and those parts were given an X-series number and handed to some of their closest partners, such as IBM, Tektronix, HP to play with. My lab at Tektronix was the receiving end and I have written about this elsewhere - the results would become the Magnolia machine.

Famously, when the IBM team from Florida came to Motorola looking for a processor for what would become the PC, Moto marketing brought them the official device, the MC6809. IBM had explained they wanted a 16-bit processor to match the mini’s of the day and Moto famously said — here is the 6809 it can do 16-bit arithmetics. IBM said, “yeah but …. We know about the X68000, we have some of them in Yorktown in Research,” and Moto said - “No, that’s not a product, that’s an experiment.”

The rest is history as they say.

The interesting thing is that between the IBM/PC and other design wins, Intel started to have good success with the 8086 and Motorola was losing market share with the MC6809. So Moto’s management made the late choice to turn the experiment into a committed project, which in the end, would become their most successful processor family (although it was too late for the PC).

Tom mentioned in his answer, that this experimental chip was a 32-bit processor. It actually is not. The natural size of the C ‘int’ data type for the original 68000 is a 16-bits (more in a minute). As I explained in my answer: Clem Cole's answer to What does 32bit and 64bit refer to?

the basic idea is that there are two primary functional units that determine the fundamental CPU size of data functional units and the address units. The computer has a memory which today is broken up into 8-bit bytes.

The processor collects those bytes together into ‘chunks’ and manipulates the bytes inside the processor itself in what are called ‘arithmetic functional units.’ These are the adders, multipliers with the most important of these is what is called a Barrel shifter - Wikipedia.

….

the old Motorola 68000 which was the processor in the original Apple Mac was a 16-bit chip using a 16-bit shifter and arithmetic unit, although all the registers were defined as 32 bits and the external memory bus was 24 bits. Only later, with the 68020 did Motorola make a full 32-bit device.

BTW: another important thing to note about the original chips from all of the vendors in those days, was the lack of an MMU built into the chips. The original 68000 had a separate and optional PDP-11 style base/limit register chip [there is a similarly famous story about Apple and that chip for Lisa and the Mac, but it is not relevant to the answer to the Intel-based question].

So now we can come back the Intel and its follow on to the 8086/8088. As Tom explained, IBM had picked the 8086 device family for the IBM PC. As a follow on to that processor, Intel countered the new Motorola part, with two more, the 80186 and 80286. Besides a larger physical address space, and new built-in MMU was added. They also added new hardware that Tom referred too and the OP asked, real and protected modes, which allowed the code for the earlier 8086/8088 to continue to execute, user/kernel-mode and the like.

As Tom pointed out, both the MC68000 and the 80286 had 24-bits of external physical addressing. And both chips were internally 16-bit processors (i.e. the barrel shifter and basic functional units operated 16-bits at a time).

However, the two teams took two different paths that would have huge differences from a software standpoint. While the processor did everything 16-bits at a time, the Motorola team created linear 32-bit registers, whereas Intel used a trick called ‘segmentation,’ which divided all registers into two pieces, and the high ‘segment’ register and the lower 16-bit “offset” part. This breaks the memory into small 16-bit chunks, called segments which can overlap each other. It turns out that for some programming languages of the day, such as Algol, Pascal, and Fortran, segmentation was not a big deal because they tended to think of data as ‘words’ and could support the chunk idea fairly easily. But other languages, such as C, really preferred a linear byte addressed memory space (in truth, as my compiler friends all tell me it is actually easier for the other languages too, but some of the larger 36-bit systems like the large GE and DEC PDP-10 were also word-oriented so tricks like the one Intel used were not unnatural for compiler writers of the day).

But that single difference in the way memory and data is treated (segmentation vs. linear), had a huge difference in practice, particularly as UNIX and C started to become popular.

The 32-bit, C long data type was a natural data type for the MC68000, although it took two clock ticks to support a 32-bit operation since it was a 16-bit chip inside. The other design choice that Les and Nick did that was important, was a lesson that they had learned from the IBM 360 architecture. The MC68000 only had 24-bits of physical address, but like the IBM architecture, the Moto designers also stored/maintained the upper 8 bits as though they had 32-bits of address space in all the microcode. This meant that like the IBM 360 family, when later chips were produced which (what IBM called models) with more external addresses were designed which actually used those upper 8 bits, the software built for the earlier chips would continue to work unchanged. The result for the programmer is a smooth and linear address space that is not broken into pieces.

At the time, many of thought that Intel had engineered themselves into a corner with the 808x ISA, and there was little they could do about it. But the Intel engineers pulled a remarkable move and in 1985 produced a chip that, like its predecessors, was still segmented, but it supported 40 bits of physical address, which a 32-bit base for the offset. I always laughed because, if you look in the old Intel 386 system software book when it was released, the authors still talked about how great segments were; meanwhile, all the software designers just ran the new 386 chip as a 32-bit linear system as everyone else had done with the Motorola 68000 family.

Finally, Tom made a comment, saying that if the first 80x86 chip had been supplied 32-bit support from the start, it probably would have had memory protection. This is where I disagree a bit with him. The 80286 had an MMU, full protection, et al, so I agree that the Intel design team saw the need for integral MMU before Motorola did, but the trick was not 32-bits, but supporting linear addressing, which was what the MC68000 had that the Intel devices lacked.

As a small postscript, when Motorola created the 68020, they made a full 32-bit chip internally (and a C “int” data type could naturally become a 32-bit value, operating in a single clock tick), but unlike Intel, that device still needed an external MMU chip (Moto would not integrate the MMU on-chip until the 68030). But the point was because the original Motorola device was linear in the addressing, all new chips that followed the 68000 ‘just worked’ from a software standpoint.

to sum up what was said in other answers:

  • x86 is the semi-formal name of the Intel 8086-compatible processors
  • the original 8086 processor had 16-bit instruction and 20-bit RAM addressing
  • for a long time, until they became the mainstay of personal computing, x86 processors would work in hybrid 16-bit / 32-bit modes (Windows 3.11 and Windows 95 ran on a 16-bit kernel with parts of the system running in 32-bit mode); as such, none could really call this x86–32, and the formal name was actually ‘extended 386’.
  • when 64-bit became prevalent, there was another thing that had become prevalent : multicore

to sum up what was said in other answers:

  • x86 is the semi-formal name of the Intel 8086-compatible processors
  • the original 8086 processor had 16-bit instruction and 20-bit RAM addressing
  • for a long time, until they became the mainstay of personal computing, x86 processors would work in hybrid 16-bit / 32-bit modes (Windows 3.11 and Windows 95 ran on a 16-bit kernel with parts of the system running in 32-bit mode); as such, none could really call this x86–32, and the formal name was actually ‘extended 386’.
  • when 64-bit became prevalent, there was another thing that had become prevalent : multicore CPUs. On top of that, the first 64-bit x86-compatible chip was made by AMD, and you needed a “real” protected kernel to run it - exit MS-DOS, welcome Windows NT, and Linux didn’t care.

As such, the first 64-bit x86 code paths where named AMD64.

But Intel couldn’t bear supporting their competitor’s name in their technologies, so they tried to impose EM64T.

Which was awkward, meant nothing and got confusing.

So, after a while, x86–64 became somewhat prevalent, x86–32 appeared when code paths between the two got forked, a few mentions of x86–16 appeared in some remote corners of the Internet (for those few softwares that still had a 16-bit code path for original 8086).

This question is a bit like asking, “What determines that a vehicle’s engine is 4, 6, or 8 cylinder?” The short answer is that the manufacturer determines whether a microprocessor is 8, 16, 32, or 64 bit. Even today, some manufacturers produce microprocessors (and/or microcontrollers) with a variety of bit sizes, including 8-bit products.

In general, an N-bit microprocessor (CPU) has an ALU (Arithmetic Logic Unit), registers, an address bus, or data bus having N bits. Notice that I said or. This is a pretty broad definition, because some CPU architectures have a mixture of internal sizes and mi

This question is a bit like asking, “What determines that a vehicle’s engine is 4, 6, or 8 cylinder?” The short answer is that the manufacturer determines whether a microprocessor is 8, 16, 32, or 64 bit. Even today, some manufacturers produce microprocessors (and/or microcontrollers) with a variety of bit sizes, including 8-bit products.

In general, an N-bit microprocessor (CPU) has an ALU (Arithmetic Logic Unit), registers, an address bus, or data bus having N bits. Notice that I said or. This is a pretty broad definition, because some CPU architectures have a mixture of internal sizes and might use different sizes internally and externally. The size of the data bus has often been used to drive the bitness of the CPU, but that’s not always the case.

Consider the following examples:

  • Zilog Z80 - Considered an 8-bit CPU, it has an 8-bit data bus, 16-bit address bus, and a mix of 8-bit and 16-bit registers.
  • Intel 8086 - Considered a 16-bit CPU, it has a 16-bit data bus, a 20-bit address bus, and 16-bit registers.
  • Intel 8088 - Considered a 16-bit CPU, even though it has only an 8-bit external data bus. Everything else is identical to the 8086. The original IBM PC was based on this CPU.
  • Intel 80386 - Considered a 32-bit CPU, it has a 32-bit data bus, 32-bit address bus, and 32-bit registers.
  • Intel 80386SX - Considered a 32-bit CPU, even though it has only a 16-bit external data bus and a 24-bit external address bus. Everything else is identical to the 80386.

As you can see, the bitness of a CPU is not always based on the size of the external data bus, the size of the external address bus, or the size of the largest registers. It usually has to do with how much data it can move around at a time internally, but that’s not always the case.

Well, there was once a chip called 8086, which was used in a personal computer called IBM PC with a cheaper version called 8088. An updated version of that chip was made and named 80186, but that was not a very common version. An updated, improved version was then made, however, and named 80286. Now, that was a very common chip, particularly because it was used in an IBM PC AT computer.

Later, Intel, which built and marketed the chips 8086, 8088, 80186 and 80286, all of which had a 16-bit architecture, saw the need to design a 32-bit chip to compete with others' similar offerings. It made the n

Well, there was once a chip called 8086, which was used in a personal computer called IBM PC with a cheaper version called 8088. An updated version of that chip was made and named 80186, but that was not a very common version. An updated, improved version was then made, however, and named 80286. Now, that was a very common chip, particularly because it was used in an IBM PC AT computer.

Later, Intel, which built and marketed the chips 8086, 8088, 80186 and 80286, all of which had a 16-bit architecture, saw the need to design a 32-bit chip to compete with others' similar offerings. It made the new chip capable of running software made for the previously listed chips, to take advantage of its incumbent role. Naturally, this new chip was named the 80386 by Intel.

By then a number of computers were using different models of Intel chips, and non-Intel chips were still compatible with Intel chips. So individuals began to refer to them as 80x86.

Intel introduced a new chip after a while, but it wanted to remove the 80, so it was the 486 instead of the 80486. Similarly, individuals dropped the "80" from the "80x86" front, calling this stuff all x86.

And then came AMD, who decided the market needed a 64-bit CPU that to the extent possible, was compatible with the x86 family. They named it the "x86-64" family as a marketing attraction, and they were hugely popular. So much so that Intel ended up following them grudgingly with their own x86-based 64-bit CPU.

Later, since people were lazy, the x86-64 was simply known as the x64.

Hope this answer helped :)