Xref: utzoo comp.arch:13337 comp.lang.c:25300 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!usc!apple!voder!pyramid!weitek!weaver From: weaver@weitek.WEITEK.COM Newsgroups: comp.arch,comp.lang.c Subject: Re: RISC Machine Data Structure Word Alignment Problems? Keywords: risc sun Message-ID: <21361@weitek.WEITEK.COM> Date: 23 Jan 90 17:21:18 GMT References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> <51245@bbn.COM> Sender: weaver@weitek.WEITEK.COM Reply-To: weaver@weitek.UUCP (Michael Gordon Weaver) Organization: WEITEK Corp. Sunnyvale Ca. Lines: 32 In article <51245@bbn.COM> slackey@BBN.COM (Stan Lackey) writes: >Just a quick summary of the last time we went around on this issue: > >There are a number of interesting applications that build many >instances of small data structures, each containing varied data types. >It was said that logic simulators do this. In a machine that forces >you to always have data aligned, this can result in lots of wasted >memory. Not because the programmer is stupid, but because of the >nature of the application. > I want to point out here that this data alignment problem can be mostly worked around for application programs. On a machine with "natural" alignment, a structure (record, common) made of primitive data items (integers, pointers, floats, etc.) needs no padding if the elements are ordered such that smaller items always follow larger items. The size ordering of primitive data items is machine dependant, but similar from one machine to the next. If the entire record is not a multiple of the largest required alignment, then some space may be lost between structures, or in nested structures. This cannot be handled so easily. 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. Michael.