Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!brl-adm!seismo!lll-lcc!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.arch Subject: Re: String Processing Instruction Message-ID: <230@winchester.mips.UUCP> Date: Thu, 26-Mar-87 22:19:13 EST Article-I.D.: winchest.230 Posted: Thu Mar 26 22:19:13 1987 Date-Received: Sat, 28-Mar-87 08:13:26 EST References: <15292@amdcad.UUCP> <978@ames.UUCP> <909@spar.SPAR.SLB.COM> Reply-To: mash@winchester.UUCP (John Mashey) Distribution: na Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 72 r Keywords: In article <909@spar.SPAR.SLB.COM> freeman@spar.UUCP (Jay Freeman) writes: >In article <978@ames.UUCP> lamaster@pioneer.UUCP (Hugh LaMaster) writes: > >> My question is this: How likely is it that a compiler itself will be able to >> detect the case when it can use an instruction like this and generate code >> automatically to use it. One of the positive points to the RISC debate is >> that it brought out the point that useful instructions which are hard for a >> compiler to generate are not always a win. > >Note that this particular instruction may well win even if no compiler EVER >generates it: BCase's posting stated that hand-modifying the object code >for two string-processing routines in the standard C library to use the >instruction, and arranging that the compiler word-align strings where >possible, effected consequent frequent improvements in run time of 15-20 >percent. That sounds like a substantial win for C programming, and surely a >fair amount of the code that does get written for this processor will be in >C. That may be reason enough for the instruction's existence. > >Although the point from the RISC debate, that LaMaster summarizes above, is >carefully qualified, it is perhaps nonetheless too narrow a view: Surely >there are many other cases in which a well-planned library of calls to >functions coded with particular care, will allow efficient use of highly >specialized instructions. Proper analysis of whether or not to include a >given instruction in an instruction set should include the effect of such >cases. This is a fairly interesting and useful discussion, especially if we can generate a few answers. Amusingly enough, neither MIPS nor IBM put this instruction in, although Marty Hopkins (IBM) once offered a desire to have it (even though it disobeyed the "must be useful from compilers rule"), and we've thought about it off and on. At one point, I did some hunting around for statistics on the use of the str* routines, how much time was spent in them, the distribution of string lengths, etc [you may have seen postings to such effect in the last few years in this group]. Weirdly enough, either nobody knows very much about the global nature of this, or nobody's telling. We did some rummaging and profiling of code, and were astonished to find the actual amount of time spent in the str* routines to be pretty small. [This was very non-intuitive to me.] Maybe we looked at the wrong things. So, now a few questions: 1) for Brian: could you say which programs you got the big improvements on? It would be very interesting for people to be able to try the test cases on some different machines and see how mcuh time is spent on these. 2) for anybody: a) What percentage of your machine's daily work is spent doing str* routines? b) Of that, how much is getting there and getting set up, and how much is in the fundamental loops? c) For each of strcpy, strcmp, and strlen, what is the distribution of lengths of argument? d) For strcmp, what is the fraction of times it finds equality. e) What fraction of strings begin on non-word boundaries/ f) For strcpy and strcmp, what fraction of calls start on word boundaries, what fraction don't start on words, but at least have similar alignment within the word, and what fraction are completely misaligned. [I think that there is actually a useful MS thesis around in here if done well.] Finally, regarding the inclusion of hand-coded cases, i.e., of instructions that can't be gotten to from compilers, but may still be useful, our sense is that there aren't very many like that. This one is one of the few like that [the others we've generally considered have often been compilable] that at least has seemed plausible to lots of us. -- -john mashey DISCLAIMER: UUCP: {decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD: 408-720-1700, x253 USPS: MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086