home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #18 / NN_1992_18.iso / spool / comp / arch / 8875 < prev    next >
Encoding:
Internet Message Format  |  1992-08-12  |  2.7 KB
  1. Xref: sparky comp.arch:8875 alt.folklore.computers:12473 vmsnet.pdp-11:611
  2. Path: sparky!uunet!gatech!rutgers!dziuxsolim.rutgers.edu!zodiac.rutgers.edu!leichter
  3. From: leichter@zodiac.rutgers.edu
  4. Newsgroups: comp.arch,alt.folklore.computers,vmsnet.pdp-11
  5. Subject: Re: Unnormalized FP and a PDP-11 bug (Re: Algorithm for bit finding)
  6. Message-ID: <1992Aug12.075553.1@zodiac.rutgers.edu>
  7. Date: 12 Aug 92 11:55:53 GMT
  8. References: <BsFMD4.HAI@watcgl.uwaterloo.ca> <55926@mentor.cc.purdue.edu> <1992Aug5.215915.9787@thinkage.on.ca> <BsKqyz.JLB@watcgl.uwaterloo.ca>
  9. Sender: news@dziuxsolim.rutgers.edu
  10. Followup-To: comp.arch
  11. Organization: Rutgers University Computing Services
  12. Lines: 32
  13. Nntp-Posting-Host: cancer.rutgers.edu
  14.  
  15. In article <BsKqyz.JLB@watcgl.uwaterloo.ca>, awpaeth@watcgl.uwaterloo.ca
  16. (Alan Wm Paeth) writes:  [Describes problme on PDP-11 with using FP operations
  17. to copy non-FP data, because the FP unit would normalize the values.]
  18.  
  19. There've been a number of responses to this, including responses from people
  20. who I KNOW are familiar with PDP-11 (and VAX) format FP numbers, and they all
  21. neglect to point out a fundamental flaw with the story as told:  The format
  22. uses a hidden bit representation, so the in-memory value is NOT "normalized"
  23. (in the sense that the most significant STORED bit is 0 about half the time).
  24. An FP unit that tried to "normalize" a value like this to get rid of the 0
  25. top bit would not be doing the FP arithmetic of this universe.
  26.  
  27. What probably was REALLY going on was that some data consisted of "false
  28. zeros" - a zero sign bit, zero exponent, and non-zero significand.  I don't
  29. have a 11/45 manual handy, but my 1979 PDP11 Processor Handbook does,
  30. indeed, not explicitly state that a "false zero" will be converted to a
  31. "true zero" (all zero bits) by a LDF or LDD.  (On the other hand, a sign bit
  32. of 1 with an exponent or 0 - "-0" or "undefined variable" in -11 terminology,
  33. "Reserved Operand" in VAX terminology - can trap during a load, so a prudent
  34. ISP abuser might suspect that something might happen to "false zeros".)
  35.  
  36.                             -- Jerry
  37.  
  38. (My favorite story of a simliar problem is on the CDC 6000 series.  They
  39. use 1's complement arithmetic, and when you load a B register, you can't
  40. really load a constant - you load contant plus some other B register.  No
  41. problem:  B0 is always 0, so you add it.  Except that in one's complement
  42. there is also -0 (all 1 bits), and the arithmetic unit tries very hard never
  43. to generate -0 as an output.  In fact, 0+(-0) is 0.  So you can't load -0 that
  44. way!  The trick is to realize that the REAL identity for addition on this
  45. machine is -0, and get that into a register (using bit-wise operations) for
  46. use in place of 0 when loading data that isn't really numbers.)
  47.