🚀 go-pugleaf

	I've only been loosely following this thread for a while, so excuse
me if this has been gone through already.  I assume that SPARC based machines
have (at least as an option) some sort of floating point coprocessor, which
obviously would be used for floating point multiplies.  Most (handwave)
non-computational integer multiplies (by which I mean operations invented by
the compiler for array subscripting, pointer arithmetic, etc) involve one
constant factor with few ones, ideal for shift-and-add strength reductions.
Non-power-of-2 integer division is even rarer.

	The bottom line is that I'm hard pressed to think of an application
where full 32 x 32 integer multiplies constitute a significant fraction of
the operations performed.  Most large utility programs (operating systems,
compilers, editors, windowing systems (except maybe NeWS?) don't do many
32x32 multiplies and most scientific number crunchers are all floating point.
In fact, we have one large number cruncher that does macromolecule energy
minimization using fixed point (integral numbers of tenths of kcals/mole) but
that's all addition, subtraction, and table lookups.  What's left?  Digital
signal processing maybe?

	Slightly off the subject, is it possible, using the current SPARC
architecture, to take advantage of the floating point data paths to speed up
integer multiplies for those few applications that really need it?
--
Roy Smith, Public Health Research Institute
455 First Avenue, New York, NY 10016
roy@alanine.phri.nyu.edu -OR- {att,philabs,cmcl2,rutgers,hombre}!phri!roy
"My karma ran over my dogma"