Xref: utzoo comp.arch:8699 comp.sys.intel:750
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!ames!ucsd!sdcsvax!ucsdhub!esosun!seismo!uunet!steinmetz!davidsen
From: davidsen@steinmetz.ge.com (William E. Davidsen Jr)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 overview (long)
Message-ID: <13328@steinmetz.ge.com>
Date: 9 Mar 89 13:22:34 GMT
References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com> <1133@auspex.UUCP>
Reply-To: davidsen@crdos1.UUCP (bill davidsen)
Organization: General Electric CRD, Schenectady, NY
Lines: 29

Several comments on my earlier posting:

(a) I was talking about the general case of machines which don't have
byte addressing and fetch a byte using a three step "load, shift, and"
and store a byte doing something like "load, and, shift, or, store". I
Didn't mean to imply that any particular RISC architecture used that
method. The Honeywell 6000 series was an example of not having direct
byte addressing (yes you can use a tally word but building it is as
slow as the and & ors). If the load and store time for an arbitrary
byte are the same as an alligned int, and if load/store byte is a
single operation, then I would consider it byte addressable for the
purposes of any program I want to run.

(b) several people posted results using big Sun4's and little Sun3's. I
believe that the tests were done on a Sun3/280 with FPU and a small Sun4
(I don't know the model number). Since troff is FP intensive (at least
on a VAX) that may be difference.

(c) the point I was trying to make was that a RISC processor which is "N
times faster" than some CISC processor is not going to have the same
improvement in all cases.

I'll post the actual results if I can get them from a rerun.

Boy are RISC people defensive! 
-- 
	bill davidsen		(wedu@ge-crd.arpa)
  {uunet | philabs}!steinmetz!crdos1!davidsen
"Stupidity, like virtue, is its own reward" -me