home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #20 / NN_1992_20.iso / spool / comp / arch / 9369 < prev    next >
Encoding:
Internet Message Format  |  1992-09-11  |  3.0 KB
  1. Xref: sparky comp.arch:9369 comp.lang.misc:3030
  2. Path: sparky!uunet!zaphod.mps.ohio-state.edu!usc!sdd.hp.com!hp-cv!ogicse!orstcs!orstcs!usenetusenet
  3. From: crowl@jade.CS.ORST.EDU (Lawrence Crowl)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Goals, Cost, and Flexibility (was Re: "Training" of programmers)
  6. Message-ID: <1992Sep11.184744.19329@CS.ORST.EDU>
  7. Date: 11 Sep 92 18:47:44 GMT
  8. Article-I.D.: CS.1992Sep11.184744.19329
  9. References: <Btx4vF.Jx6@mentor.cc.purdue.edu> <1992Sep4.151001.9886@sei.cmu.edu> <Bu5qD3.GAM@mentor.cc.purdue.edu>
  10. Sender: usenet@CS.ORST.EDU
  11. Organization: Oregon State University, Corvallis Oregon
  12. Lines: 51
  13. Nntp-Posting-Host: jade.cs.orst.edu
  14.  
  15. In article <Bu5qD3.GAM@mentor.cc.purdue.edu>
  16. hrubin@pop.stat.purdue.edu (Herman Rubin) writes:
  17. >And then the hardware designers, being told that something is useless, drop
  18. >it from the instruction set?
  19.  
  20. You misunderstand what has happened in the industry.  The hardware designers
  21. were told that something was rarely used, and therefore was not cost
  22. effective.  As good engineers, they dropped the feature.
  23.  
  24. >Designing flexibility in both hardware and software is not that expensive;
  25. >putting in something left out may be.
  26.  
  27. My experience is just the opposite.  Designing flexibility in either hardware
  28. or software is very expensive.  Given the time to program a simple utility
  29. with one option versus one with twenty supports this claim.  The time to build
  30. an shifter of constant shift versus one of variable shift also supports this
  31. claim.  I invite you to provide _evidence_ in support of your claim.
  32.  
  33. I grant you, putting something in later will be expensive.
  34.  
  35. >A simple example is that of square root.  The cost of putting in square root
  36. >on any machine which has "classical" division hardware is essentially zero
  37. >at the design and construction stage, but an algorithm to do it is otherwise
  38. >is necessarily slow and costly.
  39.  
  40. Only costly when making simplistic comparisons.  If the lack of square root
  41. hardware increases my run time from 10 seconds to 10.0001 seconds (which is
  42. probably realistic for many if not most program runs), it is _not_ costly.
  43.  
  44. >Bit vectors do not necessarily start on a word, or even a byte, boundary,
  45.  
  46. Yes, but if only one in a million don't, supporting non-aligned bit vectors
  47. probably isn't cost effective.
  48.  
  49. >and again, it is easier to deal with the problem at hardware design time
  50. >rather than in software.
  51.  
  52. This claim is strongly supported by the wide abundance of hardware-implemented
  53. compilers and spreadsheet packages.  :-)  My experience indicates that the
  54. cost to deliver a working solution to _almost_any_ problem is cheaper in
  55. software than hardware.  Consider the cost of building a working multiplier
  56. versus the cost of writing an iterative adding subroutine.  I invite you to
  57. provide _evidence_ that your claim is true.
  58.  
  59. What you meant to say is "its easier for me if the hardware designers gave me
  60. exactly what I wanted".
  61.  
  62. -- 
  63.   Lawrence Crowl        503-737-2554    Computer Science Department
  64.                crowl@cs.orst.edu    Oregon State University
  65.           ...!hplabs!hp-pcd!orstcs!crowl    Corvallis, Oregon,  97331-3202
  66.