home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 11002 < prev    next >
Encoding:
Internet Message Format  |  1992-11-15  |  2.9 KB
  1. Xref: sparky comp.arch:11002 comp.lang.misc:3832
  2. Newsgroups: comp.arch,comp.lang.misc
  3. Path: sparky!uunet!cs.utexas.edu!sun-barr!ames!purdue!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
  4. From: hrubin@pop.stat.purdue.edu (Herman Rubin)
  5. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Message-ID: <By4Dwr.78r@mentor.cc.purdue.edu>
  7. Sender: news@mentor.cc.purdue.edu (USENET News)
  8. Organization: Purdue University Statistics Department
  9. References: <martin.722176263@bert> <TMB.92Nov20140542@arolla.idiap.ch> <7958@charon.cwi.nl>
  10. Date: Sun, 22 Nov 1992 13:38:51 GMT
  11. Lines: 42
  12.  
  13. In article <7958@charon.cwi.nl> dik@cwi.nl (Dik T. Winter) writes:
  14. >In article <TMB.92Nov20140542@arolla.idiap.ch> tmb@idiap.ch writes:
  15. > > I think it might well be worth trying to standardize an interface to
  16. > > arithmetic that provides you with access to the low-level arithmetic
  17. > > primitives that you need. However, in order to make your code truly
  18. > > portable, you will need to come up with an interface that takes into
  19. > > account that there are machines with odd word sizes. Such a facility
  20. > > needs to have a much more abstract and much more task-specific than a
  21. > > general facility for accessing "low-level features". That is precisely
  22. > > why I think that Rubin and Silverman are barking up the wrong tree.
  23.  
  24.     [Excellent discussion by Dik Winter of some of the problems deleted.]
  25.  
  26. >As I said, I do not know what the real solution is, it is certainly not
  27. >as clear-cut as Herman thinks.
  28.  
  29. I never said that the solution is clear-cut.  I do not think we are 
  30. anywhere near a passable solution.  What others and I, looking at this
  31. problem, have suggested is that improved access to the hardware, and 
  32. improved means of communicating to the compilers, assemblers, etc., 
  33. be provided, with as much flexibility as possible.  
  34.  
  35. Since the problem is that complicated, the means of communication must be
  36. greatly enhanced.  My suggestion for a versatile macro processor has not,
  37. as far as I can tell, been met by what has been suggested.  The macro
  38. processor I have in mind is one where I can write out a transformation,
  39. describe it, and you can take my description, modify it slightly to your
  40. environment, and implement it in your production of code.
  41.  
  42. Full efficiency of code can be attained by hand-optimization, with whatever
  43. aid one can get from computers, for a given machine.  But there are aspects
  44. of a program which are at least partially portable, and certainly more 
  45. comprehensible in some other form than assembler, especially the current
  46. assemblers.  The improvements can only be made incrementally, and whenever
  47. some aspect of the problem is considered, complications are likely to arise.
  48.  
  49.  
  50. -- 
  51. Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
  52. Phone: (317)494-6054
  53. hrubin@snap.stat.purdue.edu (Internet, bitnet)  
  54. {purdue,pur-ee}!snap.stat!hrubin(UUCP)
  55.