home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10998 < prev    next >
Encoding:
Internet Message Format  |  1992-11-21  |  2.6 KB
  1. Xref: sparky comp.arch:10998 comp.lang.misc:3830
  2. Path: sparky!uunet!mcsun!sun4nl!cwi.nl!dik
  3. From: dik@cwi.nl (Dik T. Winter)
  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: <7958@charon.cwi.nl>
  7. Date: 22 Nov 92 00:18:15 GMT
  8. References: <martin.721995695@bert> <martin.722176263@bert> <TMB.92Nov20140542@arolla.idiap.ch>
  9. Sender: news@cwi.nl
  10. Followup-To: comp.arch
  11. Organization: CWI, Amsterdam
  12. Lines: 35
  13.  
  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. Perhaps this is indeed true, although I do not know what the real solution
  25. is for this problem.  The first step when installing my package (which
  26. contains Assembler, Fortran and C) is to first fix-up all machine
  27. dependencies.  I.e. machine dependent header files and source files are
  28. picked up.  (And indeed it is also possible to create a machine independent
  29. version, although not as efficient as the others.)  One of the things defined
  30. in the machine dependent header files is the number of bits to use.  For
  31. some reason I use 30 bits on most 32 bit machines (and in general two bits
  32. less than the word size), but there are exceptions:
  33.     Cray: only 23 bits used of the 64 available.
  34.     MIPS, i860: only 26 bits used of the 32 available.
  35. and possibly some more between those ~40 machines to which I ported the
  36. stuff.  All this is for efficiency.  On the i860 there is no integer
  37. multiply, only fp multiply, so the double multiply is used (actually
  38. some strange derivative of that operation).  Similar observations hold
  39. for Cray.  MIPS does have integer multiply, but I found that the code
  40. using fp multilpy was faster (this is true on the R3000 and earlier,
  41. one of these days I should check the R4000).  This is true even though
  42. we need more operations.  (One of these days I should try the same on SPARC.)
  43.  
  44. As I said, I do not know what the real solution is, it is certainly not
  45. as clear-cut as Herman thinks.
  46. -- 
  47. dik t. winter, cwi, kruislaan 413, 1098 sj  amsterdam, nederland
  48. home: bovenover 215, 1025 jn  amsterdam, nederland; e-mail: dik@cwi.nl
  49.