Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpfcso!dgr
From: dgr@hpfcso.HP.COM (Dave Roberts)
Newsgroups: comp.arch
Subject: Re: Is handling off-alignment important? (was Re: RISC hard to program?)
Message-ID: <8840015@hpfcso.HP.COM>
Date: 23 Jul 90 18:21:46 GMT
References: <104037@convex.convex.com>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 47


Henry Spencer writes:

> In article <8840014@hpfcso.HP.COM> dgr@hpfcso.HP.COM (Dave Roberts) writes:
> >How do processors that handle off alignment deal with getting a page
> >fault in between the multiple transfers?  Couldn't this get really
> >hairy?  ...
> 
> In a word, yes.  This is one of the major reasons why essentially all RISC
> processors insist on "natural" alignments:  so that no operand can cross
> a page boundary.
> 
> If you want *real* fun, consider that unaligned operands can overlap.
> Think about the implications of overlapping operands that span a page
> boundary between a normal page and a paged-out read-only page in a
> machine with two levels of virtual-address cache and a deep pipeline...
> with an exception-handling architecture that was nailed down in detail
> on much slower and simpler implementations, and can't be changed.  This
> is the sort of problem that makes chip designers quietly start sending
> their resumes to RISC manufacturers... :-)

Sorry guys.  I didn't mean to sound so dumb when I wrote that.  :-) I
with RISC products at a board level, so I already knew the answer was
"yes", I was just looking for a somewhat quantitative explanation of
what a designer has to go through to make this work and what
techniques were used.  How much of a slow down does this cause with
the processor?  The original argument was that not supporting
misalignment was a misfeature (or bug in the original authors
vocabulary).  Anyway, I was just wondering how much faster you could
go with a given design if you didn't have to support this stuff.  What
I was trying to convey was the idea that it isn't just as easy as
supporting multiple accesses to memory but that the problem actually
can go all the way down to the memory management and exception
handling level, and that stuff seems to be the most gut wrenching and
error prone level of a design.  It also tends to impact performance
pretty heavily the more complicated you make it.

Anyway, I was just wondering if there was any CISC designer out there
that could say something like, "Yea, well, we could have made that 25
MHz part run at 40 MHz if we hadn't had to support all the
misalignment gunk."  Some people will still want to have the
misalignment, but it's nice to see what price you're paying to get it
so that you can evaluate whether you really need it.

Dave Roberts
Hewlett-Packard Co.
dgr@hpfcla.fc.hp.com