This question already has an answer here:
Since a 32bit system can't manage a 2^33 number (because the obvious 32bit limit), how can manage a 80bit floating point number?
It should require "80bit"...
This question already has an answer here: Since a 32bit system can't manage a 2^33 number (because the obvious 32bit limit), how can manage a 80bit floating point number? It should require "80bit"... 

marked as duplicate by Ƭᴇcʜιᴇ007, and31415, Canadian Luke, Michael Kjörling, woliveirajr Jul 31 '14 at 19:42This question has been asked before and already has an answer. If those answers do not fully address your question, please ask a new question. 


One of the meanings of a 32 bit CPU is that its registers are 32 bits wide. This doesn't mean it can't deal with say, 64 bit numbers, just that it has to deal with the lower 32 bit half first, then the upper 32 bit half second. It's slower than if the CPU could just load the values in a wider 64 bit register, but still possible. Thus, the "bitness" of a system does not necessarily limit the size of the numbers a program can deal with, because you can always break up operations that wont fit into CPU registers into multiple operations. So it makes operations slower, consume more memory (if you have to use memory as a "scratchpad"), and more difficult to program, but the operations are still possible. However, none of that matters with, for example, Intel 32 bit processors and floating point, as the floating point part of the CPU has its own registers and they are 80 bits wide. (Early in the x86's history, the floating point capability was a separate chip, it was integrated in the CPU beginning with 80486DX.) @Breakthrough's answer inspired me to add this. Floating point values, insofar as they are stored in the FPU registers, work very different than binary integer values. The 80 bits of a floating point value are divided amongst a mantissa and exponent (there is also the "base" in floating point numbers which is always 2). The mantissa contains the significant digits, and the exponent determines how large those significant digits are. So there is no "overflow" into another register, if your number gets too big to fit in the mantissa, your exponent increases and you lose precision  i.e. when you convert it to an integer, you'll lose decimal places off the right  this is why it's called floating point. If your exponent is too large, you then have a floatingpoint overflow, but you can't easily extend it to another register since the exponent and mantissa are tied together. I could be inaccurate and wrong about some of that, but I believe that's the gist of it. (This Wikipedia article illustrates the above a bit more succinctly.) It's OK that this works totally differently since the whole "floatingpoint" part of the CPU is sort of in its own world  you use special CPU instructions to access it and such. Also, towards the point of the question, because it's separate, the bitness of the FPU isn't tightly coupled with bitness of the native CPU. 


