Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!lll-winken!uunet!mitel!sce!greg
From: greg@sce.carleton.ca (Greg Franks)
Newsgroups: comp.arch
Subject: Re: Unaligned Accesses (was Re: How to use silicon)
Message-ID: <580@sce.carleton.ca>
Date: 25 Mar 89 16:58:32 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>
Reply-To: greg@sce.UUCP (Greg Franks)
Organization: Systems Eng., Carleton Univ., Ottawa, Canada
Lines: 43

People debating the merits of unaligned accesses with various
people at BNR saying they are useful...

Having worked in the telephone industry (though not at BNR), I can
relate to their desire to have the processor handle unaligned
accesses.  Why?  Simple - the applications that they are dealing with
are pieces of switching equipment that have hundreds of processors of
various shapes and sizes.  They all like to pass binary data to and
from each other.  Needless to say, the alignment requirements on a
6800 are rather different from those on a 88000.  Furthemore, parts of
the system are upgraded at different times - why toss out $1,000,000 of
smart line cards when you are are updating your $10,000 processor.  

Just to make things difficult, communication channels may complicate
life.  On the switch that I worked on, we could fire 32 bytes of data
through the message switch to any other processor on the system.
Aligning the data may cause the message to grow above 32 bytes thus
requiring another message.  Our message system did not guarantee
delivery, so just imagine the extra cost of tacking a protocol onto
the system to ensure both messages arrived at their destination.  The
loss of one message is no big deal, the loss of half a message is.

To continue, lots and lots of code on the switch was written in
assembler language.  If the world were perfect, one could change
offsets by simply tweaking .h files.  But we all know that the world
is not perfect. :-(.

Finally, telephone switches that I am familiar with do not have
virtual memory.  It costs money and it complicates real-time response.
Oops - we just paged out dial tone - we'll have to wait a couple of
seconds... :-) (not a real example...).  Adding memory is expensive
and a pain.  We spent a good half year PACKING data (by shuffing
fields around, changing the compiler etc) just so we would not have to
jam in more memory cards.  Memory isn't cheap, and bus slots may not
be available.  (All cards are designed in-house, and fit on a special
bus.  Economies of scale aren't there like they are in klones-R-us).

Sorry that I've bored you to death.
-- 
Greg Franks                  Systems and Computer Engineering, 
utzoo!dciem!nrcaer!sce!greg  Carleton University, Ottawa, Ontario, Canada.
       uunet!mitel!sce!greg          greg@sce.carleton.ca
from Ottawa Ont, where life in the fast lane is skating two inners!