Xref: utzoo comp.arch:8714 comp.sys.intel:755
Path: utzoo!utgpu!utstat!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!itsgw!steinmetz!uunet!auspex!guy
From: guy@auspex.UUCP (Guy Harris)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 overview (long)
Message-ID: <1143@auspex.UUCP>
Date: 10 Mar 89 19:56:49 GMT
References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com> <1133@auspex.UUCP> <13328@steinmetz.ge.com>
Reply-To: guy@auspex.UUCP (Guy Harris)
Organization: Auspex Systems, Santa Clara
Lines: 56

>(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.

Most of them *don't*.  Therefore, the speculation about them in your
posting was incorrect.

>The Honeywell 6000 series was an example of not having direct
>byte addressing

...at least if it didn't have the extended instruction box.

>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.

Well, then, the SPARC and almost certainly the MIPS are byte-addressible.

>(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.

How can it be FP-intensive if it has no floating point numbers in it?  I
found no occurrences of "float" or "double" in the 4.3BSD "nroff"/"troff"
source, and the SunOS 4.0 "nroff"/"troff" is basically derived from the
4.3BSD version.

>(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 think everybody realizes that there isn't always a single number "N"
that can represent the speed difference between one processor and
another - regardless of whether one is a RISC and one a CISC, both are
RISCs, or both are CISCs.  Read a MIPS Performance Brief sometime.

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

Post both user-mode and system-mode CPU time.  If, by some chance, the
SunOS 4.0 "troff" has had floating-point computations inserted into it
for some reason, and the Sun-4 test was done on a 4/110 with no FPU,
then the system time should be higher since the floating-point emulation
is done in the kernel (to avoid the overhead of going back to user mode).

>Boy are RISC people defensive! 

What do you expect?  You made a completely inappropriate speculation
about RISCs (namely that they're generally word-addressible, and don't
do byte operations inefficiently), and made a hard-to-believe claim
about the relative performance of a Sun-3 and a Sun-4 on "troff".  I'd
certainly expect them to reply, and point out that the first is simply
untrue and the second doesn't match their experiences.