Xref: utzoo comp.arch:13315 comp.lang.c:25266 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!wuarchive!usc!apple!bbn!bbn.com!slackey From: slackey@bbn.com (Stan Lackey) Newsgroups: comp.arch,comp.lang.c Subject: Re: RISC Machine Data Structure Word Alignment Problems? Keywords: risc sun Message-ID: <51245@bbn.COM> Date: 22 Jan 90 19:09:52 GMT References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> Sender: news@bbn.COM Reply-To: slackey@BBN.COM (Stan Lackey) Organization: Bolt Beranek and Newman Inc., Cambridge MA Lines: 31 In article peter@ficc.uu.net (Peter da Silva) writes: >> I guess all the world's not a Vax any more, now it's a 68020. >Worse, since non-word-aligned values do cost extra cycles to access, any >68020 C compiler that didn't pad that structure is broken. Some "features" >of CISC processors are just too expensive to use. 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. Now, if I have a 4MB workstation, and alignment restrictions increases the need from under 4MB to over 4MB, there will be significant paging. I'd rather spend two cycles to access a word sometimes, than have to page over the Etherent. So would the people with whom I share the network. ------ Also: the comments on the 360 (aligned) vs 370 (unaligned): Boy did I hear a different story. The version I heard was that the 370 supported unaligned data, because the experience with the 360 showed it was incredibly painful to be without it. Remember in those days memory was VERY expensive. :-) Stan