32bit, 64bit, and 128bit all refer to the word length of the processor, which can be thought of as the "fundamental data type". Often, this is the number of bits transferred to/from the RAM of the system, and the width of pointers (although nothing stops you from using software to access more RAM then what a single pointer can access). Assuming a constant clock speed (as well as everything else in the architecture being constant), and assuming memory reads/writes are the same speed (we assume 1 clock cycle here, but this is far from the case in real life), you can add two 64bit numbers in a single clock cycle on a 64bit machine (three if you count fetching the numbers from RAM):
We can also do the same computation on a 32bit machine... However, on a 32bit machine, we need to do this in software, since the lower 32bits must be added first, compensate for overflow, then add the upper 64bits:
Going through my madeup assembly syntax, you can easily see how higherprecision operations can take an exponentially longer time on a lower word length machine. This is the real key to 64bit and 128bit processors: they allow us to handle larger numbers of bits in a single operation. Some machines include instructions for adding other quantities with a carry (e.g. Now, to extend this to the question, it's simple to see how we could add numbers larger than the registers we have available  we just break the problem up into chunks the size of the registers, and work from there. Although as mentioned by @MatteoItalia, the x87 FPU stack has native support for 80bit quantities, in systems lacking this support (or processors lacking a floating point unit entirely!), the equivalent computations/operations must be performed in software. So for an 80bit number, after adding each 32bit segment, one would also check for overflow into the 81st bit, and optionally zero the higher order bits out. These checks/zeros are performed automatically for certain x86 and x8664 instructions, where the source and destination operand sizes are specified (although these are only specified in powers of 2 starting from 1 byte wide). Of course, with floating point numbers, one can't simply perform the binary addition since the mantissa and significant digits are packed together in offset form. In the ALU on an x86 processor, there is a hardware circuit to perform this for IEEE 32bit and 64bit floats; however, even in the absence of a floatingpoint unit (FPU), the same computations can be performed in software (e.g. through the use of the GNU Scientific Library, which uses an FPU when compiled on architectures with, falling back to software algorithms if no floatingpoint hardware is available [e.g. for embedded microcontrollers lacking FPUs]). Given enough memory, one can also perform computations on numbers of arbitrary (or "infinite"  within realistic bounds) precision, using more memory as more precision is required. One implementation of this exists in the GNU Multiple Precision library, allowing unlimited precision (until your RAM is full, of course) on integer, rational, and floating point operations. 


The memory architecture of the system may only allow you to move 32 bits at once  but that doesn't stop it from using larger numbers. Think of multiplication. You may know your multiplication tables up to 10x10, yet you probably have no problem performing 123x321 on a piece of paper: you just break it into many small problems, multiplying individual digits, and taking care of the carry etc. Processors can do the same thing. In the "olden days" you had 8 bit processors that could do floating point math. But they were slooooooow. 


"32bit" is really a way of categorizing processors, not a setinstone ruling. a "32bit" processor typically has 32 bit general purpose registers to work with. However, there are no set in stone requirement that everything in the processor be done in 32bit. For example, it was not unheard of for a "32bit" computer to have a 28bit address bus, because it was cheaper to make the hardware. 64bit computers often only have a 40bit or 48bit memory bus for the same reason. Floating point arithmetic is another place where sizes vary. Many 32bit processors supported 64bit floating point numbers. They did so by storing the floating point values in special registers that were wider than the general purpose registers. To store one of these large floating point numbers in the special registers, one would first split the number across two general purpose registers, then issue an instruction to combine them into a float in the special registers. Once in those floating point registers, the values would be manipulated as 64bit floats, rather than as a pair of 32bit halves. The 80bit arithmetic you mention is a special case of this. If you have worked with floating point numbers, you are familiar with the imprecision that arises from floating point round off issues. One solution for roundoff is to have more bits of precision, but then you have to store bigger numbers, and force developers to use unusually large floating point values in memory. The Intel solution is that the floating point registers are all 80 bits, but the instructions to move values to/from those registers primarially work with 64bit numbers. As long as you operate entirely within Intel's x87 floating point stack, all of your operations are done with 80 bits of precision. If your code needs to pull one of those values out of the floating point registers and store it somewhere, it truncates it to 64bits. Moral of the story: categorizations like "32bit" are always hazier when you get deeper into things! 


A "32bit" CPU is one where most of the data registers are 32bit registers, and most of the instructions operate on data in those 32bit registers. A 32bit CPU is also likely to transfer data to and from memory 32bits at a time. Most of the registers being 32bit does not mean all of the registers are 32bit. The short answer is that a 32bit CPU can have some features that use other bitcounts, such as 80bit floating point registers and corresponding instructions. As @spudone said in a comment on @ultrasawblade's answer, the first x86 CPU to have integrated floatingpoint operations was the Intel i486 (specifically the 80486DX but not the 80486SX), which, according to Page 151 of the i486 Microprocessor Programmers Reference Manual, includes in its numerical registers "Eight individuallyaddressable 80bit numeric registers". The i486 has a 32bit memory bus, so transferring an 80bit value would take 3 memory operations. The predecessor to the 486 generation, the i386, did not have any integrated floatingpoint operations. Instead, it had support for using an external floating point "coprocessor", the 80387. This coprocessor had nearly the same functionality that was integrated into the i486, as you can see from Page 21 of the 80387 Programmer's Reference Manual. The 80bit floating point format seems to have originated with the 8087, the math coprocessor for the 8086 and 8088. The 8086 and 8088 were 16bit CPUs (with 16bit and 8bit memory buses), and were still able to use 80bit floating point format, by taking advantage of the 80bit registers in the coprocessor. 

