Xref: utzoo comp.arch:13368 comp.lang.c:25333 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!uwm.edu!uwvax!primost.cs.wisc.edu!larus From: larus@primost.cs.wisc.edu (James Larus) Newsgroups: comp.arch,comp.lang.c Subject: Re: RISC Machine Data Structure Word Alignment Problems? Keywords: risc sun Message-ID: <9610@spool.cs.wisc.edu> Date: 24 Jan 90 20:52:06 GMT References: <21361@weitek.WEITEK.COM> <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> <51245@bbn.COM> Sender: news@spool.cs.wisc.edu Reply-To: larus@cs.wisc.edu Organization: University of Wisconsin--Madison Lines: 22 In article <21361@weitek.WEITEK.COM>, weaver@weitek.WEITEK.COM writes: > In summary, if you are writing an application from scratch, you > can minimize this effect in an almost (but not quite!) machine > independant way. So for new programs, I think natural alignment > is a good time/speed tradeoff. I also think that supporting > unaligned data by both traps and special in-line code is a good > idea, since so many programs have long histories. This statement may be true in general, but it is not always true. For example, I wrote a program tracing system that writes out a trace file consisting of a mixture of bytes, halfwords, and full words. It is crucial to this system that the byte quantities only take up 8 bits (otherwise the size of the already large files grow by a factor of 2 or more). However, it means that I need to do unaligned stores into the trace buffer. And, since I trace programs in real time, I need to do the stores fast. The MIPS R2000 has a 2 instruction sequence that can store a half/fullword quantity on any byte boundary. On SPARC, it takes 7 instructions to store fullwords byte-by-byte. Comming from Berkeley, I hate to say it, but this is another case in which MIPS has a much better designed machine than Sun (-: /Jim