home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 11026 < prev    next >
Encoding:
Internet Message Format  |  1992-11-23  |  3.0 KB
  1. Xref: sparky comp.arch:11026 comp.lang.misc:3843
  2. Path: sparky!uunet!pipex!warwick!uknet!comlab.ox.ac.uk!nnhost!pcl
  3. From: pcl@oxford.ac.uk (Paul Leyland)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Message-ID: <PCL.92Nov23140711@black.oxford.ac.uk>
  7. Date: 23 Nov 92 14:07:11 GMT
  8. References: <TMB.92Nov14145619@pollux.idiap.ch> <Bxq7y0.IJ@mentor.cc.purdue.edu>
  9.     <mwm.2n6z@contessa.palo-alto.ca.us> <Bxr8vG.IpI@mentor.cc.purdue.edu>
  10.     <martin.721995695@bert> <TMB.92Nov17181419@arolla.idiap.ch>
  11. Organization: Oxford University Computing Service, 13 Banbury Rd, Oxford, OX2
  12.     6NN
  13. Lines: 51
  14. In-reply-to: tmb@arolla.idiap.ch's message of 17 Nov 92 18:14:19 GMT
  15.  
  16. In article <TMB.92Nov17181419@arolla.idiap.ch> tmb@arolla.idiap.ch (Thomas M. Breuel) writes:
  17.  
  18.  
  19.  
  20. Lot's of stuff about double-length multiplies deleted, then:
  21.  
  22.    If anything, if you are going for efficiency, the C approach is more
  23.    portable, saying that "int" is whatever is fastest and "long" gives
  24.    you extra bits. "int" essentially used to mean "CPU register size" and
  25.    "long" was largely intended to mean "probably twice CPU registers
  26.    size, which coincidentally is what multiply may give you, unless
  27.    that's too inconvenient". The only problem with this approach was
  28.    that the early C compilers for 32bit machines messed up and didn't
  29.    make "long" 64bits.
  30.  
  31.  
  32. If only it was that simple.  Ten years ago, I was working part-time
  33. for a company building a bit-slice mini.  It had a 32-bit alu and was
  34. quite capable of performing 32x32=>64 and 64/32=>32,32.  I wrote the
  35. great majority of the microcode, and played a significant part in
  36. defining the architecture.  I also did a lot of multi-precision
  37. integer work, and argued that longs should be 64-bits; partly for
  38. elegance, partly for performance reasons.  I wrote the microcode to
  39. support those instructions.
  40.  
  41. We then came to port an operating system (BSD 4.0 I think, though
  42. itmay have been 4.1).
  43.  
  44. It was a real eye-opener to find out how many pieces of code *knew* a
  45. long was 32 bits long.
  46.  
  47.  
  48. Faced with the unsurmountable opportunities of changing hundreds of
  49. kilolines of kernel and utilities, we chickened out.  It was bad
  50. enough, fixing everything that knew address zero was readable and
  51. contained zero; and others that knew stacks grew towards lower
  52. addresses; and others that knew it was safe to calculate addresses
  53. outside of arrays, so long as you didn't use them before calculating
  54. another offset to bring them back in bounds, and ...
  55.  
  56. Still, I was able to have an instruction which returned the smallest
  57. prime factor of a 64-bit unsigned integer operand on the stack, even
  58. if I did have to load my own ucode and use an asm statement 8-)
  59.  
  60.  
  61. Paul
  62. --
  63. Paul Leyland <pcl@oxford.ac.uk>          | Hanging on in quiet desperation is
  64. Oxford University Computing Service      |     the English way.
  65. 13 Banbury Road, Oxford, OX2 6NN, UK     | The time is come, the song is over.
  66. Tel: +44-865-273200  Fax: +44-865-273275 | Thought I'd something more to say.
  67.