Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!convex!patrick
From: patrick@convex.com (Patrick F. McGehearty)
Newsgroups: comp.arch
Subject: Re: Is handling off-alignment important? (was Re: RISC hard to program?)
Message-ID: <104075@convex.convex.com>
Date: 18 Jul 90 22:38:04 GMT
References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca> <3648@auspex.auspex.com> <2163@opus.cs.mcgill.ca> <104037@convex.convex.com> <1990Jul18.190750.7282@zoo.toronto.edu>
Sender: usenet@convex.com
Organization: Convex Computer Corporation; Richardson, TX
Lines: 40

In article <1990Jul18.190750.7282@zoo.toronto.edu> henry@zoo.toronto.edu (Henry Spencer) writes:
>In article <104037@convex.convex.com> patrick@convex.com (Patrick F. McGehearty) writes:
>>Trivial example: consider the std libc bcopy which takes two pointers and a
>>count. ...
>
>Essentially always, unless the count is very small.  Even on machines that
>handle misalignment, if the alignment on the two areas is compatible, it
>is better to copy enough initial bytes to align the pointers and then do
>an aligned copy for the bulk of the data.
>
>(Also, a quibble:  bcopy may be "std", but the *standard* routine for
>doing this is memcpy. :-))

I agree with everything henry says above.
I should have said "well known" instead of "std" bcopy :-) :-)

I also see I did not make the question I wanted answered clear.  Let me try
again.  I was assuming (but should have said as henry points out) that the
source pointer was initially aligned with a partial word move before the
block transfer began.  What I intended to ask was when is it worth the
trouble to load/shift/store or load partials or whatever it takes to avoid
off-alignment accesses when the src and dest do not match alignment?

But what I really was interested in is the following question:
What guidelines would you give an architect about how slow he
get away with making off-aligned accesses before it will start:
(1) causing internal library people to rewrite code to avoid the problem?
(2) causing compiler code generation oddities to avoid the problem?
(3) causing customer application code people to recode assembly libraries
	to avoid the problem?
(4) cause a general stink in the marketplace because of the problem?

We already have some evidence that an infinite time for off-alignment
does cause at least some customers to be unhappy. (like Sparc :-) :-))
However, such evidence shows that it is not fatal either.  There are a lot
of Sparc's out there.

Part 2 of the question: does the answer depend on market segment?
Are software performance expectation for a workstation different from a
supercomputer?  (I suspect they are)