TO:	Whomever It May Concern
FROM:	Dr. Thomas R. Nicely, Lynchburg College, Lynchburg, Virginia
	(nicely@acavax.lynchburg.edu)
RE:	Pentium Bug and Intel NDA
DATE:	94.11.25.1540 EST

This is in reply to Paul Rubin's (phr@netcom.com) inquiry of 23 November.

* I signed a temporary nondisclosure agreement with Intel on 10 November.
* There was no coercion or threat of any kind, by either party.
* The NDA was signed in the course of discussions to determine
  whether or not an agreement (such as a consultancy) could be reached
  which would prove beneficial in the long term to myself, to the Intel
  Corporation, and to my employer, Lynchburg College.
* From 10 November until 22 November, I deflected all inquiries regarding
  the Pentium FPU to Intel's representatives.  This was a consequence of
  my own mistaken interpretation of the NDA; I was treating it in the
  manner of a security clearance; I once held a clearance for secret
  restricted data in X-division (nuclear weapon design and analysis)
  at Los Alamos National Laboratory, and that clearance treated most
  information concerned as "born secret," even if the information was
  acquired prior to the clearance and/or independently.  In the same
  spirit, I removed from the College's VAX anonymous FTP directory
  copies of the codes used to analyze the Pentium chip for the bug.
* After receiving some complaints in this regard, Intel (on its own
  initiative) informed me on 22 November that I was free to discuss publicly
  the discovery and nature of the Pentium FPU bug, since this was my own
  work, accomplished prior to signing the NDA and without assistance from
  Intel; and that the primary purpose of the NDA was to insure
  confidentiality of information exchanged in the course of any consulting
  I might do for Intel in the future.
* To this date, Intel has been most cooperative in alleviating difficulties
  caused for my own research (computational number theory; distribution of
  twin primes and other constellations, and the sums of their reciprocals)
  by the presence of the bug.  They have shipped replacement chips for the
  CPUs in the machines I am using, and I have verified that the new chips
  are free of the bug (zero errors in > 1e15 simulated random divisions).
* I cannot speak for Intel regarding its policies on CPU replacement for
  Pentium systems having the bug; that is a management decision which
  obviously must take into account the constraints of supply, inventory,
  logistics, expense, and public relations.  To date, I believe Intel has
  handled the affair in essentially the manner that could usually be
  expected of most businesses operating in a highly competitive, low-margin,
  capital-intensive environment.  Any Pentium owner who feels the need for a
  replacement CPU should contact Intel Customer Service and Tech
  Support at 800-628-8686, or Intel representative John Thompson at
  408-765-1279.
* I probably have a somewhat different perspective on the bug than most
  users.  It is my opinion that the current generation of microprocessors
  (and possibly all of them since, say, the 8080) has become so complex
  that it is no longer possible to completely debug them, or even to
  determine every bug that exists in one.  Thus, the discovery of this
  particular bug should not be any great surprise.  There have been many
  well-publicized bugs in the past (e.g., the 32-bit multiply bug in the
  early 80386s, the arctangent bug in the early 80486s, the stack-handling
  bug in the early 8088s, and the Motorola 68K revision F bug).
  Furthermore, in view of this, all mission-critical computations should
  be performed multiple times, in settings as independent as possible---
  preferably with different CPUs, operating systems, and software
  algorithms.  Where different platforms are not available, the same
  computation should be performed using algorithms as independent as
  possible; this was in fact how I pinpointed the Pentium bug---the
  sums of the reciprocals of the twin primes were being done in both
  long double floating point (64 significant bits) and in extended
  precision using arrays of integers (26 decimal digits at that time,
  53 decimal digits currently).  Dual calculations were also being run
  on 486 and Pentium systems.
* Note that the bug can be temporarily circumvented by locking out
  the FPU.  For most DOS applications, this can be done by means of the
  DOS commands SET 87=NO (for executables created by Borland compilers)
  and SET NO87=NO87 (for executables created by Microsoft compilers).
  Of course, this is at best a performance-killing band-aid; some
  applications require an FPU, while Windows and most DOS extenders
  ignore these environmental variables.  In theory, it should be
  possible to write a fairly short (100 lines?) utility code which
  enters protected mode (ring 0), sets up a valid global descriptor table
  (and perhaps a valid interrupt descriptor table), resets the emulation
  bit in the machine status word of control register 0, and then re-enters
  real mode.  Running such a code at boot time should lock out the FPU
  even for Windows and DOS extended applications; a similar code could
  reactivate the FPU at will.  Unfortunately, I haven't had the time to
  write the code yet!
* To date, my analysis indicates that the bug will appear in about 1 in
  31 billion random divisions and 1 in 1.26 billion random reciprocals.
  These figures are similar to the rate of 1 in 9.5 billion attributed to
  Intel.  In my own application (distribution of twin primes and the sum
  of their reciprocals) no error appeared for values < 824e9.  Most users
  will find these values reassuring; those of us doing computational
  number theory, chaos theory, or analysis of ill-conditioned matrices
  may still want a new, bug-free CPU.
* To date, the worst-case error of which I am aware is an example
  apparently posted by Tim Coe of Vitesse Semiconductors on 14 November,
  indicating that the quotient 4195835.0/3145727.0 is returned correctly
  to only 14 significant bits (5 significant decimal digits).  I have not
  yet had a chance to verify this example.
* Copies of some of the codes I have used to analyze the bug (updated to
  reflect later developments) will be restored to the anonymous FTP
  directory [anonymous.nicely.pentbug] of Lynchburg College's VAX server
  (machine ID acavax.lynchburg.edu) as soon as I get time to update and
  post them.
* Feel free to transmit this communication as you wish.
 
Sincerely,

Dr. Thomas R. Nicely

