RISC Machine Data Structure Word Alignment Problems?

[Gary Bridgewater]

In article <21361 at weitek.WEITEK.COM> weaver at weitek.UUCP (Michael Gordon Weaver) writes:
>In article <51245 at bbn.COM> slackey at 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 at 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).