Path: utzoo!attcan!uunet!seismo!dimacs.rutgers.edu!rutgers!ucsd!swrinde!zaphod.mps.ohio-state.edu!wuarchive!psuvax1!psuvm!psuecl.bitnet!d6b
From: d6b@psuecl.bitnet
Newsgroups: comp.arch
Subject: Re: Architecture questions
Message-ID: <1990Sep13.161733.20608@psuecl.bitnet>
Date: 13 Sep 90 20:17:30 GMT
References: <2531@l.cc.purdue.edu> <4043@auspex.auspex.com> <20597.26ed1035@psuecl.bitnet> <4057@auspex.auspex.com>
Organization: Engineering Computer Lab, Pennsylvania State University
Lines: 25

In article <4057@auspex.auspex.com>, guy@auspex.auspex.com (Guy Harris) writes:
>>Typically you only use 8 bits of your 32 or 64 bit registers/data bus when
>>manipulating text. Obviously you can add instructions to improve this
>>situation, and there are several examples in the real world of this being
>>done. (The Am29000 and the -gasp- Intel chips come to mind).
>
> Or you can *not* add them, and just do it anyway.  I seem to remember
> the 29K having an instruction to test any of the bytes in a word for
> zero; other systems do this in software - does the 29K do it faster?

Certainly. You can "often" speed things up by adding hardware. After all,
the reason why RISC chips are faster than typical CISC chips is because
they use 32-bit fixed-field opcodes and immediate register address
decoding, not because they have fewer instructions...(am I asking for
a flame here? :-)) Actually, a lot of so-called RISC chips have
instructions that are more complicated than CISC chips, simply by
stacking things up in parallel (once again using the larger opcode size
to advantage). Obviously if you're just in scientific computations, or
some such, text-handling support is superfluous. Adding features does
typically slow things down, but I claim that if one is sufficiently
clever the overall speed decrease can be made very small. Of course
there's also an opportunity cost involved, but what the heck - text
manipulation is pretty common.

-- Dan Babcock