home *** CD-ROM | disk | FTP | other *** search
/ NetNews Usenet Archive 1992 #27 / NN_1992_27.iso / spool / comp / arch / 10825 < prev    next >
Encoding:
Internet Message Format  |  1992-11-17  |  3.5 KB
  1. Xref: sparky comp.arch:10825 comp.lang.misc:3734
  2. Path: sparky!uunet!snorkelwacker.mit.edu!ai-lab!life.ai.mit.edu!tmb
  3. From: tmb@arolla.idiap.ch (Thomas M. Breuel)
  4. Newsgroups: comp.arch,comp.lang.misc
  5. Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
  6. Date: 17 Nov 92 18:14:19
  7. Organization: IDIAP (Institut Dalle Molle d'Intelligence Artificielle
  8.     Perceptive)
  9. Lines: 72
  10. Message-ID: <TMB.92Nov17181419@arolla.idiap.ch>
  11. References: <TMB.92Nov14145619@pollux.idiap.ch> <Bxq7y0.IJ@mentor.cc.purdue.edu>
  12.     <mwm.2n6z@contessa.palo-alto.ca.us> <Bxr8vG.IpI@mentor.cc.purdue.edu>
  13.     <martin.721995695@bert>
  14. Reply-To: tmb@idiap.ch
  15. NNTP-Posting-Host: arolla.idiap.ch
  16. In-reply-to: martin@math.rwth-aachen.de's message of 17 Nov 92 10:21:35 GMT
  17.  
  18. In article <martin.721995695@bert> martin@math.rwth-aachen.de (  Martin Schoenert) writes:
  19.  
  20.    Thomas Breuel continues:
  21.  
  22.        (3) Many programming languages let you declare 32 and 64bit
  23.        integers explicitly and good compilers will select the right
  24.        instruction to go with the types (Ada and CommonLisp are
  25.        among those languages).
  26.  
  27.        Even the C language has provisions for just the case that you are
  28.        concerned with in the case of 16bit integers, 32bit longs:
  29.  
  30.            int a = ...;
  31.            int b = ...;
  32.            int c = ...;
  33.            long product = (long)a*(long)b;    [note correction]
  34.            int result = product/c;
  35.  
  36.        In fact, on some machines, int is 32bit and long is 64bit,
  37.        so this code will do what you want.
  38.  
  39.    Ahh, but the 16x16->32 bit multiplication is not as good.  Suppose that I
  40.    want to multiply two large integers, each 32 bytes long.  Using 16x16->32
  41.    bit multiplication I  need 256 such  instructions.
  42.  
  43. You are missing the point. The above paradigm was created when
  44. machines had 16bit integers and 32bit longs, and it worked pretty well
  45. back then.
  46.  
  47.    Thomas Breuel continues:
  48.  
  49.        Furthermore, C is being extended to allow access to 64bit types,
  50.        so that you can write:
  51.  
  52.            int a = ...;
  53.            int b = ...;
  54.            long long product = (long long)a*(long long)b; [note correction]
  55.            int result = product/c;
  56.  
  57.    This  may  be  so,  but it  isn't  really  relevant.   Bob  talked  about
  58.    *languages*,  you  talk about  *implementation* or  possible *extension*.
  59.    This is not the same thing.
  60.  
  61. It is quite relevant. Now that machines have 32bit integers and 64bit
  62. arithmetic as well, languages need to adapt.
  63.  
  64. Because integer sizes are machine specific, code that makes
  65. assumptions about it is not going to be both portable and efficient.
  66. To illustrate this, assume that C let you specify the size of integers.
  67. Then, you could write:
  68.  
  69.     int:32 a,b,c;
  70.     int:64 product = (int:64)a*(int:64)b;
  71.  
  72. That's fine, but will be rather inefficient on a 60bit machine with
  73. 30bit halfwords.
  74.  
  75. If anything, if you are going for efficiency, the C approach is more
  76. portable, saying that "int" is whatever is fastest and "long" gives
  77. you extra bits. "int" essentially used to mean "CPU register size" and
  78. "long" was largely intended to mean "probably twice CPU registers
  79. size, which coincidentally is what multiply may give you, unless
  80. that's too inconvenient". The only problem with this approach was
  81. that the early C compilers for 32bit machines messed up and didn't
  82. make "long" 64bits.
  83.  
  84. So again, the problem of having machine independent access to machine
  85. specific features hasn't been solved because it's inherently not
  86. solvable. With somewhat better conventions, however, we might be able
  87. to do a little better than we are doing now.
  88.  
  89.                     Thomas.
  90.