floating point arithmatic

[feroz]

can any body able to explain about floating point arithmatic. specially multiplication. some regarding this if possible...
thax

 

[drwho78]

You can start here:

http://www2.hursley.ibm.com/decimal/

 

[nand_gates]

See the link below!

http://www-ee.eng.hawaii.edu/~msmith/pJ/SUNv2/picoJava-II/docs/design_html/hierarchy-f.html

here you will find verilog code for fpu of picojavaII processor!!

 

[xworld2008]

I think IEEE have a standard about float point, you can try find it.

 

[artem]

**broken link removed**

 

[justin.li]

The idea that IEEE 754 prescribes precisely the result a given program must
deliver is nonetheless appealing. Many programmers like to believe that they
can understand the behavior of a program and prove that it will work correctly
without reference to the compiler that compiles it or the computer that runs it.
In many ways, supporting this belief is a worthwhile goal for the designers of
computer systems and programming languages. Unfortunately, when it comes
to floating-point arithmetic, the goal is virtually impossible to achieve. The
authors of the IEEE standards knew that, and they didn’t attempt to achieve it.
As a result, despite nearly universal conformance to (most of) the IEEE 754
standard throughout the computer industry, programmers of portable software
must continue to cope with unpredictable floating-point arithmetic.
If programmers are to exploit the features of IEEE 754, they will need
programming languages that make floating-point arithmetic predictable. C9X
improves predictability to some degree at the expense of requiring
programmers to write multiple versions of their programs, one for each
FLT_EVAL_METHOD. Whether future languages will choose instead to allow
programmers to write a single program with syntax that unambiguously
expresses the extent to which it depends on IEEE 754 semantics remains to be
seen. Existing extended-based systems threaten that prospect by tempting us
to assume that the compiler and the hardware can know better than the
programmer how a computation should be performed on a given system. That
assumption is the second fallacy: the accuracy required in a computed result
depends not on the machine that produces it but only on the conclusions that
will be drawn from it, and of the programmer, the compiler, and the hardware,
at best only the programmer can know what those conclusions may be.

 

[drwho78]

IEEE 754-1985:

 

[caplash_vlsi]

u can refer to patterson....very gud block diagram of a fp adder is given.....also refer to ieee 754 paper on floating point.....given with this link....hope this will help u....

 

[rakesh1234]

The idea that IEEE 754 prescribes precisely the result a given program must
deliver is nonetheless appealing. Many programmers like to believe that they
can understand the behavior of a program and prove that it will work correctly
without reference to the compiler that compiles it or the computer that runs it.
In many ways, supporting this belief is a worthwhile goal for the designers of
computer systems and programming languages. Unfortunately, when it comes
to floating-point arithmetic, the goal is virtually impossible to achieve. The
authors of the IEEE standards knew that, and they didn’t attempt to achieve it.
As a result, despite nearly universal conformance to (most of) the IEEE 754
standard throughout the computer industry, programmers of portable software
must continue to cope with unpredictable floating-point arithmetic.
If programmers are to exploit the features of IEEE 754, they will need
programming languages that make floating-point arithmetic predictable. C9X
improves predictability to some degree at the expense of requiring
programmers to write multiple versions of their programs, one for each
FLT_EVAL_METHOD. Whether future languages will choose instead to allow
programmers to write a single program with syntax that unambiguously
expresses the extent to which it depends on IEEE 754 semantics remains to be
seen. Existing extended-based systems threaten that prospect by tempting us
to assume that the compiler and the hardware can know better than the
programmer how a computation should be performed on a given system. That
assumption is the second fallacy: the accuracy required in a computed result
depends not on the machine that produces it but only on the conclusions that
will be drawn from it, and of the programmer, the compiler, and the hardware,
at best only the programmer can know what those conclusions may be.