🚀 go-pugleaf

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 <canonical disclaimer>