Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!swrinde!cs.utexas.edu!rice!ariel.rice.edu!preston From: preston@ariel.rice.edu (Preston Briggs) Newsgroups: comp.arch Subject: Re: Compilers, architecture, and efficiency Message-ID: <1991Apr30.025904.13028@rice.edu> Date: 30 Apr 91 02:59:04 GMT References: <1991Apr28.154603.8003@rice.edu> <1991Apr29.155945.29907@rice.edu> <11588@mentor.cc.purdue.edu> Sender: news@rice.edu (News) Organization: Rice University, Houston Lines: 51 hrubin@pop.stat.purdue.edu (Herman Rubin) writes: >Is it the compiler writer's job to recognize combinations of expressions in >a language which really represent an operation not contained in that >language? It's the compiler writer's job to write code that recognizes combinations of expressions that are supported by machine instructions. It's one of the significant tasks of instruction selection. I don't know how to handle everything (e.g., recognizing a routine that computes square root), but many of the combinations you (and others) give as examples _are_ easily handled. >What is needed for the user to be able to communicate what operations are >wanted. I agree that the user should be able to instruction the computer. However, I don't think I want to specify the assembly operations. Instead, I want to manipulate numbers, sets, sequences, and objects in a somewhat high-level fashion. Then I want the compiler to make very good code out of my specification. >> If you change the machine, you need to change compilers. > >This newsgroup is comp.arch. How are the computer architects to recognize >these situations and others? I expect they learn from reading and by experience. It seems that one of the major accomplishments of the RISC evolution was a recognition that architects and compiler people should talk more often than in the past. >What you have shown is that a compiler can, in effect, extend a language >by looking for certain code patterns. I disagree. The language (Fortran 77) didn't change when I added my optimization. The compiler translates exactly the same set of programs; some programs simply ran slightly faster. > I fail to see that this procedure, >which will always be limited by the information given to the compiler >writers, and which can also sometimes lead to difficulties, is better >than allowing the user to extend the language and pass the information >to the compiler in such a way that it can use more of the >machine capabilities. The difference is that we (computer science community in general) know how to do optimizing compilers. You pose a much harder problem. Preston Briggs