Article View: comp.arch
Article #11391Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)
From: Dik T. Winter
Date: Sun, 22 Nov 1992 00:18
Date: Sun, 22 Nov 1992 00:18
35 lines
2705 bytes
2705 bytes
In article <TMB.92Nov20140542@arolla.idiap.ch> tmb@idiap.ch writes: > I think it might well be worth trying to standardize an interface to > arithmetic that provides you with access to the low-level arithmetic > primitives that you need. However, in order to make your code truly > portable, you will need to come up with an interface that takes into > account that there are machines with odd word sizes. Such a facility > needs to have a much more abstract and much more task-specific than a > general facility for accessing "low-level features". That is precisely > why I think that Rubin and Silverman are barking up the wrong tree. > Perhaps this is indeed true, although I do not know what the real solution is for this problem. The first step when installing my package (which contains Assembler, Fortran and C) is to first fix-up all machine dependencies. I.e. machine dependent header files and source files are picked up. (And indeed it is also possible to create a machine independent version, although not as efficient as the others.) One of the things defined in the machine dependent header files is the number of bits to use. For some reason I use 30 bits on most 32 bit machines (and in general two bits less than the word size), but there are exceptions: Cray: only 23 bits used of the 64 available. MIPS, i860: only 26 bits used of the 32 available. and possibly some more between those ~40 machines to which I ported the stuff. All this is for efficiency. On the i860 there is no integer multiply, only fp multiply, so the double multiply is used (actually some strange derivative of that operation). Similar observations hold for Cray. MIPS does have integer multiply, but I found that the code using fp multilpy was faster (this is true on the R3000 and earlier, one of these days I should check the R4000). This is true even though we need more operations. (One of these days I should try the same on SPARC.) As I said, I do not know what the real solution is, it is certainly not as clear-cut as Herman thinks. -- dik t. winter, cwi, kruislaan 413, 1098 sj amsterdam, nederland home: bovenover 215, 1025 jn amsterdam, nederland; e-mail: dik@cwi.nl
Technical Details
Message-ID:
<7958@charon.cwi.nl>Path:
arc1-ca.pugleaf.net!sparky!uunet!mcsun!sun4nl!cwi.nl!dikReferences:
<martin.721995695@bert> <martin.722176263@bert> <TMB.92Nov20140542@arolla.idiap.ch>Show Full Headers
Complete Article Headers
Path: arc1-ca.pugleaf.net!sparky!uunet!mcsun!sun4nl!cwi.nl!dik From: dik@cwi.nl (Dik T. Winter) Newsgroups: comp.arch,comp.lang.misc Subject: Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms) Message-ID: <7958@charon.cwi.nl> Date: 22 Nov 92 00:18:15 GMT References: <martin.721995695@bert> <martin.722176263@bert> <TMB.92Nov20140542@arolla.idiap.ch> Sender: news@cwi.nl Followup-To: comp.arch Organization: CWI, Amsterdam Lines: 35