Path: utzoo!attcan!uunet!convex!patrick
From: patrick@convex.com (Patrick F. McGehearty)
Newsgroups: comp.arch
Subject: Is handling off-alignment important? (was Re: RISC hard to program?)
Message-ID: <104037@convex.convex.com>
Date: 17 Jul 90 22:49:47 GMT
References: <40088@mips.mips.COM> <2162@opus.cs.mcgill.ca> <3648@auspex.auspex.com> <2163@opus.cs.mcgill.ca>
Sender: usenet@convex.com
Organization: Convex Computer Corporation; Richardson, TX
Lines: 17


For machines which are pushing the limits of technology, there are clearly
some advantages to not handling offalignment accesses efficiently in
hardware.  Let us assume that some mechanism is provided for handling
offalignment accesses (like 16 bit accesses on a byte boundary, or 32 bit
accesses on a 16 bit boundary, or whatever), but making it significantly
less efficient could reduce the number of gate delays in the primary path to
memory for aligned accesses.  The question I would be interested in seeing
some discussion on is how much penalty is allowable for off-aligned accesses
before the performance cost requires reprogramming to avoid the
off-alignments from occurring.

Trivial example: consider the std libc bcopy which takes two pointers and a
count.  Most machine specific implementations move the data in units larger
than a character at time.  Under what conditions should the implementor of
this commonly used library worry about checking the alignment of the
pointers before starting the copy?