Re: Problems with Hardware, Languages, and Compilers

hrubin@stat.purdue.edu (Herman Rubin) wrote:


> The compilers available did manage to do x/y as x*(1/y), but as square
> root is recognized and reciprocal square root is not, it was found
> quite difficult to manage the problem on a routine basis.


This is a generic problem with computers, compilers, and, indeed,
computer science itself. A function f(x,y) and a function g(x) differ
in more than the value they compute: they differ in the number of
arguments they require.


For many arithmetic functions nowadays, this difference is much more
important than the actual circuitry or time to compute the bits of the
answer. At the hardware level, the differences between a 1-argument
function and a 2-argument function are vast, and it amazes me that
only a small fraction of software and compiler people can appreciate
this difference.


Factorizing x/y as x*(1/y) is not generally done inside compilers,
because compiler people are generally given a quotient hardware
operation, rather than an inverse operation. The software that cares
about this sort of thing -- e.g., linear algebra software -- often
uses hand-optimization to pull out the inverse operation from within a
loop, so the compiler is never called upon to do this itself. Since
compiler optimizations are completely driven by a handful of
standardized 'benchmarks' these days, only those optimizations
required by these benchmarks are given any priority.


--

Return to the comp.compilers page.
Search the comp.compilers archives again.