Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uwm.edu!linac!midway!midway!stephen From: stephen@pesto.uchicago.edu (Stephen P Spackman) Newsgroups: comp.arch Subject: Re: Compilers and efficiency Message-ID: Date: 8 May 91 06:17:42 GMT References: <27fa3350.6bc2@petunia.CalPoly.EDU> <9782@mentor.cc.purdue.edu> <11411@mentor.cc.purdue.edu> <653@ctycal.UUCP> Sender: news@midway.uchicago.edu (NewsMistress) Organization: University of Chicago CILS Lines: 32 In-Reply-To: ingoldsb@ctycal.UUCP's message of 7 May 91 19: 19:05 GMT In article <653@ctycal.UUCP> ingoldsb@ctycal.UUCP (Terry Ingoldsby) writes: It seems to me that the only way your crusade for bit distance will ever be successful is to show the general utility of such functions. Otherwise, no matter how interesting (to you), you will not get these features. Are we talking about "find first one" here? Find first one was a pretty useful instruction in our lisp compiler. In fact, we figured we could speed the thing up a LOT by moving to the Amiga and using the blitter to do bitmask stuff (which we wanted (a) for closure algorithms and (b) for resource allocation). A lot of CPU seems to get expended on variable length data encoding around here. I haven't examined the code myself but it sounds like it would come up there. It's a notoriously useful thing for resource allocation in operating systems, too. I've surely wanted this more often than, say, floating point addition. Of course, there are always other data representations, and so long as the hardware people take the attitude that computers are for fluid dynamics and to hell with compilers, operating systems and databases (who uses computers for THAT stuff anyway? :-).... Lotsa smilies. ---------------------------------------------------------------------- stephen p spackman Center for Information and Language Studies systems analyst University of Chicago ----------------------------------------------------------------------