Take the 2-minute tour ×
Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. It's 100% free, no registration required.

I'm trying to wrap my head around some details about how floating point math is performed on the CPU, trying to better understand what data types to use etc.

I think I have a fairly good understanding of how integer math is performed. If I've understood correctly, and disregarding SIMD, a 32-bit CPU will generally perform integer math at at least 32-bit precision etc.

Is it correct that floating-point math is dependent on the presence of a FPU? And that the FPU on the x86 is 80-bit, so floating point math is performed at this precision unless using SIMD? What about ARM?

share|improve this question
add comment

3 Answers

up vote 5 down vote accepted

Many times, operations like floating point and memory management are encoded in a way that they can be "trapped". This means that the system can be configured to either use hardware or automatically branch to a software implementation. In the case of software, the implementation can be anything, although most manufacturers supply libraries that follow accepted standards (IEEE-754 in the case of floating point). In many systems, when a floating-point unit or other chip is installed, the instruction execution is automatically deferred to the new chip, so no software reconfiguration is necessary.

As I understand it, the ARM architecture does something very similar to the x86, with floating-point instructions that trap to software emulation if no FPU hardware is found.

share|improve this answer
    
If I understand it correctly from the article, the ARM will also generally work in 80 bit precision if it has an FPU? –  Jo-Herman Haugholt Nov 21 '11 at 13:51
1  
It uses 80-bit precision internally, but results are given in either single-precision (32 bits) or double-precision (64 bits), in accordance with the IEEE standard. Note that the ARM permits manufacturers to supply any type of FPU, so you can't guarantee anything beyond IEEE-754 compliance (and possibly not even that). –  TMN Nov 21 '11 at 14:23
add comment

If you understand C datatypes - it can support following formats:

The number of bits is distributed as : {Sign + Exponent + Significand }

float -which is 32 bits distributed as 1 + 8 + 23.
dbouble -which is 64 bits distributed as 1 + 11 + 52.
Extended double - which is 80 bits dist. as 1 + 15 + 64.

So the extended double with 80 bits precision is the largest length float that can be natively supported by C in x86. Remember, that if your variable is float (32 bits) it still has precision equivalent to 32 bits not as per 80 bits in final storage. However, in most CPUs, the ALUs and FPUs are usually larger than native word length so that intermediate results do not overflow.

To support any precision better than above, additional software support is required. It is possible to create such higher precision arithmetic (e.g. cryptographic routines that generates arithmetic which are anything from 128 to 1024 bits; but this additional support is generated from software.)

share|improve this answer
add comment

You do not need floating point hardware to use floating point math.

IEEE-754 has a number of floating point lengths 80, 64, 32 and now a 16. There are other non-ieee floating point formats. The IEEE format/standard is very painful, almost all of the features are wasted, few know them, and few or none of the languages give you the ability to use them. With compliant hardware you can still fail to meet the spec because the software/operating system is part of it. You are required to provide different answers depending on whether exceptions are trapped for example. You would find non-IEEE floating point formats in DSP's for speed, processor size, etc. They were more closely tuned with what you really used the fpu for and not everything we could ever want and the kitchen sink approach that the IEEE standard uses.

Not every hardware fpu supports every length.

fpu bugs are often solved by not using the hardware for the broken instruction, or the broken instruction is wrapped by software to fix any problems. Hardware may have gotten better in the last 5-10 years but it was difficult to find a hardware fpu without any bugs. To avoid the pentium embarrassment all over again you would need or at least want to fix the bugs in software. the difficulty of the IEEE spec is why it is rare to find a system that completely meets the spec. fixing the bug in software gets into compilers and operating systems, unless you control all three (hardware, compiler, operating system) you are likely to fail that as well.

Normally you compile your program knowing what you expect to run against, at least with ARM you compile for hard float or soft float. It is certainly possible to have the floating point library detect and then use the appropriate solution from there on out so that one binary will work on both. You have to examine each compiler separately to know what the solutions/rules are. Compilers tend to know what platforms normally dont support it and build for soft float by default and other platforms that normally or always have an fpu and normally build for a hardware fpu for example.

Trying to decide when to use it? As a general rule, avoid it unless you really, really, need it. When you do use it there are many many ways to use it wrong, understand how to use it without wasting it, or without getting the wrong answer. You might have been better off with integer math or keeping track of the decimal place yourself.

share|improve this answer
    
x87 80-bits format is not from IEEE754. The latter defined 128-bit format (in 2008 edition). Other your statements are also quite confusing. Do you describe some very specific (definitely not x86 mainstream) hardware? –  Netch Oct 22 '13 at 5:46
add comment

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.