Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP Path: utzoo!utgpu!water!watnot!watmath!clyde!rutgers!lll-lcc!pyramid!prls!mips!mash From: mash@mips.UUCP Newsgroups: comp.arch Subject: Re: String Processing Instruction Message-ID: <237@winchester.mips.UUCP> Date: Sat, 28-Mar-87 17:14:47 EST Article-I.D.: winchest.237 Posted: Sat Mar 28 17:14:47 1987 Date-Received: Sun, 29-Mar-87 09:57:30 EST References: <15292@amdcad.UUCP> <978@ames.UUCP> <909@spar.SPAR.SLB.COM> <230@winchester.mips.UUCP> <948@spar.SPAR.SLB.COM> Reply-To: mash@winchester.UUCP (John Mashey) Distribution: na Organization: MIPS Computer Systems, Sunnyvale, CA Lines: 59 In article <948@spar.SPAR.SLB.COM> freeman@spar.UUCP (Jay Freeman) writes: > >In article <230@winchester.mips.UUCP> mash@winchester.UUCP (John Mashey) writes: > >I offer personal anecdotal evidence that highly optimized string-processing >might be perceived as valuable by users: .... >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.) I believe that if you have a microcoded machine, you should have at least a few of the critical string routines, although note that it is very difficult to get a minimal set that covers all of the interesting cases, i.e., many CPU's string instructions don't do C. If you have a machine that provides them, you're crazy not to use them. > > >>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 I think it's "quartic", and I think there may be some justification for them, depending on the silicon tradeoffs, i.e., does it cost you time in add or multiply to put the quartics on. Depending on the target applications, it may or may not be worth it. >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.) I don't know why its silicon would be curdled. Again, it really depends on the target application mix: for example, for some applications, I'd be tempted to put an FP unit on the CPU chip. [We didn't because we wanted ferocious FP performance, and you cannot yet get enough silicon area to do that on the CPU chip, certainly not at 2micron, and probably not a 1.2.] > >How about test-bit-field-and-branch instructions to support Lisp? We did some looking at that for LISP & Smalltalk. Some of them really want to be traps on bitfields for tag-checking. However, these are in the category of "compiler can generate them". > >How about "atomic" test-and-set operations for semaphores, or bus-locking >primitives for dealing with various specialized peripheral devices. Some operations of this class are required, although there are different ways to implement them. Most of the typical implementations don't extend very well into large N shared-memory multis, i.e., bus-lock is the LAST thing you want to be going on very much. Anyway, some good points: there certainly exist instructions that are hard for compilers to generate, that are still useful, and depending on the application targets, people may decide or not to include them. -- -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