The effects of buggy microcode are usually not quite so pernicious as the one that haunts a couple million Pentia. If a program hangs, or goes barmy, you tend not to respect the numbers it has just generated. You are also motivated to change the program until it avoids acting demonstrably nutty.

But when the numbers look fine, or maybe just a little suspicious, you're more inclined to doubt your intuition. After all, the whole idea of computers is to be very fast and very accurate in doing rather stupid things. We neither expect nor want creativity in floating-point arithmetic.

I've been writing and testing math functions for several decades now. While I keep getting better at it, I still confess to shipping more than a few buggy lines of code. It's horribly easy to lose bits of precision, particularly for extreme argument values, and not catch the problem even with a fairly responsible test discipline. When you're piecing together a multipart result — as the Pentium evidently does on a floating-point divide — it's easy to lose a bit or two out of the middle as well.

Where I fault Intel is in their public relations. You don't hide such a serious flaw from your customers. When it becomes widely known, you don't pooh pooh legitimate expressions of concern. And when you fix the product, you don't make customers jump through hoops to prove they deserve a properly functioning replacement. At least Intel eventually had the sense to wise up and apologize.

I have observed more than once that software is seen more as a subscription service than a one-time sale. I have also predicted that the increasing use of microcode, ROMs, and EPROMs will shift the perception of more and more hardware in the same direction. Intel, to their credit, has created a mass market that expects regular and dramatic improvements in processor technology. It's too bad for them that they were slow to recognize the change in public perception that comes with this success, and to act accordingly.

Those of us who deliver products based on C and C++ should view this episode as a cautionary tale. We need to check our work as thoroughly as budgets and schedules allow. Then we need to stand ready to fix the bugs that inevitably go out the door. For many of us, writing software is a happy end in itself, but to our customers the software is just a means to a different end.

P.J. Plauger
pjp@plauger.com