This is not a complete answer because it doesn't answer what the exact cost savings were, but I think it's worthwhile to have an informed primary source for the claim that there were cost-savings and commodity-components motivations behind IBM's choice to use the 8088 instead of the 8086.
Peter Norton, PC guru and DOS programmer extraordinaire, writes in his book, Inside the IBM PC:
(© 1986; p. 9)
“There was an inherent practical problem . . . in using the 8086 as the base of a computer design. While the 8086 had 16-bit capabilities internally—which is very good—it also had to work exclusively with other computer components that handle 16 bits at a time as well. When the PC was being designed, 8-bit parts were plentiful and cheap; 16-bit parts were more expensive and in shorter supply. This presented an obstacle to anyone designing a computer around the 8086.
Intel found a simple, practical solution to this problem with the 8088 chip. The 8088 internally has all the 16-bit skills of the 8086, but when it communicates with other circuitry around it, it talks only 8 bits at a time; this slightly reduces the speed of the 8088, but it makes it possible for the 8088 to work with other components that are cheap and plentiful.
For practical reasons, IBM designed the original model of PC around the 8088—a microprocessor with 16-bit power, but 8-bit economy. […]”
Furthermore, while the question makes it sound like IBM's choice to use a hobbled 16-bit processor was a rather curious one, it really wasn't. It's important to realize that when the IBM PC was designed (and even at the time of its release to the public), virtually all home computers were 8-bit systems.
In fact, IBM's original plan apparently was to use an 8-bit processor, and Microsoft is who persuaded them to go with the 16-bit 8086 instead. In an interview with PC Magazine on March 25, 1997, Bill Gates had this to say (emphasis added):
…for IBM it was extremely different because this was a project where they let a supplier—a partner, whatever you call us—shape the definition of the machine and provide fundamental elements of the machine. When they first came to us, their concept was to do an 8-bit computer. And the project was more notable because they were going to do it so quickly and use an outside company. It wouldn't be a high-volume product.
Their charge was to do a home and a very low-end business machine. They had the Data Master, which was 8085-based at the time, that they felt was covering part of the business market. Then they had the 5100, the machine that had both an APL and a BASIC interpreter, which was covering another part of the business market. So it was sort of a home-down business machine. And it was a very small team in Boca that wanted to prove that IBM could do a product, any kind of product, in about an 18-month cycle. And that was the most novel-that was going to be the novel thing was: could you work with outsiders, which in this case was mostly ourselves but also Intel, and do it quickly?
And the key engineer on the project, Lou Eggebrecht, was fast-moving. Once we convinced IBM to go 16-bit (and we looked at 68000 which unfortunately wasn't debugged at the time so decided to go 8086), he cranked out that motherboard in about 40 days. It's one of the most phenomenal projects because there were very small resources involved and we had to ROM the BASIC which meant that it was essentially cast in concrete, so you couldn't make much in the way of mistakes.
Microsoft co-founder Paul Allen remembers things the same way as Gates, writing in his autobiography:
(© 2011; p. 133)
That August [of 1980], a three-piece-suited contingent led by Jack same approached us about Project Chess, the code name for what would become IBM's PC. After we talked them out of an 8-ibt machine and won them over to the Intel 8086 (or as it turned out, the cheaper but virtually identical 8088), they wanted everything in our 16-bit cupboard, including FORTRAN, COBOL, and Pascal. Aside from BASIC, none of these products were even close to being ready for the 8086 platform. It would take a wild scramble to get them all done on IBM's tight timetable.
That's not to say, of course, that 16-bit computer systems didn't exist at this time—they did—but they were not found in personal computers. The most popular computers at that time, from Apple and Atari, were powered by the MOS Technology 6502, and a number of others by the Zilog Z80. You might object and say that IBM wasn't really designing the PC to compete with the likes of Apple IIs and Commodores, since it wasn't a home gaming machine, but remember that IBM was still making powerful mainframes and minicomputers and certainly did not expect or want their PC to compete with these.
In fact, the 8088's pseudo-16-bit architecture was considerably more powerful than any of its competitors. It has a lot of neat tricks up its sleeve that its contemporaries just couldn't match:
- Chief among those was its relatively large complement of general-purpose registers. The 6502 only had a single GP register, while the 8088 had between 4 and 6 (depending on how you count). Sure, there were some instructions that were hardcoded to use only certain registers, but this was still a lot more headroom. Plus, these instructions required fewer bytes to encode, which turned the register specialization into an advantage.
- Another unique feature of the 8088 compared to other personal computers were its hardware multiplication and division operations. Being a 16-bit processor internally, these could do a full 16-bit multiply or divide internally on two values that were known only at run-time. Granted, these instructions were extremely slow, but they were still faster than emulating them on processors that didn't support them.
- An even more important advantage of the 8088 was Intel's CISC architecture, which offered a wide variety of extremely powerful "meta-instructions" that could be encoded in fewer bytes and executed more quickly than equivalent sequences of instructions on other microprocessors. The string instructions are the best known, and were truly one of the defining features of the 8088 from a performance-oriented programmer's perspective. With a single opcode (
MOVSB
), you could copy a byte from one memory location to another and advance both pointers—all in an order of magnitude less time than it would have taken to execute these three logical operations. There were instructions to copy memory around (MOVSB
), scan a buffer for a value (SCASB
), compare two buffers (CMPSB
), and fill a buffer with a certain value (STOSB
). When coupled with the REP
prefix (which caused the instruction to be repeated a certain number of times, or according to a particular condition), you had a loop that could do these operations repeatedly at extremely high speeds. The XLAT
instruction is another honorable mention, weighing in at only 1 byte yet allowing efficient, effective use of translation tables.
It's important not to overstate the drawbacks of an 8-bit external bus. This only slowed down memory operations, which were—relatively speaking—extremely slow anyway and therefore avoided as much as possible by programmers targeting this architecture. Where you really saw a penalty from the 8-bit bus was in fetching instructions to be executed (as opposed to data).
It turned out that the 8088 spent a lot of its time idling, waiting for instructions to be read, since it could execute many of them so quickly that its 4-byte prefetch queue was usually empty. (It took ~4 cycles to read a single byte.) The way around this was to take advantage of those nice, short CISC instructions that were fetched quickly and packed readily into a small queue. If you had a series of 1-byte instructions, the queue would stay full and the chip would stay busy—and thus run quickly, as fast as an 8086. When optimizing for 8088, using more instructions was usually a win if they were smaller, and x86 has a lot of special-case short-form encodings of various instructions.
(The 8086, in addition to having a 16-bit external bus, also had a 6-byte prefetch queue; it was these things together that made the 8086 a superior performer, since it was easier to keep the queue full and thus the processor busy. The 8088 limited its prefetch queue to only 4 bytes, probably because prefetch contends with data load/store, and some of that prefetch will turn out to be useless: discarded on jumps. With less memory bandwidth available, it's less worthwhile to aggressively prefetch. See discussion in comments. Michael Abrash's extended treatment of the prefetch queue in his Zen of Assembly is also worth a read.)
Another thing about the 8088 (and 8086, of course) that was huge was the 8087 math coprocessor. It was an expensive add-on for sure, and therefore wasn't found in many systems, but boy was it powerful. Not only did it make it possible to do complex IEEE floating-point operations, which was already unprecedented in a home computer, it also did it with high accuracy and precision. Even more significantly, it was a true coprocessor, that could execute floating-point operations independently, meaning that the main 8088/8086 processor could stay busy executing integer instructions. Background multiprocessing in 1981—what is this insanity?!
From this perspective, it is, in some ways, surprising that the IBM PC was as powerful as it was. In the hands of the right programmer, it could blow the ceiling off of contemporary personal computers, and would even pose a real threat to some of the mini-computers on the market. Unfortunately, there were relatively few programmers who really took advantage of these neat features, and by the time such tricks were widely known, they were already obsolete. I also can't speak as to the extent to which IBM's engineers realized the power of Intel's processor—they may have thought they were humbling the machine more than they actually were, and it may be Andy Grove's team that were the real wizards here.