SI
SI
discoversearch

We've detected that you're using an ad content blocking browser plug-in or feature. Ads provide a critical source of revenue to the continued operation of Silicon Investor.  We ask that you disable ad blocking while on Silicon Investor in the best interests of our community.  If you are not using an ad blocker but are still receiving this message, make sure your browser's tracking protection is set to the 'standard' level.
Technology Stocks : IS INTC A GROWTH STOCK?
INTC 37.24-2.8%Nov 6 3:59 PM EST

 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext  
To: Yaacov who wrote (64)5/6/1997 7:04:00 PM
From: Edgar Costello   of 243
 
About the INTEL bug :

From : x86.org

"The bug relates to operations that convert floating point numbers into integer numbers. Floating point
numbers are stored inside of the microprocessor in an 80-bit format. Integer numbers are stored in two
different sizes. A short integer is stored in 16-bits, and a long integer is stored in 32-bits. It is often desirable
to store the 80-bit floating point numbers as integer numbers. Sometimes the converted number won't fit into
the smaller integer format. This is when the bug occurs.

The host software is supposed to be warned by the microprocessor when such a floating point conversion
error occurs; a specific error flag is supposed to be set in a floating point status register. If the
microprocessor fails to set this flag, it would not be in compliance with the IEEE Floating Point Standards
which mandate such behavior. For the Dan-0411 bug, the Pentium II and Pentium Pro processors fail to set
this error flag in many cases.

This bug appears to affect 231 + 247 different floating point numbers. That's approximately
140,739,635,839,000 different floating point numbers that result in the incorrect behavior. The Pentium,
Pentium with MMX Technology, and AMD K6 microprocessors do not appear to have this problem.

It might be interesting to note that a launch failure of the Ariane 5 rocket, which happened less than a minute
into the launch, was traced to behavior around an overflow condition (in this case, it was software, not
hardware, that was the problem). One of the computers on board had a floating point to integer conversion
that overflowed, but because the overflow was not handled by the software the computer did a dump of its
memory. Unfortunately, this memory dump was interpreted by the rocket as instructions to its rocket nozzles.
Result--boom! "
Report TOU ViolationShare This Post
 Public ReplyPrvt ReplyMark as Last ReadFilePrevious 10Next 10PreviousNext