21

I have read the following in the x86 Wikipedia page:

The term "x86" came into being because the names of several successors to Intel's 8086 processor end in "86", including the 80186, 80286, 80386 and 80486 processors.

But what does the "x" in "x86" represent? Is it a "variable" that can be something like "801" or "802" or "803" or "804"?

JRN
  • 1,265
  • 8
  • 25
user12302
  • 227
  • 1
  • 2
  • 3
  • 17
    80 _ 86 (nothing in between), 80 1 86, 80 2 86, 80 3 86, 80 4 86...notice the pattern? – user17915 Apr 16 '19 at 00:15
  • 6
    x in IC part numbering is a common way to declare variable ID for the same IC family. Its meaning can be anything in CPU its usually a generation of processor in MCU it might indicate RAM or EEPROM size, for voltage regulators its target voltage etc ... For TTL logic XXYY like 7474 etc the XX means quality (from commercial to military) etc ... so to be sure see datasheet of the part ... To get back to your question Intel CPU/MCU start using a shortcuted marking like x86, x51 its really an shortcut for 8086... and 8051 ... and it sort of stuck with the community too – Spektre Apr 16 '19 at 06:37
  • @bogl heh I did not consider that comment an answer rather some additional info I did not see in the other answers ... and was reluctant to create answer on my own as there are already good answers present ... Should I move into answer? – Spektre Apr 16 '19 at 08:10
  • 1
    Up to you, I have no say here. ;) But to me, it looks very much like an answer. – bogl Apr 16 '19 at 08:15
  • 2
    OT in Retrocomputing ... ;-) – Peter - Reinstate Monica Apr 16 '19 at 14:37
  • How is this about retrocomputing when it's still being used? – pipe Apr 17 '19 at 09:04
  • Note that from the 80286 onwards at least, it is common to omit the 80, so the processors are often called the 286, the 386, the 486. IIRC at some point they were even actual Intel marketing names (though they were probably prefixed with an "i" in that case, so i386, i486...). so the x is just shorthand for 2, 3, 4... – jcaron Apr 18 '19 at 11:54

7 Answers7

49

The term x86 is shorthand for 80x86, which was used to refer to any member of the family 8086 (and also, incidently, 8088), 80186, 80286, etc. Things have since gotten a bit muddled by the fact that while an 80386 had a mode that was compatible with the old architecture, it also introduced some fundamentally new ways of doing things which were shared by the 80486 as well as "named" processors like the Pentium, Pentium Pro, etc., and thus it is sometimes ambiguous whether the name "x86" is used in reference to the architecture that started with the 8086, or the one which had its debut with the 80386.

