Why did some early CPUs use external math chips?

Question

While enjoying the response to "Why did CPU designers in the 70s prioritize reducing pin count?" In 1979 IEEE was hard at work at coming up with a standard for handling floating point numbers, and math functions that dealt with them. I remember several early uses of external math chips i.e. 6502, Z-80, 8088.

Examples are AMD AM9511, AM9512, Motorola MC68881/2, Intel 8231, 8232, 8087, National 32081, TI TMS1018, Weitek WTL1032/1033, Micromega uM-FPU, etc.

Some are being re-purposed while others are still in production for current micro-controllers like the Arduino and Z-80 i.e. Micromega uM-FPU

What was the rationale? Heat, pin count, size, tooling, marketing & cost, die failures, something else?

Answer 1

Another point not addressed in the existing answers relates to the latency associated with accessing an external coprocessor.

The first math coprocessors, while much faster than doing the same work on a CPU, still took many clock cycles to complete each operation. The overhead (bus cycles) associated with transferring data between the two chips was "lost in the noise". In other words, there was no penalty for putting those functions in a separate chip.

However, as coprocessors got faster, this overhead became a significant bottleneck on throughput, and this is what drove integrating them directly into the CPU chip.

Answer 2

Simple: Complexity.

A 8088 had about 29,000 transistor functions, while an 8087 with 45,000 is almost double that. Integrating the FPU within the CPU would have made it three times as big, putting production at a >5 times higher failure rate, resulting in a price tag way higher than 3 times the CPU alone. More like 5-8 times.

When closing in to what is possible in production, it's more efficient to do two smaller chips than one big. This greatly reduces the cost for a complete setup. Having two parts further allows you to skip the additional cost for users not needing the FPU - a majority at that time.

Answer 3

