Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sdd.hp.com!hplabs!hpcc01!hpbbn!hpbbrd!hpfcmdd!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: <8840014@hpfcso.HP.COM>
Date: 20 Jul 90 18:24:56 GMT
References: <104037@convex.convex.com>
Organization: Hewlett-Packard, Fort Collins, CO, USA
Lines: 35


Okay, with all this talk about off alignment, here's something that nobody
has mentioned yet.

How do processors that handle off alignment deal with getting a page
fault in between the multiple transfers?  Couldn't this get really
hairy?  I mean, consider this:


$A	: $XDDD  <- Page 1
$A + 4	: $DXXX  <- Page 2

Where "A" is the last address on page 1.  "D" represents the
misaligned word that you want to load and "X" is don't care.

What if page 2 is paged out?  When does the CPU notice that it's paged
out and what does it do about it?  Does it abort the transaction
entirely, bring page 2 back in, and restart?  If so, what if, because
of the page replacement algorithm, page 1 gets blown away by bringing
in page 2?  If you do bring in the first three bytes and put them into
one of the registers, what kind of state does that leave the paging
code to deal with, since paging isn't handled by the hardware?  This
has nasty implications for instruction fetch of variable length
instructions also.  In this case, what if the misaligned transfer is
an instruction fetch?  I mean, ick!

I've gotta think that all these corner cases have got to add a lot of
checking to the CPU design which has to slow it down, not to mention
the possiblity of having a case that you didn't think of and
introducing a bug.  I think I'd rather deal with the alignment, have
my CPU run fast, and have a greater assurance that it was designed
correctly.

Dave Roberts
dgr@hpfcla.fc.hp.com