supercat
  • 35,993
  • 3
  • 63
  • 159
  • "80386...introduced a fundamentally new mode" - Are you referring to protected mode, actually introduced with the 80286? Virtual 8086 mode from the '386? Something else? – Brian H Apr 15 '19 at 20:02
  • 2
    @BrianH: Perhaps "mode" wasn't the best term. Maybe "ways of doing things" is better, though some of those new ways of doing things also included new 32-bit modes. Perhaps the most important point is that compilers targeting code for the 80386 and later processors will tend to do things fundamentally differently from those targeting the 80286 and earlier processors, so they really should be viewed as distinct architectures. – supercat Apr 15 '19 at 20:30
  • 15
    @BrianH, 32-bit protected mode with paging and all that is pretty much fundamentally different from the 16-bit protected mode in the 286. – ilkkachu Apr 15 '19 at 22:16
  • 1
    also, from memory the 286 had to reset to come out of protected mode, while the 386 could change modes at will, so protected mode wasn't widely used until the 386 came along. – Joseph Rogers Apr 16 '19 at 14:15
  • 2
    @JosephRogers: Protected mode was the only way to access more than 1MB of address space, so using storage beyond that region within a DOS program would require switching to protected mode, doing the access, setting a special "the reset handler should reload some registers and resume normal operation" flag, and then asking the keyboard chip to trigger a CPU reset. There was actually an undocumented way code could access upper memory without that rigamarole, but that wasn't discovered until the 80386 came along. It's really a shame that the designers of protected mode failed to recognize... – supercat Apr 16 '19 at 15:15
  • 1
    ...what had been uniquely good about the way real mode segments worked. Had the 80386 protected mode incorporated the better aspects of 8086 segmentation, it would have been practical for a framework like .NET to allow programs to access many gigs of storage using 32-bit object references (which would only take half as much cache space as 64-bit ones). Make segment identifiers 32 bits, with the upper portion selecting a descriptor that contains a base and a scale factor, and the lower containing a scaled offset. That would allow every object to start at address 0 of some segment... – supercat Apr 16 '19 at 15:19
  • @supercat interesting, I didn't know about the undocumented work-around, but 286's with more than 1MB of RAM were rarer than hens teeth (I actually owned two, but both had been heavily upgraded from factory specs), so in practice it wasn't something that came up a lot. – Joseph Rogers Apr 16 '19 at 15:20
  • ...without requiring separate segment descriptors for every object. If the scale factor could be adjusted from 4 to 4096 and the offset field were 28 bits, a segment for holding tiny objects could hold up to 1GiB of objects aligned to 4-byte boundaries, one for small objects could hold 4GiB of objects aligned to 16-byte boundaries, one for medium objects could hold 64GiB of objects at 256-byte boundaries, and each a segment for large objects could hold 256GiB of objects aligned to 1024-byte boundaries. Using only 4 of the 16 segments. – supercat Apr 16 '19 at 15:25
  • @supercat: How would you actually use one of those 2^28 objects-aligned-to-1024-bytes? You'd need a way to address parts of such an object, unless your architecture has instructions that work directly on 8192-bit wide values. – hmakholm left over Monica Apr 16 '19 at 16:04
  • @HenningMakholm: If e.g. the object was 25,000 bytes in size, you'd load a segment register (e.g. es) with the object reference, and then access the object at addresses es:0 to es:24999. The JVM does something a little bit like that when scaled addressing is enabled, but it scales object addresses by a factor of 8 and has to use the scaling address modes to scale object addresses, meaning that accessing element i of an int[] would require computing i*4 in a register (e.g. rbx), having the object reference in another (e.g. rcx), and then using address [rcx*8+rbx]. – supercat Apr 16 '19 at 16:47
  • @supercat "Protected mode was the only way to access more than 1MB of address space", not exactly. Sure at the end of the DOS era, DOS extender became prevalent and every program could be compiled for 32bit and protected mode right away. But before that, a lot of games would use XMS (and even before that EMS), to stay in real mode but use a memory exchanger driver (remember HIMEM.SYS?) to do the trick. You would use a special segment in the 640k-1M region to swap data from the 1M+ RAM region. You call an interrupt with the requested block number in the register and it would get swapped. – werfu Apr 16 '19 at 17:37
  • @werfu: The EMS cards would attach 16KB chunks of RAM to IIRC four 16KB regions within the first 1MB of the processor's address space. – supercat Apr 16 '19 at 18:27
  • @supercat: Ah, I can see I misunderstood your suggestion. So essentially your suggestion is to let a segment register contain a selector plus a floating-point base offset. :-) That would work for Java, but not very well for languages like C that assume you can make a pointer to every subobject of an object you can address in the first place. Whether such an architecture at the time of the 80386 could have prevented the rise of C is an interesting hypothetical ... though my gut feeling is that it would have been too little, too late. – hmakholm left over Monica Apr 16 '19 at 18:53
  • @HenningMakholm: The .NET Framework, like Java, assumes that an "object reference" identifies the start of an object. It also has a "byref" type that behaves more like a pointer and can identify fields within an object, and that would have to be 64 bits, but the vast majority of references used by a program will always identify the start of an object. – supercat Apr 16 '19 at 19:05
  • @JosephRogers the undocumented way to access memory beyond 1MiB on 286s was LOADALL, which was used extensively in OS/2 1 and in some versions of HIMEM.SYS. – Stephen Kitt Apr 17 '19 at 12:48
39

