Path: utzoo!utgpu!news-server.csri.toronto.edu!rpi!zaphod.mps.ohio-state.edu!samsung!spool.mu.edu!news.nd.edu!mentor.cc.purdue.edu!pop.stat.purdue.edu!hrubin
From: hrubin@pop.stat.purdue.edu (Herman Rubin)
Newsgroups: comp.arch
Subject: Re: Compilers and efficiency
Message-ID: <10095@mentor.cc.purdue.edu>
Date: 11 Apr 91 13:26:28 GMT
References: <27fa3350.6bc2@petunia.CalPoly.EDU> <7117@auspex.auspex.com>
Sender: news@mentor.cc.purdue.edu
Lines: 20

In article <7117@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
> >If the languages do not allow the user to communicate  the use of those
> >features of the CISC architecture which can make the object code considerably
> >faster, the compiler cannot take advantage of them.
> 
> What about those features of the CISC architecture that don't make the
> object code *any* faster?  Methinks that's what a lot of people are
> complaining about here....

In some cases this is true.  A badly implemented procedure is bad.  

If a hardware polynomial evaluation takes longer than an explicit loop,
it is not the fault of the instruction, but of the implementation.  Also,
it is important not to compare the object codes produced by compilers, but
by intelligent human beings, who can reason out how to use the features not
supported by the languages.
-- 
Herman Rubin, Dept. of Statistics, Purdue Univ., West Lafayette IN47907-1399
Phone: (317)494-6054
hrubin@l.cc.purdue.edu (Internet, bitnet)   {purdue,pur-ee}!l.cc!hrubin(UUCP)