🚀 go-pugleaf

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: <generic disclaimer, I speak for me only, etc>
UUCP: 	{decvax,ucbvax,ihnp4}!decwrl!mips!mash, DDD:  	408-720-1700, x253
USPS: 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086