So these math chips (I assume you're talking about floating point units, such as the 8087 and other coprocessors) were not always/usually included in the CPU because they were not required by most users. When you don't need floating point maths, you also don't need the FPU, and that was the commonest case. So to make the CPU cheaper they leave it out.

Then as an upgrade/optional extra, you might add an FPU to do functions that would be a bit slow in software.

Answer 4

It seems to me there are a number of factors involved, some of which have been addressed in other answers:

• design complexity
• cost (which largely results from the complexity)
• feature necessity
• time-to-market

Regarding complexity, as Raffzahn explains, early FPUs were much more complex than the CPUs they complemented. This meant that they needed more transistors, and had lower yields, which both contributed to higher costs, both for the manufacturer and at retail. Ken Shirriff has been documenting some of the complexity involved recently — the 8087 was pushing the envelope in a number of ways.

In the late seventies and early eighties, micro-processors didn’t have floating-point support, so software was developed without needing hardware floating-point. Even once FPUs became available, the cost meant that few users bought them, which meant that (most) software had to continue working without them, which allowed most users to do without them, and so the cycle continued. Some markets used FPUs extensively, e.g. for CAD; but even after Intel added them as standard to 486s, there continued to be a huge market for FPU-less CPUs (which Intel capitalised on with the 486SX). The killer app for FPUs in the x86 world ended up being Quake...

The time-to-market aspect is significant IMO. The 8086 was released in 1976, but the 8087 only became available in 1980; it was supported thanks to its designer’s foresight — even though the FPU was nowhere near designed, let alone ready, Bill Pohlman (who was in charge of the 8086’s development) added features to the 8086 so that it would be able to support a co-processor (not just FPUs too — see Were there 8086 coprocessors other than the 8087?). Likewise, the 386 was released in 1985, but the 387 only became available in 1987 — and at this point, users did know the value of an FPU (which wasn’t the case when the 8086 was released). If Intel had had to wait for their FPUs to be ready, they would have missed a lot of market opportunities (and we wouldn’t be running x86 PCs).

Answer 5

This simple answer is not enough room on a chip for the total transistor count given the limitations of the process technology of the day.

As per Wikipedia on the Intel 8087:

The 8087 was an advanced IC for its time, pushing the limits of period manufacturing technology. Initial yields were extremely low.

This for the coprocessor all by itself.

At 45,000 transistors, attempting to integrate this on the same chip with the main CPU (29,000 counting all ROM and PLA sites) would have been beyond the maximum practical transistor count for the process technology of the day.

Answer 6

Like anything else, in the end, it was "ease of use" for some value of "ease" and "use".

The primary motivator was performance, the specialized processors are just an extension of the maturity of micro electronics and CPU design.

Recall that the original computer were just discrete components. Then, as the ICs evolved, gates out of transistors, and flip flops out of gates, the discrete components fell naturally in to functional integrated circuits. The "first" math co-processor is arguably the 4-Bit adder. Many old computer designs strung those off the shelf adders together as part of their ALU (Arithmetic Logic Unit).

Obviously, the first CPU IC combined much of the decode logic, counters, and the ALU on to a single IC. It's not that computers were new, but these ICs combined them all on a single chip. Thus the "micro" processor. Saving, well, everything: space, cost, heat, complexity, and gaining performance.

These math co-processor were just a natural specialization. The CPUs didn't have the real estate to combine all of those features on a single die. Plus the market wasn't mature enough or willing to spend the money for extravagances like FP Math, or multi-precision multiplication.

History is full of compromises and work arounds to get around "doing math" in CPUs. Fixed point math is a fine substitute for floating point math in many situations. Lookup tables if you can afford the memory. Shifting and adding instead of a general purpose multiplier. Also, most CPUs were, and still are, used for control purposes. Don't need a lot of trigonometry to run a sprinkler timer.

Today, of course, most of the major CPUs bundle FP hardware on the die, but we still have things like GPUs now, off chip, doing their own thing. But there are some CPUs that integrate them today. Why not, it's "Drag and drop" in Verilog -- tada...CPU with integrated low end GPU.

Answer 7

We're so used to hugely complex and dense chips these days it's easy to forget that there was a time when the 8086, with "only" 29,000 transistors (no on-chip cache of any kind), was at the edge of what could be done.

To put it simply:

• It wasn't feasible because the chip would be too big to produce cost-effectively (die size, yield)
• Everything a math chip can do could be done in software, just slower
• Most applications weren't that math-heavy; having a dedicated math chip to speed it up wasn't important enough to most users to justify the extra cost of even adding a co-processor, let alone the probable cost of a CPU with math integrated into it.

It was only as Moore's law allowed for much larger transistor counts that engineers put it use by integrating the math co-processor, adding logic for instruction prefetching/pipelining/branch prediction, cache, and multiple cores that we see in today's chips.

Answer 8

Many small CPUs available and used today for embedded designs do not have an onboard floating point unit - most of the AVR and PIC series, MCS51, some ARM ...

8 bit single-chip microprocessors were meant at least as much, if not more, for the same market that microcontrollers and embedded CPUs target today. In that market, cost and power efficiency are paramount, and a lot of such applications are about controlling equipment and not doing heavy computing.

The same might even apply to early 16/32 bit CPUs - the users that could afford the early examples would not that often have built general purpose desktop computers with them - but had aircraft, industrial equipment, laboratory equipment to equip.

The first CPUs that seem to be tailored ALMOST ONLY to desktop/server/workstation computing are probably those of the 486/early Pentium era: Complex electrical and cooling requirements, multimedia optimizations, consumer-focused marketing...

Mind that floating point can ALWAYS be done in software on an integer only CPU, but with significantly lower performance.

Also, in an embedded application, you would usually have all your data inputs (eg from ADCs driven by sensors, or video data from a digitizer) represented as integers, and try to scale all your calculations accordingly so that floating point math is not NEEDED - and once you can break the problem down to fixed point math, you can simply scale your values by multiplication with either powers of 10 or powers of 2 (the latter being very efficient, but needing some more computing to make end result numbers presentable to a decimal-system user) and work with integers.

Using floating point numbers for controlling equipment is sometimes a bad idea anyway, since there are more complex, bug-prone rules about which exact values a floating point data type can actually represent - which can give you interesting surprises when trying to make decisions by comparing numbers: Two seemingly different inputs (or a too-large number vs the same number given a too-small increment) might suddenly be represented identically, and always compare as identical, which is just perfect if nonequality is your loop exit condition. Also, some floating point formats know one or more "undefined" values, which also might be treated in ways that break expectations like "(a<b && a>b) will always be false" . Add some of these features being subtly implementation dependent, and the fact that you are using someone else's implementation when you use hardware floating point, and try to make code reliably portable... and there is your perfect storm.

The same is true of early PC applications - games could work with fixed point math since they did not really have to work with arbitrary number inputs or high precision, database handling software did not need floating point for anything, spreadsheets were usually not used to handle large AMOUNTS of floating point numbers - and currency can be well expressed in fixed point formats (->integer calculations behind the scenes). Same applied to early multimedia formats. Users that DID need the capability - eg for precision CAD, scientific software, large spreadsheets - bought math coprocessors.

Also, there was likely a chicken-and-egg effect for a while: Since coprocessors weren't that widespread, software authors (of software that did not NEED the performance) often did not bother including support for them even if there was some performance advantage - so no one bought a coprocessor since most of their software made no use of it.

Also, increasing the die size of an IC can cause you big problems when your processes are not yet really high yield. Say you put 10 combined chips on one wafer. You put 10 CPUs and 10 coprocessors each on another. Now you discharge a shotgun at both wafers, each with a load that will blast 10 random holes through each wafer (and silicon defects seem to work just like that). You will not be selling many combined chips.

Answer 9

One simply did not need a math co-processor. I could do double precision floating point operations in Basic on a computer with only an 8-bit Z80 CPU (at 1.66 MHz). Yes, it was slow, but we compensated for that by writing efficient algorithms !

Later I got a 16-bit 8088 (at 8 MHz). It was only when I started using AutoCad that I felt the need for a 8087 co-processor, so I paid for one.

With the 486DX came the built-in co-processor, though you could still opt out with the 486SX and then back in with the 487. All your programs would still run without. But by then the software became dependent on more speed, so you had better opt in. Startiung with the Pentium, math was always included.

You could argue the same for the graphics co-processor. We didn't have any but still we could play games, in 128 x 48 x 1 bit resolution...

I am still surprised that my quad-core Xeon plus GTX feels no faster than my Z80 used to feel, despite running 4 x 2000 times faster. Apparently Windows has eaten up all progress. ;-)

