🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.arch
Article #11391

Re: how to advocate new software/hardware features (Re: Hardware Support for Numeric Algorithms)

#11391
From: Dik T. Winter
Date: Sun, 22 Nov 1992 00:18
35 lines
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!dik
References: <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