Xref: utzoo comp.arch:8695 comp.sys.intel:749
Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!ucbvax!decwrl!sun!imagen!atari!portal!cup.portal.com!bcase
From: bcase@cup.portal.com (Brian bcase Case)
Newsgroups: comp.arch,comp.sys.intel
Subject: Re: i860 overview (long)
Message-ID: <15562@cup.portal.com>
Date: 8 Mar 89 19:59:44 GMT
References: <807@microsoft.UUCP> <92634@sun.uucp> <13322@steinmetz.ge.com>
Organization: The Portal System (TM)
Lines: 13

>One problem with any chip which requires alligned data is that
>performance suffers when addressing bytes, to the point that a program
>may become impractical. One of the people here checked his Sun-30
>(68020) against his Sun-4 (SPARC). The three ran troff about 5x faster.
>This doesn't mean RISC is bad in a workstation, but it can have
>performance problems in software we take for granted.

Now wait a minute; can anyone substantiate this claim?  It seems that
something else must have been wrong:  I might believe that the 020
could be faster for *unaligned* data, but not 5 times faster.  The
SPARC has load/store byte, halfword, and word instructions that work
just fine as long as data is properly aligned.  And I can't imagine
the compiler unaligning things on purpose.  Could you clarify this?