x is meant as wildcard, so this represents all CPUs able to run 8086 compatible code.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 7
    This answer is so far the only answer that addresses the original question about what the "x" represents. – G. Tranter Apr 15 '19 at 21:32
  • 5
    @G.Tranter I agree up to a point. However, if you write "x86" people usually assume you mean compatible with the Intel 80386. i.e. capable of running in 32 bit protected mode. For example, if you compile a C program with gcc -march=x86 the code won't run on an 8086. – JeremyP Apr 16 '19 at 08:47
  • 5
    @JeremyP Exactly my thoughts. Even in the nineties, I don't remember anybody using x86 to mean 80286 or earlier. The gap was too large to put 16-bit systems in the same bag as 32-bit. When x86 appeared as a term I think everyone meant "80386+" by it. – kubanczyk Apr 16 '19 at 09:34
  • 2
    Read the question. I find it's always best to answer the question, not what I think is the question behind the question. The "x" is a wildcard. If you read the whole question, you'd see that the author already understands the architecture part. – G. Tranter Apr 16 '19 at 13:41
  • 1
    The start of x86: Intel 8080 vs Intel 8086? goes into what it means to be an x86 (supporting a mode that's binary compatible with 8086). – Peter Cordes Apr 17 '19 at 00:54
  • 4
    @JeremyP: gcc doesn't have -march=x86. It has -march=i386. See https://godbolt.org/z/xg19XI shows gcc -m32's help for invalid -march=... values, which lists all it supports. If you run x86 gcc with the default -m64, it leaves out arches that only support 32-bit mode. gcc -m16 exists, but still requires 386+ because it mostly just assembles its usual machine code with .code16gcc so instructions with explicit operands get an operand-size and address-size prefix. Anyway, the critical point is that gcc -march never pretended to set the target mode, just ISA extensions within it. – Peter Cordes Apr 17 '19 at 01:00
  • 1
    Semi-related: Why does "i586" refer to Pentium 1, and why does "i686" refer to Pentium Pro? for why modern named instead of numbered CPUs still fit the x86 wildcard pattern with only a small stretch. – Peter Cordes Apr 17 '19 at 01:10
9

In modern usage it also means software which only uses the 32-bit architecture of the earlier 80x86 processors, to distinguish it from 64-bit applications.

Microsoft uses it that way on 64-bit versions of Windows, which have two separate directories called "Program Files" and "Program Files (x86)."

The 32-bit applications will run on 64-bit hardware, but the OS needs to provide the appropriate 32 or 64 bit interface at run-time.

alephzero
  • 6,646
  • 3
  • 29
  • 34
  • 6
    That doesn't mean software though, it means the hardware the software is built for. Consider a rack of fan belts labelled "Ford Focus", "Nissan Micra", etc.. You're not saying the fan belt is a Nissan Micra, only that it's suitable for use on one. – Graham Apr 16 '19 at 07:17
  • 3
    Only MS Windows uses x86 to specifically exclude x86-64. In other contexts, like computer architecture discussion, x86 includes all CPUs that are backwards-compatible with 8086, with the usual assumption that modern CPUs are running in their best mode (x86-64 long mode). Or at least no implication of 32-bit mode specifically. e.g. "x86 has efficient unaligned loads, but ARM or MIPS doesn't always". But I'd certainly say "modern x86 has 16 integer and 16 or 32 vector registers". (Which is only true in long mode, and I'm of course talking about architectural registers, not physical.) – Peter Cordes Apr 17 '19 at 01:05
  • 1
    TL:DR: In other contexts (outside of MS Windows software), x86-64 is a subset of x86, not a disjoint set. – Peter Cordes Apr 17 '19 at 01:08
  • 1
    A term that unambiguously means 32-bit x86 is "IA-32". https://en.wikipedia.org/wiki/IA-32. Intel uses that in their ISA manuals. (For a while, they used IA-32e (enhanced) for x86-64-specific features / modes. I forget if they still do that or if they call it x86-64.) – Peter Cordes Apr 17 '19 at 01:29
8

The name "x86" was never 'given' or 'designed' this way. If I remember correctly, it more or less evolved as a convenient abbreviation for a whole range of compatible processors.

Back in the day when PC's became popular, it was important that your PC was "IBM Compatible". This meant, among other things, your PC must have an Intel 8086 or an 8088. Later, when Intel released more powerful processors such as the (rare) 80186 or (popular) 80286, it was still important that your PC was just "MS-DOS" or "IBM Compatible". The 80286 was just a faster processor. It had a protected mode feature, but little software actually used or even required that.

The next step was the 80386. This was an improvement over the 80286 because it had a mode that provided full backward compatibility with 8086 programs. Operating systems such as OS/2, DesqView and MS-Windows used this mode to provide backward compatibility with existing software. Other operating systems such as Linux and *BSD's designed for PC hardware also depended on some new features of the 80386 without actually providing direct compatibility with existing MS-DOS software. All these systems required a 80386 processor.

Then came the 80486. An even faster and more powerful processor but mainly backward compatible with the '386. So if you bought a '486 you could still run software designed for the '386. The package would say 'needs a 386 or better' or 'needs 386 or 486'

Along came the 80586 or Pentium. And then the Pentium Pro, also known as 80686...

By this time software developers got tired of listing all possible numbers and since most software was still written to be able to run on a '386, the whole list of numbers was abbreviated to just "x86". This later became synonymous with "32 bit", because the 80386 was a 32 bit processor and hence software that's written for 'x86' is 32-bit software.

Toby Speight
  • 1,611
  • 14
  • 31
Oscar
  • 81
  • 2
7

Intel products were numbered. For example, their first microprocessor was the 4-bit Intel 4004, which was coupled with the 4001 ROM, 4002 RAM, and 4003 shift register. The start denoted the series, and the last digit denoted the specific part.

Later, the intel 8008 came along, which was an 8-bit microprocessor. This was succeeded by the 8080, which was then replaced by the 8085, which was then replaced by the 8086.

After the 8086, processors started taking on the format of 80x86, with x being a number such as 80186, 80286, 80386, etc. They were backwards compatible with one-another, and modern computers still boot into 16-bit-mode. As Intel continued rolling out processors, they began to be referred to as Intel 386 or Intel 486 rather than Intel 80386. This is how the terms 'i386' and 'i586' came into play. As they were based on the same architecture, they were called Intel x86, where x refers to a number. They also came with coprocessors that had a last number of '7', such as 80387, and as such we also have x87.

Josh Pritsker
  • 71
  • 4
3

It just means any processor compatible with same architecture. So it includes 8088, 8086, 80186, 80286, 80386, 80486, Pentium, etc..

Justme
  • 31,506
  • 1
  • 73
  • 145
1

Practically x86 is shortening for "80386 or 80486 running in 32-bit mode". It comes from 8086/186/286+ line but Win32 cannot run on CPU below 386. After 80486 the 80*86 scheme was changed to Pentium[N] and AMD [model].

i486
  • 111
  • 4