Problems with Hardware, Languages, and Compilers

hrubin@stat.purdue.edu (Herman Rubin)
7 Mar 1997 21:38:07 -0500

          From comp.compilers

Related articles
Problems with Hardware, Languages, and Compilers hrubin@stat.purdue.edu (1997-03-07)
Re: Problems with Hardware, Languages, and Compilers nmm1@cus.cam.ac.uk (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 hbaker@netcom.com (1997-03-09)
Definable operators (was: Problems with Hardware, Languages, and Compi rrogers@cs.washington.edu (1997-03-09)
Re: Problems with Hardware, Languages, and Compilers mw@ipx2.rz.uni-mannheim.de (1997-03-09)
Re: [++] Re: Problems with Hardware, Languages, and Compilers jhi@alpha.hut.fi (Jarkko Hietaniemi) (1997-03-13)
[63 later articles]
| List of all articles for this month |
From: hrubin@stat.purdue.edu (Herman Rubin)
Newsgroups: comp.compilers,comp.lang.misc,comp.arch.arithmetic
Date: 7 Mar 1997 21:38:07 -0500
Organization: Purdue University Statistics Department
Keywords: design

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
hrubin@stat.purdue.edu 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]


--


Post a followup to this message

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