|Problems with Hardware, Languages, and Compilers email@example.com (1997-03-07)|
|Re: Problems with Hardware, Languages, and Compilers firstname.lastname@example.org (1997-03-09)|
|[++] Re: Problems with Hardware, Languages, and Compilers Terje.Mathisen@hda.hydro.com (Terje Mathisen) (1997-03-09)|
|Re: Problems with Hardware, Languages, and Compilers email@example.com (1997-03-09)|
|Definable operators (was: Problems with Hardware, Languages, and Compi firstname.lastname@example.org (1997-03-09)|
|Re: Problems with Hardware, Languages, and Compilers email@example.com (1997-03-09)|
|Re: [++] Re: Problems with Hardware, Languages, and Compilers firstname.lastname@example.org (Jarkko Hietaniemi) (1997-03-13)|
|[63 later articles]|
|From:||email@example.com (Herman Rubin)|
|Date:||7 Mar 1997 21:38:07 -0500|
|Organization:||Purdue University Statistics Department|
I read an article in _High-Speed Computing_ recently, and this showed
up a problem involving languages and compilers, and incidentally
hardware arithmetic. I do not remember the exact title of the paper,
but the topics discussed were division and square root on the i860.
Hardware on the "cutting edge" can use a table lookup to start
reciprocal or reciprocal square root, and iterative methods using only
a few multiplications and additions to get accurate values for these.
The same cannot be done for square root.
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 an example where there can be useful hardware which cannot be
incorporated into a language, and/or the compiler could not do a good
job with it. Both of these need to be changed; what is needed is that
other operations can be added at will to the language, and that the
compiler can be instructed to select from optimization techniques
which the user can supply it, as well as from those which the compiler
writer included. These will be machine dependent, and may even depend
on what other instructions are running in the neighborhood.
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
firstname.lastname@example.org Phone: (765)494-6054 FAX: (765)494-0558
[As always, I invite Herman to sketch out such a language so we can see
what the concrete syntax would look like. I used IMP72, a language where
you could add any operations you wanted, and it was awful. -John]
Return to the
Search the comp.compilers archives again.