24

Based on my understanding, the bitness of a CPU specifies how much memory it can address (which is determined by the size of the CPU's address bus I guess). For example: a 32-bit CPU can address 232 bytes of memory.

But why is the Intel 8086 CPU called a 16-bit CPU even though its address bus is 20-bit, shouldn't it be called a 20-bit CPU?


Addendum: There is a somewhat similar question about bitness and marketing of the Mega Drive: Why was the Sega Genesis marketed as a 16-bit console?

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
user14660
  • 273
  • 1
  • 2
  • 3
  • 26
    Wikipedia: All internal registers, as well as internal and external data buses, are 16 bits wide, which firmly established the "16-bit microprocessor" identity of the 8086. – Kelvin Sherlock Jul 18 '19 at 00:07
  • 14
    The 6502 has 16 address pins but it's not a 16-bit cpu. The 6507 (Atari 2600) had 12 address pins but it's not a 12-bit cpu. – Kelvin Sherlock Jul 18 '19 at 00:13
  • 12
    Also 808286, 386SX and Motorola 68000 CPUs all have only 24 bits of address bus, yet they are never ever referenced as 24-bit CPUs. – Justme Jul 18 '19 at 08:08
  • 16
    Do you have reference that the address bus width is what decides the bitness of the processor? – UncleBod Jul 18 '19 at 15:48
  • @KelvinSherlock: And the 8088 (the cheapo version of the 8086) had 8-bit data busses, but was still a 16-bit CPU (because 16-bit registers). – Vikki Jul 19 '19 at 04:14
  • 3
    This would be confusing as hell since old 32bit pentiums had PAE which allowed it to address up to 52 bit (48 being the most ever implemented) and current 64bit x86_64 CPUs essentially having a 48bit addressing scheme, but depending on model and manufacturer you only see 46 or even only 40 bits implemented in hardware actually. – PlasmaHH Jul 19 '19 at 09:41
  • 1
    Your definition of bitness is wrong, from there the rest of the question is moot. – Patrick Schlüter Jul 22 '21 at 09:17
  • 1
    @Vikki to be fair though, I did read the other day a BYTE magazine from 1980 where Intel promo materials were referring to i8088 as an eight-bit CPU, but one that is future-proof by being binary-compatible with a 16-bit CPU like i8086. Allowing 8088 to be treated more similarly to actual real 8-bit CPUs (except 20-bit address bus) when designing a computer was, after all, it's whole raison d'être. – moonwalker Jul 23 '21 at 00:21
  • @moonwalker do you remember which issue of BYTE? – Stephen Kitt Jul 23 '21 at 06:15
  • @StephenKitt October 1980, Volume 5, Number 10, page 57: "And because it's the only 8-bit microprocessor that addresses up to 1 million bytes of memory, the 8088 can take on large programs. Without having to slow down due to overlays or memory bank switching, like other 8-bit processors." Granted, in an actual article in the same magazine ("An 8088 processor for the S-100 bus") it's explicitly called out 8088 being "a 16-bit processor with 8-bit connections to the outside world", so clearly marketing materials call 8088 an 8-bit CPU less on technical grounds and more to define competition. – moonwalker Jul 23 '21 at 15:59

8 Answers8

64

Generally, the "bitness" of a CPU is determined by the usual or common size of its data registers (or, the width of its data bus), rather than the width of the address bus. There are exceptions, for example while the 8086 is considered a 16-bit CPU because it has a 16-bit data bus, the 8088 (which is software compatible with the 8086 and is also a 16-bit CPU) only has an 8-bit data bus which was less efficient. But functionally, it works just like the 8086.

Today's common 64-bit CPUs have 64-bit wide data registers and data bus, but the address bus isn't anywhere near 64 bits (that would be wasteful, because there isn't 2^64 bytes of memory that has ever been manufactured, let alone installed in one system).

Greg Hewgill
  • 6,999
  • 1
  • 28
  • 32
  • 9
    IMO it is more accurate to refer to the actual register size than the data bus size. Then exceptions to the "data bus" definition, such as the 8088, don't occur. – RichF Jul 18 '19 at 01:04
  • 4
    @RichF: While that is true, there are also exceptions there. For example, the 8086 specially treats the DX and AX registers together as one 32-bit value for the purposes of some instructions (MUL, DIV). That's why I said "usual or common size". – Greg Hewgill Jul 18 '19 at 01:07
  • 19
    Is this really true re 2^64 memory never having been manufactured? That's 4B 4G systems - seems reasonable... – dashnick Jul 18 '19 at 03:00
  • 1
    @dashnick I think that statement is still true, probably for a few years. But not for long - considering the size & number of smartphones in the world, we're actually getting close - and maybe even have gotten there already. Similar is the IP address issue - IPv4 is way over - 32 bits of devices just isn't nearly enough, though we've managed thanks to NAT, private networks, etc. But IPv6 will get us 2^128 devices - enough for a while, but who knows what the future will bring. – manassehkatz-Moving 2 Codidact Jul 18 '19 at 03:44
  • 5
    @RichF Register size can be misleading. For example, the registers of the 68000 are 32 bits wide but the internal data paths, the database and the ALU are only 16 bits.The 68000 is a 16 bit implementation of a 32 bit architecture. – JeremyP Jul 18 '19 at 06:28
  • 4
    @dashnick 2^64 = 18,446,744,073,709,551,616 = (18 million terabytes). At todays RAM prices of about $5.00 per GB, the RAM alone would be a $85 billion. That much storage in hard drives would be a bit cheaper, costing a mere $360 million. I think the only entity that could afford such a system would be the U.S government. – user4574 Jul 18 '19 at 13:25
  • @manassehkatz It was never even the intention that IPv6 would support 2^128 individual devices. (Until privacy issues arose, I think the original intent was that an interface would use 64 bits as a public-facing address, and the other 64 bits would correspond to an interface-specific identifier, e.g. the MAC address.) The idea is to overallocate addresses to anyone needing IP space, so that you never need to give anyone more than one contiguous block. This simplifies routing and (in theory) will keep the size of the global routing table smaller. – chepner Jul 18 '19 at 14:55
  • @chepner I know that - I'm just pointing out that just like 2^64 memory addressing (or previously 32 Meg. DOS hard drive, etc.) limits that seem unreachable suddenly become real limits. – manassehkatz-Moving 2 Codidact Jul 18 '19 at 15:03
  • 3
    The address bus isn't 64 bits wide, but the address space is. – chrylis -cautiouslyoptimistic- Jul 18 '19 at 16:08
  • 9
    @manassehkatz: There are over 4 billion people using mobile phones. Even cheap mobile phones usually have 8GB of memory. So Greg's claim is probably false just from mobile phones alone, and definitely false overall. – BlueRaja - Danny Pflughoeft Jul 18 '19 at 16:08
  • 3
    @BlueRaja: the majority of those are not smartphones and probably have memory measured in megabytes. – Nick Matteo Jul 18 '19 at 16:39
  • 4
    Today's common 64-bit x86-64/AMD64 processors don't even have 64 bits of virtual address space. – ilkkachu Jul 18 '19 at 16:58
  • 2
    @kundor: A quick google search suggests ~60% are smartphones – BlueRaja - Danny Pflughoeft Jul 18 '19 at 17:13
  • @JeremyP Great point. In introductory computer architecture classes/books, a lot of examples include a bus that may be only 16-bit wide pulling at 32-bit sized registers. I think the point was to make sure students dont get set in the idea that bus size is always equal to register size. – 8protons Jul 18 '19 at 17:36
  • “But functionally, it works just like the 8086.” I thought so too, in the late 80s… until I wrote assembly code that executed a 16-bit bit shift instruction on memory (not a register), and learned the hard way that on an 8088, the two bytes were shifted individually, with no carry from the high byte to the low byte. – VGR Jul 18 '19 at 18:25
  • 5
    @VGR, I find that hard to believe. Because of the separation of the EU and BIU,16-bit shifts shouldn't behave any differently from 16-bit adds or any other 16-bit memory operation. The 8086/8088 User's Manual says "software written for one CPU will execute on the other without alteration," and there's nothing that indicates any exceptions for shifts. This would surely be a well-known bug in the 8088. Are you aware of any documentation of this bug? – prl Jul 19 '19 at 02:11
  • 1
    @prl I am not, unfortunately. But at the time, x86 assembly books were quite rare. – VGR Jul 19 '19 at 02:21
  • 3
    @BlueRaja-DannyPflughoeft there are smartphones that have 256 MB (https://www.flipkart.com/lava-a32-white-512-mb/p/itmeuyd88ztz6gue) or 512 MB (https://www.flipkart.com/swipe-konnect-5-1-eco-black-4-gb/p/itmeznnukye5enxt) RAM. My guess would be that most smartphones have 1-4GB RAM –  Jul 19 '19 at 02:52
  • 1
    @hojusaram All depends on how you define "smart" phone. If you define it as Android or iPhone then it must have Gigs. But if you define it as "phone that can browse the internet to at least a limited degree and can load some sort of additional user applications" then Megs. – manassehkatz-Moving 2 Codidact Jul 19 '19 at 15:30
  • @manassehkatz The two models I linked are running Android. A previous comment said 60% of mobile phones are smart phones - I suspect for this definition they use the loosest definition. –  Jul 19 '19 at 15:55
  • @hojusaram It looks like it varies quite a bit by version but that 512 MB is close to minimum for a lot of versions. Of course, I remember when 32 Meg. hard drive was HUGE... – manassehkatz-Moving 2 Codidact Jul 19 '19 at 16:23
  • 2
    @VGR: that's just not plausible. 8088 is well-known to be binary compatible with 8086. What you describe would be obvious and major. Even at the transistor level, the only difference from 8086 is the bus interface and prefetch, doing things with two 8-bit transfers instead of one 16-bit transfer. But shl [di], 1 will definitely do a 16-bit load (in 2 halves), then a 16-bit shift, then a 16-bit store (in 2 halves). Presumably you had some kind of bug in your code and mis-diagnosed it as shl [mem] being a SIMD 2x 8-bit shift. Whatever you changed after that happened to fix the real bug. – Peter Cordes Jul 19 '19 at 17:12
  • 4
    Serious, the VAST majority are not smart phones, but at best feature phones, offering very restricted internet abilities. Most advanced services (including banking) in these countries are SMS based, not IP. They come with single digit megabytes of RAM. And a good number are being just phones. No smart, no feature, no nothing. Keep in mind, what one may count as 'cheap' 8 GiB phone is more than a month salary in most countries on this planet. The huge majority of phones sold are sub 15 USD class, taxes included. You ain't get even a singe GiB for that. I suggest some travel... – Raffzahn Jul 19 '19 at 22:44
  • 1
    @BlueRaja-DannyPflughoeft The (current) flagship iPhone Xs has 4GB of RAM, not 8GB. But it really doesn't need 8GB where some Android phones might need 8GB, because of the operating system and the more explicit memory management of the programming tools, versus Java on Android, which has quite a large footprint (due in part to it's GC architecture). Just a clarification. – Craig Tullis Jul 20 '19 at 00:39
  • @Raffzahn You are correct about feature phones and "smartphones" in recent years, but it was quite common a few years ago for an Android smartphone to have 256 MiB or 512 MiB of RAM and 4 GB of storage. – Toothbrush Jul 20 '19 at 17:30
  • 1
    @Toothbrush Making the numbers even lower, doesn't it? – Raffzahn Jul 20 '19 at 20:52
  • @BlueRaja-DannyPflughoeft The first iPhone to have 1Gb of RAM was the iPhone 5. The latest iPhone XS has 4Gb. The Samsung Galaxy S8 (to pick an Android phone at random) has 4Gb. Modern Android phones may contain more RAM but I think it's likely that almost no mobile phone has more than 4Gb and many have much less. The original iPhone has 128Mb, for example. – JeremyP Jul 21 '19 at 07:42
  • 1
    @Raffzahn: There are a lot of decent, basic Android smartphones under $75 that are within reach of the upper-lower to middle income of third world countries; many would get them second hand for even cheaper. Having lived in these countries, it's surprising how quickly people you don't expect to carry smartphones just a few years ago now have them. Yes, they may cost nearly a month's salary and they may only come with 512MB RAM or so, but a device that allows one to use the internet, access news/prices, use Whatsapp/Facebook, and gigs economy apps is worth the cost for many. – Lie Ryan Jul 21 '19 at 09:10
  • 1
    @Raffzahn: you and I probably would never use many of these lower end devices, but they do contain all the elements of a smartphone: touchscreen device running Android, internet, phone, and Wifi connection, and a camera; and the number shows: China, India, and Indonesia have 700 million, 300 million people, and 100 million smartphone users respectively. – Lie Ryan Jul 21 '19 at 09:44
  • @LieRyan Not sure why you argue with me here, as that's exactly my point. With Android they are already smart phones. I'm talking about the class below. Without a full figured open system and way less than the half GiG you mention. They are still the majority. But yeah, the low end smartphones do as well make the total amount of RAM way lower than the original comment estimated – Raffzahn Jul 21 '19 at 10:15
33

But why the Intel 8086 CPU is called a 16-bit CPU even though its address bus is 20-bit, shouldn't it be called a 20-bit CPU?

Address bus size is probably the least used method to determine CPU "size". For example, the Z80 and many other CPU chips that are commonly considered 8-bit, has a 16-bit address bus. That allows easy access to 64k of memory, which was the norm for many years for typical 8-bit CP/M systems (and many other systems). If the address bus determined the "CPU size" then either these would have been called 16-bit systems or the systems would have been limited to 256 bytes of memory. Similarly, the 4-bit 4004 operated on 4-bit words but had a 12-bit address bus and could access 4k of memory - actually a little more - 4k ROM plus 640 bytes of RAM.

  • 8
    Exactly. One would be hard-pressed to find an "8-bit" processor with an external 8-bit address bus. – DrSheldon Jul 18 '19 at 06:04
  • Odd. In my computing experience I have always regarded the virtual address size as being the major determinant of "bit size", as a consequence of being concerned more with "how large can my code be?" than "how large can integers be?". – dave Jul 18 '19 at 12:43
  • 1
    @another-dave: That's probably because you're used to 32 and 64-bit systems, where registers are wide enough to hold a pointer. (And maybe some 16-bit systems? 16 bits is enough address space to be useful, while 8 isn't for most things). And yes, a large motivation for the move from 32 to 64-bit computing was larger address-space to work with more data. But below 16 bits, systems still usually wanted 16-bit address spaces even if everything else was narrower to save transistors. So addressing memory had to be supported with special architectural features, not like the C model. – Peter Cordes Jul 19 '19 at 17:18
  • @PeterCordes The MC6809/HD6309 family is an example where both the ALU registers and address bus are 16 bits wide. It was used in the Tandy CoCo series and the Dragon clones of it. – Chromatix Dec 01 '19 at 11:21
25

Why is the Intel 8086 CPU called a 16-bit CPU?

Because that’s how Intel marketed it. The 8086 is part of “the range of 16-bit processors from Intel” (see for example Introduction to the iAPX 286, page 3-1). The 8086 Primer says “In 1978, Intel introduced the first high-performance 16-bit microprocessor, the 8086.”

The 8086 Family User’s Manual isn’t quite so categorical, but it does describe the 8086 as an “8/16 bit general-purpose micro-processor” with a “16-bit external data path”; and it specifies that all CPUs in the 8086 family “operate on both 8-and 16-bit data types” with “internal data paths are at least 16 bits wide”. Regarding the 8086 and 8088’s execution units, “A 16-bit arithmetic/logic unit (ALU) in the EU maintains the CPU status and control flags, and manipulates the general registers and instruction operands. All registers and data paths in the EU are 16 bits wide for fast internal transfers.” (The EU is the execution unit.) Finally, “Both CPUs have the same complement of eight 16-bit general registers.”

This covers all the sizes which are, in various combinations, typically used to determine a CPU’s “bit-size”:

  • the internal data path;
  • the native data types;
  • the (integer) register width;
  • the ALU width.

The address bus wasn’t used to qualify a CPU’s size: the 8008, 8080, and 8085 were all considered 8-bit CPUs, even though the 8080 and 8085 had 16-bit address buses. Likewise, the 286 was marketed as a member of the 16-bit family, with a 24-bit address bus.

The address bus can in some ways be thought of as an implementation detail, as can the internal data path size. Thus, Pentium CPUs have a 64-bit internal data path, and Pentium Pro CPUs have a 36-bit address bus, but they are 32-bit CPUs; and current 64-bit x86 CPUs don’t have 64-bit address buses. Even on the 8086, the address bus only affected the bus interface unit. So using the address bus or even the internal data path size can be misleading; Intel only highlighted the latter in the 8086’s case because they were guaranteeing that it would be wide enough to transfer the native data types without splitting them up.

Stephen Kitt
  • 121,835
  • 17
  • 505
  • 462
  • 1
    You are certainly right that the bit-ness of a processor is all about marketing. It is whatever number that is (1) high enough so it looks at least as good (if not better) than competitors' processors, but (2) low enough that you can later sell a "better" one. – DrSheldon Jul 18 '19 at 15:48
  • Marketing is indeed a good explanation for bitness of a CPU. For all the categories you listed one can find CPU's that fail the criteria. 68000 with 32 bit register but 16 bit ALU, Z80 with 4 bit ALU, 65816 which is an 8 bit marketed as 16 bit even if it 8 bit ALU and datapaths. – Patrick Schlüter Jul 22 '21 at 09:25
  • Sometimes it is the system they are built in that will effectively define the bitness. TMS-9900 was a 16 bit CPU but was crippled by the architecture it was built in in the TI-99 (2 memory access with 4 wait states to read 16 bits from system RAM, only 8K ROM and 256 byte RAM were fast). – Patrick Schlüter Jul 22 '21 at 09:31
  • As I mentioned in the comment to the question itself, I did see marketing materials from 1980 in BYTE magazine that referred to Intel 8088 as an 8-bit CPU. Yet despite those marketing materials 8088 is still widely considered a 16-bit CPU. – moonwalker Jul 23 '21 at 00:28
15

Based on my understanding, the bitness of a CPU specify ...

One extreme example is the NS16032 or NS32016:

The CPU was first sold as "16-bit CPU" named "NS16032".

Later, the manufacturer decided to sell exactly the same CPU as "32-bit CPU" under the name "NS32016".

This example shows that there is no real objective criterion that decides if a CPU is a 16- or a 32-bit CPU.

Another example is the Infineon XC2000 which was marketed as "32-bit CPU" some years ago although the derivative I was working with had 16- and 40-bit registers but (as far as I remember) absolutely nothing which was 32 bits wide.

... how much memory it can address.

I have heard of different criteria why I CPU is seen as 16- or 32-bit CPU.

However, I never saw that anybody used this criterion!

Most CPUs I know do not have its "bitness" as address bus width:

Modern 64-bit PC CPUs have 48 bits address bus width which means that they can access 2^48 bytes of memory...

Why the Intel 8086 CPU is called a 16-bit CPU?

There are three common criteria to define the "bitness" of a CPU:

  1. The width of the data bus
  2. The width of general purpose registers
  3. The width of operations (e.g. the CPU can perform a 16-bit addition)

There are a lot of examples of CPUs where these three criteria lead to different results:

  • Motorola 68000, Intel 80386SX, NS16032/NS32016
    (16 bits according to 1., but 32 bits according to 2. and 3.)
    This explains why NS could sell the CPU as "16-bit" CPU first and later sell it as "32-bit CPU".
  • Intel 8088 (8 bits according to 1., but 16 bits according to 2. and 3.)
  • Zilog 8000 (16 bits according to 1. and 2., but 32 bits according to 3.)

However, the 8086 is a "16-bit CPU" according to all three criteria!

Martin Rosenau
  • 3,399
  • 3
  • 11
  • 23
  • 1
    68000 had a 16 bit ALU. Although it had 32 bit arithmetic operations, these were performed in two 16 bit chunks as evidenced by the fact that the 32 bit versions of the operations took longer. So by criterion 3, the 68000 is a 16 bit CPU in implementation. – JeremyP Jul 18 '19 at 07:28
  • 1
    @JeremyP Not really, as the operations performed are 32 bit. Point 3 doesn't state if it's to be done parallel or serial. – Raffzahn Jul 18 '19 at 08:17
  • @JeremyP Both interpretations are possible; there is no rigorous definition that I know of. But as Raffzahn said, it has a 32-bit operation; the criterion as listed by Martin Rosenau is fulfilled. Of course, by this criterion, you could call a Pentium 4 128-bit, since it allowed 128-bit integer addition/multiplication using XMM registers. Some CPU manufacturers tried that too (remember those 256-bit consoles?). – Luaan Jul 18 '19 at 08:24
  • 3
    @Luaan Agreed. In fact Sinclair called the 68008 in the QL an 8/16/32 bit processor. However, at the time, everybody thought of the 68000 as 16 bit except the marketing droids who wanted to make it appear more super. – JeremyP Jul 18 '19 at 09:02
  • 2
    "48 bits address width" is about virtual addresses; an actual bus would be physical addresses. The ISA hard limit for x86-64 physical address is 52 bits (page-table-entry format): Why in 64bit the virtual address are 4 bits short (48bit long) compared with the physical address (52 bit long)?. Actual HW implements 40 or so physical address bits, https://en.wikipedia.org/wiki/RAM_limit#64_bit_computing saying 40 to 52. Future HW will support another level of page tables for another 9 virtual address bits (57 total), allowing lots of NV-DIMM storage. – Peter Cordes Jul 19 '19 at 17:30
14

An N-bit CPU is generally one which can perform a significant range of individual operations on N-bit values about as quickly as it could perform those operations on anything smaller. There is sometimes a little wiggle room as to what "about as quickly" means, but usually it's pretty clear. Note that while N would often match the size of the ALU, that isn't always the case.

The Z80 has a 4-bit ALU, but it can add two eight-bit values faster than it can add two values of any other size (four cycles for a register-to-accumulator add). It has instructions to add two 16-bit values, but the fastest of those takes almost three times as long (11 cycles) as the instruction to add two 8-bit values. Thus, it is essentially always described as an 8-bit processor.

The CDP1802 has a one-bit ALU, but it the clock pulses eight times for each machine cycle. The CDP has sixteen 16-bit registers, and can increment or decrement two of them (or increment one of them twice) in a two-machine-cycle instruction. Despite the ability to directly increment and decrement any 16-bit register in a single machine cycle, however, and despite its one-bit ALU, it is always described as an 8-bit processor.

The 8088 has a 16-bit ALU, but an 8-bit memory bus. Nearly all operations involving registers can be performed on 16-bit values just as fast as with 8-bit values, but operations which involve reading and writing memory are about 50% slower. Because 16-bit register operations are generally as fast as 8-bit operations, it is often described as a 16-bit CPU, but occasionally as an 8-bit one.

The 68000 has a 16-bit ALU and memory bus. Operations involving 32-bit values are generally about 50% slower than operations involving 16-bit ones. It is thus usually described as a 16-bit CPU, but because most 32-bit operations take significantly less than twice as long as 16-bit ones, it is sometimes described as 32-bit. C compilers for the 68000 often allow int to be configured as either 16 or 32 bits.

supercat
  • 35,993
  • 3
  • 63
  • 159
  • 1
    This question has gotten several good, succinct answers, but I think this one is the best. – Davislor Jul 19 '19 at 11:14
  • It's also the most fascinating of the answers as the first computer I built was based on the CDP1802 and it explains why there were so many clocks per instruction cycle. I definitely learned something new today! – Julie in Austin Jul 20 '19 at 21:17
  • @JulieinAustin: Incidentally, if the CDP1802 feels like the addressing unit is annoyingly separated from ALU-based operations, there's a two-chip variation which puts the addressing registers in one chip, and puts the D register and ALU in the other. – supercat Mar 17 '24 at 22:36
12

There are many great answers here and it seems safe to assume that those answers have established that bitness is about the main data type a CPU is build around. After all, the task of a CPU is Data Processing not Address Generation.

Next to all relevant criteria have been mentioned, but I'd like to take it a step back to a more generic approach, showing that there are three basic perspectives bitness can be defined by

  1. Marketing
  2. ISA
  3. Implementation

Always in this order.

The first one being often forgotten(*1) or ignored (*2) by tech people.

Marketing

Noteworthy here is that it's not always about more is better - like Atari did by marketing the Jaguar as 64 bit. Motorola for example did originally market the 68k as being 16 bit (and so did many early users). At that time 8 bit CPUs were standard for microcomputers, with the exception of some 16 bit families (PACE et. al.), so 16 bit were seen as the next step. Going as sole 32 bit provider was seen as an uphill battle against every other offering, as customers would rather ask why spend money on something they don't need. So while some of the 16 bit age, like 9900 or 8086 were really 16 bit, Motorola, National and Zilog placed their new development as 16 bit - despite the fact that we today would see them as 32 bit.

ISA - Instruction Set Architecture

Taking the (abstract) ISA as guideline is eventually not just the middle of the list but also the middle ground here. An ISA describes how a CPU works at instruction level. It describes what the CPU can do using the resources visible to a program handled by the instructions available. It doesn't care if a CPU is implemented bit serial or full parallel or anything inbetween. It doesn't rely on how wide an external bus is either.

Implementation

Tech people often focus on the lowest level, implementation. What is the size of the data bus, internal or external, the size of the ALU, registers and so on. While this does have impacts on performance and for sure offers a good game of 'mine is better than yours', it is very specific on single implementations, making it hard to see the whole picture - after all, a NS32008 is an 8 bit CPU, thus not better than an 8080, isn't it?

ISA vs. Implementation

An ISA can be implemented in a wide variety, and that has been used all over since the early days (of computer families). IBM /360 were not always 32 bit implementations - but they always present the same 32 bit ISA. Or take PDP-8/S, a bit serial implementation of the PDP-8 ISA. And not at least the 68008 vs. 68000 vs. 68020. While having many different bitnesses in terms of register, ALU and bus, they are all the same 32 bit ISA.

In the end, it's the ISA that decides what a CPU is. Implementation differentiates two chips in usage not more than using the same at variations of clock speed. I guess noone will state that a 2 MHz 6502 is a different CPU than a 1 MHz one.

Technology vs. Marketing

(...silence ...)


Last but not least it should be noted that all the bitness arguments are a thing of the past. And even back then not all that meaningful. It was (made) important during a phase of maturing, when going from barely usable architectures and implementations thereof toward today's all around capable ones. So trying to make sense from today's point of view does not always produce a valid result.


*1 - Martin made a great point by the XC2000

*2 - Especially here, as most of us are rather on the technological side than about pumping out funny phrases.

Raffzahn
  • 222,541
  • 22
  • 631
  • 918
  • 1
    That's a really interesting point about m68k being marketed as 16-bit to avoid seeming extravagant and costly vs. its purely 16-bit competitors. I'd never thought of it from that angle. – Peter Cordes Jul 19 '19 at 17:37
  • ISA vs. Implementation: implementation changes can get enshrined in the ISA. For example, Intel's x86 manuals guarantee that a 64-bit aligned load or store is atomic on Pentium and later. Even though it's still a 32-bit CPU! The few 64-bit load or store instructions include x87 fld and fild, and integer cmpxchg8b. (And on Pentium MMX, movq). Since an 80-bit x87 reg has a 64-bit significand, fild m64 ; fistp m64 can atomically copy an arbitrary 64-bit integer without corrupting it (e.g. to a local tmp on the stack for integer reload). GCC does this for stdatomic without SSE. – Peter Cordes Jul 19 '19 at 17:41
  • Why is integer assignment on a naturally aligned variable atomic on x86? quotes the relevant parts of Intel's manuals that give guarantees for P5 Pentium and later. And for P6 and later re: cacheable loads / stores. – Peter Cordes Jul 19 '19 at 17:42
  • There isn't really a complete x86 ISA standard separate from implementations. In the ARM world for example, they might say that ARMv5 adds some new guarantee of something, and these various microarchitectures are implementations of ARMv5. In the x86 world, we have the same thing just documented differently. New generations of uarches add new guarantees. Intel's uncooperative-to-AMD attitude means that there isn't good documentation of portable guarantees; compiler devs have to find the common subset of what Intel and AMD guarantee when implementing __atomic_... support. – Peter Cordes Jul 19 '19 at 20:49
  • Part of what makes something an ISA guarantee is that it's guaranteed to work on all future CPUs. Intel doesn't document things that are just implementation details of a specific uarch. (Other than in their optimization manual for performance effects. Things that matter for correctness are left undocumented if they don't want you to write code that relies on it. Lots of things like that have been reverse-engineered, e.g. page-walk coherence in some cases: http://blog.stuffedcow.net/2015/08/pagewalk-coherence/.) – Peter Cordes Jul 19 '19 at 20:53
  • Later 32-bit Intel CPUs provide all the same atomicity guarantees that earlier ones did (and sometimes more), like I said. As far as answering this question, yes what matters are ISA changes. They become ISA changes by documentation, not just by implementation. I took the wrong approach to making that point earlier. (Unless you want to get into "undocumented ISA" stuff like the fact that an AVX 32-byte aligned load or store is in fact atomic on Haswell and later, even though Intel only guarantees atomicity up to 8 bytes with no way to detect when a system/CPU has wider load/store atomicity.) – Peter Cordes Jul 19 '19 at 21:07
  • @PeterCordes Erm, if it doesn't work the polite way, lets put it straight: This nitpicking doesn't make any sense here. – Raffzahn Jul 19 '19 at 21:21
  • I think you're right. I thought there was an interesting point to be made here about implementation changes making it easy to add new ISA guarantees/features, but extending the ISA for new implementations is not rare. Talking about wider atomicity guarantees or happens-to-work features probably just confuses the issue of bitness, because nobody's arguing that P5 or early P6 should be called 64-bit CPUs based on their data bus width. Sorry for the noise. – Peter Cordes Jul 19 '19 at 21:32
  • No sweat, we're bit flipping nerds - always :)) – Raffzahn Jul 19 '19 at 21:48
  • I had a book in the early to mid 80s on "16 bit microprocessors" (possibly this one http://www.bitsavers.org/pdf/osborne/books/Osborne_16-Bit_Microprocessor_Handbook_1981.pdf) and the M68000 is in there. – Peter Smith Dec 04 '19 at 16:03
  • @PeterSmith Yes, I guess many bought it - and many more peeked into at a book store :)) – Raffzahn Dec 04 '19 at 16:16
8

the bitness of a CPU specifies how much memory it can address (which is determined by the size of the CPU's address bus I guess)

Not really. It is generally defined by the size of data it natively operates over, so the size of its registers. The definition is slightly fuzzy though as some CPUs have a range of register sizes for different features, and of course there is marketing involved as others have mentioned.

To give a few examples which should clarify the "it is generally the registers that count", certainly for Intel CPUs and related implementations:

  • The 8086 has 16-bit registers (though can access many of them as 8-bit ones too) and a 16-bit data bus so is generally considered a 16-bit CPU despite the 20-bit address bus. Same for the 80186.
  • The 8088 is basically an 8086 with an 8-bit data bus so can work on cheaper motherboards. Despite the smaller external bus it still deals with 16-bit vales internally (the bus has a shim between it and the rest of the CPU to translate one 16-bit request into two 8-bit ones), so is still considered a 16-bit CPU and can run all the software that the 8086 can.
  • The 80286, still 16-bit like the 8086, had a 24-bit address bus, allowing eays use of 16Mb of memory instead of being limited to 1Mb (without paging tricks like EMS).
  • The 80386 (latterly referred to as the DX once the SX was released) has 32-bit registers (though can use them in 16-bit and 8-bit chunks in many ways) and a 32-bit data bus and a 32-bit address bus. There is little question with this one!
  • The 386SX is to the 386DX what the 8088 is to the 8086: the same internals but reduced external interfaces so it can run on cheaper motherboards. This had 32-bit internals, so is considered a 32-bit CPU, but a 16-bit data bus and 24-bit address bus for talking to the rest of the machine (more like a 286).
  • The 486 had a built-in floating-point co-processor which operates on 80-bit "long double" registers. This does not make the whole chip 80-bit though as these are not general purpose registers: the 486 is 32-bit mostly internally just like the 386 line.
  • The original Pentium CPUs were still 32-bit internally (apart from the floating-point registers) with a 32-bit address bus, so are called 32-bit chips, but had a 64-bit data bus so that memory could be transferred to/from the CPUs internal cache faster (CPU<->RAM bandwidth being a major bottleneck by that point as CPUs sped up much faster than RAM did)
  • Later versions of the Pentium had another little complication: the MMX registers were 64-bit. But like floating-point registers these are not general purpose registers, so they do not make the whole chip be considered 64-bit.
  • Also, many 32-bit Pentiums (PPro, PIII, possible the PII, some Celerons) had 36-bit address busses allowing them to access 64GB or memory instead of being limited to 4GB as the first versions were (unless certain paging tricks like PAE were used).
  • Straying quite far out from "retro computing" now, some of AMD's 64-bit designs used a 40-bit address bus (still 64-bit internals and 64-bit data bus) allowing a Terabyte of address space. Both they and Intel seem to have standardised on a 48-bit address bus.

Non-Intel chips follow very similar conventions. For instance most 8-bit CPUs like the 6502 family had 16-bit address busses (so they could address 64Kb of memory).

It can be a bit confused, and it can get even more complicated when you start moving away from general purpose CPUs to start looking at more specialised processors, but hopefully this makes it a little clearer to you.

  • Not to mention that later Pentium (Pro until Core2) had more than 32 address lines while still being 32 Bit data. – Raffzahn Jul 18 '19 at 11:00
  • @Raffzahn - I thought I'd made my point by then so stopped, but it probably makes sense to finish the job and mention that. And the 48-bit address bus. I'll edit those in. – David Spillett Jul 18 '19 at 14:33
  • 1
    Oh, no doubt, you made a great list. I just remembered that PAE was again an oddity where the CPUs stayed 32 Bit, but addressing went 36 (Pentium Pro) and 38 (Xeon) even before the CPU itself moved to 64 bit - and all of that complete invisible to user level ISA. – Raffzahn Jul 18 '19 at 14:40
  • 48-bit is the x86-64 virtual address width, and it's tied to the page-table format so it has to be standardized (4-level x 9-bit page tables + 12 bit page offset). That's not a bus; translation to physical happens right away in the load/store execution units. The physical address space is up to 52 bits wide (PTE format) Why in 64bit the virtual address are 4 bits short (48bit long) compared with the physical address (52 bit long)?. But physical address width depends on the CPU model, with some as narrow as 40-ish bits. – Peter Cordes Jul 19 '19 at 17:51
  • x86-64: canonical addresses and actual available range shows how to check a given CPU (using cpuid) to find the actual virtual and physical address widths. e.g. a Haswell desktop reported 39-bit physical address width. – Peter Cordes Jul 19 '19 at 17:55
  • PPro / PII/PIII are a different architecture from P5 Pentium. All P6-family CPUs support PAE (new page-table format with 36-bit physical addresses, and a no-exec bit). No P5 CPUs do (Pentium, Pentium MMX). Anyway, if you're looking for a collective name for those CPUs with PAE, it's "P6", not Pentium. Confusingly Pentium has been the name of a microarchitecture (P5), and also a marketing / product-line name that they still use (e.g. modern Skylake Pentium and Celeron CPUs are a thing.) Even "Core" has been both a marketing name (Core duo / Core 2 duo) and a uarch (first seen in Core 2). – Peter Cordes Jul 19 '19 at 18:14
  • 2
    unless certain paging tricks like PAE were used. Umm, PAE is the trick that allows them to access more than 4GB of physical memory. Virtual / linear addresses are still 32-bit in 32-bit mode; only paging with PAE can generate physical addresses larger than that. – Peter Cordes Jul 19 '19 at 21:01
-1

because 8086 can have 16 data bus as well as it can be categories into five register those are:

  1. General register(AX,BX,CX,DX)
  2. Index Register(SI,DI)
  3. Pointer Register(SP,BP,IP)
  4. Control Register(IP,OTHER CONTROL)
  5. Segment Register(CS,DS,ES,SS) totally 16 register are there, so it called 16-bit