Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!decwrl!spar!freeman From: freeman@spar.UUCP Newsgroups: comp.arch Subject: Re: String Processing Instruction Message-ID: <948@spar.SPAR.SLB.COM> Date: Fri, 27-Mar-87 23:09:52 EST Article-I.D.: spar.948 Posted: Fri Mar 27 23:09:52 1987 Date-Received: Sun, 29-Mar-87 09:07:12 EST References: <15292@amdcad.UUCP> <978@ames.UUCP> <909@spar.SPAR.SLB.COM> <230@winchester.mips.UUCP> Reply-To: freeman@spar.UUCP (Jay Freeman) Distribution: na Organization: Schlumberger Palo Alto Research - CASLAB Lines: 50 Keywords: <*munch*> In article <230@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes: > >In article <909@spar.SPAR.SLB.COM> freeman@spar.UUCP (Jay Freeman) writes: >> [...] >>Note that this particular instruction may well win even if no compiler EVER >>generates it: >> [...] >> other cases in which ... functions coded with particular >>care, will allow efficient use of highly specialized instructions. > [Thoughtful queries on cycles consumed by string-processing.] I offer personal anecdotal evidence that highly optimized string-processing might be perceived as valuable by users: One noticeable irritation in the editors I use daily on various machines (Sun 3/160, Sun 3/75, Symbolics 3600), is the time-delay for string-search in text buffers: For editors that work by stuffing large pieces of a file into memory as contiguous characters, (rather than those that use a linked list of lines), this time delay can be reduced a *lot* by hand-coding the search routines to use low-level high-speed string-search primitives. (My evidence for "*lot*" is also anecdotal; I once did a screen editor in the Intel *86 architecture: With all text as contiguous bytes in memory, the difference between the usual C loop "while( *buf++ != c ) ..." and careful use of Intel's REP SCASB string-search assembly-language idiom, was markedly noticeable in buffers only a few 10s of KBytes long on my 5 MHz 8088 machine.) Note that I address user satisfaction, not cycles consumed. >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. How about special floating-point instructions to support "cortic" (have I got that spelled right?) algorithms for transcendental functions? (I acknowledge that a general-purpose RISC machine would probably curdle its silicon at the mere thought of having floating-point hardware on chip, but consider a CISC manufacturer who is doing a floating-point coprocessor or auxiliary processor.) How about test-bit-field-and-branch instructions to support Lisp? How about "atomic" test-and-set operations for semaphores, or bus-locking primitives for dealing with various specialized peripheral devices. Jay Freeman, Schlumberger Palo Alto Research