# Why is there a separate Floating Point Units in some micro controllers

I would like to know why there is a separate FPU peripheral in some high end micro-controllers even if the small end 8 bit controllers can perform float calculations on their own.

I tried experimenting with a float division on a pic 18 controller which does not have an FPU (Majority of 8 bit family does not have an FPU)and found out by debugging(ICD 3) that @48 mhz clock a simple division of float variable takes minimum 800+ clock cycles.

I don't have a controller with FPU on my side as of now to test with.But still I would like to know what effective difference and edge does the addition of a FPU make or provide .

While FPU are typically slower than the main CPU, they are much faster in calculating with floating point because they use hardware implementation of the floating point operators. In order to better understand what happens, consider that a floating point operation consists of several steps.

For instance, an addition is roughly:

1. Comparison of the exponentials;
2. Scaling of the significand according to the exponentials' difference;
3. Sum of the significands;
4. Rounding of the resulting significand;
5. (possible) adjusting of the result's exponential.

Note that these operations must be performed separately on a fixed-point CPU, and each may take more than one cycle to be computed.

If you design a dedicated unit that can in part parallelize these operations (e.g rounding and adjusting the exponential), you can save significant computation time.

• If the FP operation cannot cause an exception (or imprecise exceptions are allowed by the architecture, e.g., the FPU is treated more like an I/O device), then the main processing unit can continue with other work while the FPU calculates. (Even if exceptions are possible and must be precise, an implementation can—possibly conservatively, i.e., with false positives—check if one is possible reducing the delay before main processor operations can commit. IIRC, MIPS R4000 did this.) Oct 29 '14 at 11:21

When a microprocessor or microcontroller needs to execute a lot floating-point calculations, there are three ways to carry this out:

1) In software i.e. floating-point library
2) An FPU which is integrated intro the microprocessor/microcontroller
3) An FPU in a separate chip


Choice 1, doing it all in software, may be the only option if hardware FPU's are not available. A software solution will be 5-10 times slower, or even worse depending on the register size of the processor. I am currently doing a project which requires some 32-bit floating point math on an 8-bit HCS08. Doing that with an 8-bit accumulator is pretty ugly.

Choices 2 and 3 are pretty much the same thing, speed wise. One of the very first separate FPU's was the the 8087, a companion chip added to the 16-bit 8086, the great-great-great-great-granddaddy (or something like that) of the Intel or AMD 80x86 processor in your PC. It was developed for two reasons: Intel didn't have the capability at the time to include the FPU on the same chip as the processor; and this allowed it to be sold as an option -- the 8087 initially cost \$150 just by itself. Computer makers put a socket next to the 8086 processor (or 8088 with an 8-bit data bus and 16-bit address bus, which was in the very first IBM PC model 5150) so a consumer could add an 8087 later on.

The 8087 had something like 60 different instructions. If there was no 8087, the 8086/8088 actually trapped the floating point instructions codes and emulated them in software. It could handle 32/64 bit floating numbers, and used an internal 80-bit register for calculations. It's floating point format was the basis for the IEEE 754 floating point standard, which is now used by all other FPU's and floating point software libraries.

Besides the typical floating point operations like add, subtract, multiply, and square root, it could do exponential, logarithmic and trigonometric calculations.

The FPU for the 80x86 was a separate chip up through the 80386/80387; from the 80486 onwards it was integrated into the processor. The advantage of having the chip as part of the processor, is that you don't need to have any extra leads (i.e. pins) between the processor and the FPU to control its operation. Outboard FPU's also shared data, address and other control lines with the processor, but those were already there to handle external memory.

There also were separate FPU chips for the 68000, and the early MIPS and ARM processor which did not have integrated floating point. Now both MIPS and ARM processors (in addition to the Intel 80x86 line and others) have FPUs built into the chip. The advantage of course is both cost and space on the PCB.

I am not aware of any 8-bit microprocessor or microcontroller that includes an FPU (external or integrated), except for the Intel 8232, designed for the 8-bit 8080.

I am also not aware of any microcontroller that has a separate FPU available for it, since microcontrollers generally don't have their address and data busses brought out to external pins like microprocessors do. However there is no reason not to include an FPU integrated into a microcontroller, like some ARM's do.

Whether you have a hardware FPU, or need to use a floating point library, in almost all cases this will completely transparent to you, since you just declare a variable to be floating point (float or double keywords in C for example), and the compiler will generate the appropriate instructions to either call the library or use the FPU. You may not to set up your compiler options though to inciate you have an FPU.

• There is also a distinction between a tightly coupled coprocessor interface (where FP exceptions are precise) an a loosely coupled interface (more like I/O) where FP exceptions are imprecise with respect to the main processor. For the former, the main processor may have to wait at least until it is determined that an exception cannot occur. I suspect that microcontroller FPUs generally don't have exceptions enabled (if only for WCET reasons). Oct 29 '14 at 11:30
• The 8088 was a 16-bit processor with an 8-bit bus, but it was designed for use with the 8087. I'm not sure I see the "problem". Apr 30 '16 at 22:31
• @supercat If you were referring to my third to the last paragraph, I'm not sure why I included 16-bit processors there. I have edited it. Also, you are quite right, the 8087 was compatible with the 8088 and the very first [IBM PC model 5150](QHRU-UZ3RAJ-8BN323) (with an 8088) have had a socket for an 8087. I should have included it. May 1 '16 at 0:15
• @tcrosley: You did include the 8087, which is why I was puzzled by you saying 16-bit processors didn't have them. BTW, I've sometimes thought someone should do a chip with a half-serial multiplier to facilitate RSA and similar cryptography. Hardware for a large multiply+add unit which could hold one factor and accepted the other serially while clocking in the other factor and term and clocking out results at a rate of two bits per cycle would be quite cheap (cost proportional to N rather than NxN), but would have performance comparable to a much fancier unit since even the latter... May 1 '16 at 16:07
• ...would be throughput-limited by the need to get data into and out of it. May 1 '16 at 16:07

Have an FPU allows floating point calculations to be made more quickly. Software floating point is more flexible (single, double, or whatever precision you like if you write the routines), but is extremely slow in comparison (at least an order of magnitude, all other things being equal).

It's not necessarily a perfect solution even if you have to do number crunching, for example, in some of the instruments I've developed the single precision of a typical ARM FPU is inadequate, and of course the FPU uses silicon area, so the cost of the chip increases, and they tend to be aimed at applications that require a lot of I/O pins, so you may be looking at 256 ball fine pitch BGA package that requires many layers in the PCB rather than an easier-to-use package.