Answer 10

Professional production coder / former IBM dealer here.

High Cost is the answer

And the fact that fairly few users needed them. That's it.

Now, the rationale behind the high cost is that math coprocessors were more complex and harder to make, even than the main CPU, as discussed in other answers. To the consumer it boiled down to a match coprocessor or a printer. Not a hard decision.

PCs were a game-changer for small business, but in organizing and filing (not in hard scientific computation). Killer apps were simple databases, word processing, early accounting, and spreadsheets. Spreadsheets sound like math but they're mostly organizing.

Remember, a lot of spreadsheets deal in money, and floating-point for money isn't necessarily a good idea especially in 32-bit with only 7.225 significant digits. Correct money arithmetic is what keeps COBOL relevant, after all.

---

FP was perfectly possible without a math coprocessor. It was just done in software, slower.

Keep in mind most programmers were very accustomed to not having hardware FP. We coded a lot closer to the bare metal back then, and one simply did not carelessly ask for a bunch of floating point calcs the way you do today -- instead you figured a way to do it in integer math (or to be more precise, fixed point, no disappearing pennies).

Answer 11

IIRC, improved yield was another factor.

The number of properly functioning chips from a given wafer was confidential information, so this is anecdotal - yet, they were not that great.

A 486 could be made as a 486DX with a CPU and FPU, 486SX (CPU only) or 487 (FPU). 486DX chips that only passed 1 of the 2 tests could be sold as 486SX or 487.

---

Re-use/leap-frogging Another factor was that the new CPU and FPU halves need not become available at the same time.

Case: With a new 386 (CPU), lacking the FPU of the later 387, some motherboards allowed re-using a 287. Although not as fast as the later 386/387, a 386/287 was certainly faster with FP than a 386 alone emulating FP math or a 286/287.

Answer 12

My very first job was an in-line weighing system using an 8085. At 6.14MHz it just did not have the speed to perform the necessary floating point calculations needed for doing the stats. I cannot remember the chip used but it was a co-processor.

Answer 13

There are already several excellent answers. I'dd add that floating-point operations can be implemented in software. For example, the BASIC ROM on my old Commodore 64 -- which was actually written by Microsoft -- included subroutines to perform floating-point arithmetic. The VIC-20 had a nearly identical BASIC, so I'm assuming it had similar support.
... and the interfaces were well documented. So the FP support was available to assembly language and (in theory) to any compiler.

IIRC the Atari 400/800 models also had a Microsoft BASIC ROM, so I'm guessing they would also have had software-based floating-point support. I can't speak to that generation of Apples.
Per the comments, the Atari 400/800 also had a Microsoft BASIC, but it was disk (not ROM) based. Per Wikipedia "AppleSoft BASIC" was also authored by Microsoft. AppleSoft BASIC had FP support, I'd guess the Atari version did as well.

Last but not least, software floating-point support via an external library was also a common option on the PC (x86) compilers of the day.

Performing floating-point operations in software was obviously much slower than a numeric co-processor, but this was "good enough" for most users, especially compared with the additional cost of a dedicated "co-pro" -- if that was even an option with your hardware (I'm pretty sure it was not on most "home" computers).

... and if there wasn't a compelling case (for many/most users) for an external numeric (co)processor, there was even less incentive for CPU manufacturers to integrate those functions onto the main/primary CPU. As other answers have pointed out, there were engineering difficulties involved in doing so ... but my point is, there was very little incentive to try.

Answer 14

Since my reputation score at this point isn't high enough to reply directly yet, I wanted to mention 2 things...

The "Math Box" in relation to Atari [Inc.] was found in their vector-graphics based arcade games and it used AMD chips in said box. Such as with the game "Red Baron". I'm pretty sure the much more popular "Battlezone" also used it.

As for Atari BASIC - for the Atari 8-bit computers, not Atari Corp's later ST computers with its much-loathed disc-based BASIC from Metacomco - it was originally designed by Shepardson Microsystems and later revised by OSS. Atari wanted to use Microsoft BASIC and have it contained in an 8K ROM which was to be cartridge-based for the 400/800 computers. That's what the contract with Microsoft stipulated. Microsoft was unable to deliver it and it run within 8K. Shepardson was hired to get it to work and after much labor, recommended scrapping it and going with a custom-written version of BASIC instead. As others have mentioned, Microsoft BASIC for Atari 8-bit was later released on floppy disk but never replaced the ROM based Atari BASIC in the Atari 8-bit line.