Xref: utzoo comp.arch:13349 comp.lang.c:25318 Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!swrinde!zaphod.mps.ohio-state.edu!uwm.edu!lll-winken!sun-barr!newstop!sun!amdahl!dgcad!gary From: gary@dgcad.SV.DG.COM (Gary Bridgewater) Newsgroups: comp.arch,comp.lang.c Subject: Re: RISC Machine Data Structure Word Alignment Problems? Keywords: risc sun Message-ID: <1309@proa.SV.DG.COM> Date: 24 Jan 90 08:16:46 GMT References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> <51245@bbn.COM> <21361@weitek.WEITEK.COM> Reply-To: gary@proa.SV.DG.COM () Followup-To: comp.arch Organization: Data General SDD, Sunnyvale, CA Lines: 62 In article <21361@weitek.WEITEK.COM> weaver@weitek.UUCP (Michael Gordon Weaver) writes: >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. I think you missed the phrase "Not because the programmer is stupid..." >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. I need to allocate an array of 50,000,000 8 bit integers. How do I do this? Which is more important 1) overall memory use, 2) misalignment penalty, or code readability? Then I need to allocate 1,000,000 structs containing other structs written by another programmer. What is the natural order of the data a priori on any machine? How big is an addr_t on a 386? Sparc? Cray? Is it bigger than a long float? I plan to pass these structures from a Sun 4 to a Vax to a Cray via an ethernet connection. Now what is the natural order? >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. I suggest that when RE-writing a program from scratch you can mitigate this effect if you have some idea where the code is going to run. This is of little help to Simulator vendors who have to run across different architectures. When you write a program you have no idea if it will be successful enough to be bothered by data alignment inefficiencies. You are usually more worried about getting it up quickly and in the same execution universe as the specs. In general, you are stuck and at best will have to go back and micro-tune the heck out of it on a case-by-case basis. In your spare time, study malloc algorithms so you can figure out how to allocate bit structures for fun and profit. I agree that it is easier if the hardware lets you misalign but that thinking is passe in the brave new world of RISC where using the computer is a compiler problem. -- Gary Bridgewater, Data General Corporation, Sunnyvale California gary@proa.sv.dg.com or {amdahl,aeras,amdcad}!dgcad!gary Networking is the worst form of data exchange except for all the others (apologies to WC).