Each CPU has an ALU (the latest models have a few of them already), which receives all instructions and data for integer operations. This is usually one of the fastest processor units in terms of clock frequency. Roughly speaking, the working algorithm of this unit looks as follows: the data arrive (two integer values: 3 and 4), the instruction arrives (multiplication), the outgoing result equals 12. Addition, subtraction, division, etc., are all effected the same way.

Of course, it doesn’t matter if we use the numbers in 4bit or 64bit representation: the algorithm will remain the same. ALU receives the numbers, applies certain instructions to them and produces the result. Certainly, it is potentially possible to split this part of the algorithm into two parallel ones, by finding two pairs of numbers and a pair of operations to be performed, which wouldn’t affect one another. This is a pretty rare situation (that is actually why we use a set algorithm, i.e. a chain of sequential steps), but it is not completely impossible. Contemporary programs have enough procedures, which are not connected with one another in any way.

Then you can ask: what do the registers have to do with all that? As we have already said, the data should be loaded to the processor ALU from a certain source. The source can be of any type: starting with the system hard disk drive and finishing with the processor cache. From the processor cache the data get directly to the CPU, to the data storage unit, which is not very big, but quite fast. However, this unit cannot be placed close enough to the ALU for physical reasons, that is why there are special transitional blocks for temporary data storage working very fast and known as registers.

This is exactly where the data for the processor ALU come from. And for the ALU the “3x4”operation will most probably sound like: “register A multiplied by register B and save the result in one of the registers” (maybe even in one of the registers already involved into this operation). Later on the result can be taken from this register for further processing, or may be saved in the RAM, so that the sacred space could be free. When we are talking about the processor capacity, we first of all imply the registers capacity, i.e. if they can store 8, 16, 32 or 64bit numbers.

When it comes to broken numbers, namely to floating point numbers, the situation changes completely. Much bigger capacity is evidently required to store and process them properly. Of course, as you can definitely imagine how many digits should be usually stored for numbers like that. Especially, if you need to perform high precision calculations with a lot of digits after the dot. However, since they started using these numbers not yesterday, no one was going to wait until 64bit processors arrive.

There is a separate x87 instructions set working with the floating-point numbers. There are special computational units organized in a co-processor, which deal with these numbers. The numbers are stored and processed in a special internal format with 80bit representation. So, everything is alright here, and the floating-point numbers were not the ones to cause the changes. Especially, since this direction takes its own autonomous way: SSE, 3DNow!, etc. In other words, the transition from 32bit to 64bit has very little influence here.