Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!bbn!bbn.com!slackey
From: slackey@bbn.com (Stan Lackey)
Newsgroups: comp.arch
Subject: Re: Unaligned Accesses (was Re: How to use silicon)
Message-ID: <37924@bbn.COM>
Date: 29 Mar 89 15:05:50 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <13@microsoft.UUCP> <362@bnr-fos.UUCP> <59@microsoft.UUCP> <844@bnr-rsc.UUCP>
Sender: news@bbn.COM
Reply-To: slackey@BBN.COM (Stan Lackey)
Organization: Bolt Beranek and Newman Inc., Cambridge MA
Lines: 54

In article <844@bnr-rsc.UUCP> mlord@bnr-rsc.UUCP (Mark Lord) writes:
>In article <59@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes:

>>CISC processors have exactly the same problems.  They still have to break
>>[unaligned accesses] up into two accesses.  
>>flexibility.  If the second one fails, the VAX will restart both accesses,
>>while a 68020 will only reexecute the second.  In both cases, an arbitrarily
>>long time can pass between the first (the first first, in the case of the
>>VAX) access and the second.  How is this different from what a RISC chip
>>provides?
>I didn't actually have data faults in mind here.  Of more concern were 
>interrupts occuring between the multiple accesses, with the interrupt code

Nope!  Processors typically test for interrupts between instructions,
not during.  Unless it is one of the VAX continuable instructions, in
which case it can take one but only after all specifiers are evaluated
(and fetched if appropriate).  This is architecturally defined.
(Disclaimer: Other architectures that support continuable instructions
may do other things.)

Page faults are the only case (that I can think of right now anyway) that
can cause this class of situation.  An interrupt could be taken (after the
fault frame is pushed), but by now that's beside to point.

I can't imagine any processor that would go to the trouble of taking
an interrupt at any arbitrary time.  It would save a few cycles to
recognize the interrupt earlier, at the cost of many many cycles to
save all internal state.  Much added complexity for only a slight
reduction (not a typo) in performance!

>>I don't quite understand the problem.  Alignment restrictions are almost
>>zero hassle in most code, are enforced by compilers even on processors
Then, why were the suppliers (IBM, DEC, Motorola, etc) pressured so much
by programmers to add this feature in the first place?  What has changed?

>>which don't beed them for efficiency reasons (the Microsoft C compiler
>>inserts pad bytes in the instruction stream to get the target of a branch
>>instruction word-aligned), 
Instruction alignment is very far from the current issue.  Some
processors (in fact, ONLY those with variable-size instructions,
typically non-RISCS's) can be benefited by this, in that the first
fetch after a branch will pick up more of a variable-size instruction.

>>and simplify the hardware tremendously.
This is a major part of the point!  If it were a tremendous savings,
it would never have been done in the first place.  Trust me, if you
had a gate-level schematic of a CPU in front of you, you could look at
it for weeks and never find the unaligned logic.  So many pieces of it
you need anyway: rotators to fetch bytes/words, stalls to deal with
non-zero wait state memory systems, traps to handle page faults.

It's just another small cost-small benefit item.  Like a lot of the other 
stuff that's creeping back into RISC's these days.
:-) Stan