Xref: utzoo comp.arch:8708 comp.sys.intel:753
Newsgroups: comp.arch,comp.sys.intel
Path: utzoo!henry
From: henry@utzoo.uucp (Henry Spencer)
Subject: Re: i860 overview (long)
Message-ID: <1989Mar10.181724.1704@utzoo.uucp>
Organization: U of Toronto Zoology
References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com> <1133@auspex.UUCP> <13328@steinmetz.ge.com>
Date: Fri, 10 Mar 89 18:17:24 GMT

In article <13328@steinmetz.ge.com> davidsen@crdos1.UUCP (bill davidsen) writes:
>(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"...

You're still confusing two issues, or at least using confusing terminology.
There are, in fact, three separate issues here:

Alignment: Are N-byte objects required to be aligned on N-byte boundaries?

Byte addressing: Do the pointers point to bytes, as opposed to words?

Byte accessing: Can the processor read/write bytes, as opposed to words?

It is quite possible to have byte addressing without byte accessing, as on
the current 29000:  the pointers do point to bytes, but without external
hardware help, the current processor only does word memory accesses.

Nobody in his right mind designs a processor without byte addressing today.
Byte accessing is a tradeoff that depends on hardware constraints and how
the processor is to be used (Cray, for example, considers it unimportant).
Alignment is coming back in fashion for several reasons, notably simplicity
of hardware and easier exception handling (because aligned objects cannot
span page boundaries).

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

Did the Sun 4 have enough memory not to page itself to death?  Especially
if it was running SunOS 4, that's not a trivial issue.

Were the troffs compiled the same way?  Modern troffs have an option for
keeping the temporary file in memory, which can have a major effect on
performance.

Did you think to normalize for memory-system performance?  The 280 has
a big fast cache.

>... Since troff is FP intensive (at least on a VAX)...

Are you sure???  That doesn't sound like the troff I know.

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

Nobody would argue with this; why are you making a big deal out of it?

>Boy are RISC people defensive! 

Even non-RISC people think that apparent absurdities are worth challenging.
-- 
Welcome to Mars!  Your         |     Henry Spencer at U of Toronto Zoology
passport and visa, comrade?    | uunet!attcan!utzoo!henry henry@zoo.toronto.edu