Path: utzoo!utgpu!water!watmath!clyde!att!osu-cis!tut.cis.ohio-state.edu!rutgers!uwvax!oddjob!uxc!uxc.cso.uiuc.edu!urbsdc!aglew
From: aglew@urbsdc.Urbana.Gould.COM
Newsgroups: comp.lang.c
Subject: Re: sizeof( _variable_ )
Message-ID: <28700031@urbsdc>
Date: 30 Jul 88 01:52:00 GMT
References: <6089@chinet.chi.il.us>
Lines: 45
Nf-ID: #R:chinet.chi.il.us:6089:urbsdc:28700031:000:1987
Nf-From: urbsdc.Urbana.Gould.COM!aglew    Jul 29 20:52:00 1988


>In article <1264@bc-cis.UUCP> john@bc-cis.UUCP (John L. Wynstra) writes:
>typedef struct {
>	char	x[10];
>	char	y;
>	char	xx[10];
>	char	yy;
>} Stuff;
>Stuff z;
>Later on in the same code I had a reference to sizeof(z) expecting to get 22
>(which is btw what I just now got on the bsd 4.2 vax), but what I got was 24!

Oh, you're going to love me... I have proposed, and, in my spare time
university research (this is definitely not related to my employer!)
occasionally do some work on evaluating, a system where ALL data structures 
have to be aligned on a power of two boundary... no, that phrase isn't
quite correct. I call it "strict power of two alignment", and it means
that all objects are rounded up to a power of two in size, and have to be
aligned on a multiple of their rounded up size.

So, in the above example, x would be at location 0, y would be at location
16, xx would be at location 32, and yy would be at location 48. 
sizeof(Stuff) would be 64.

Why do this? To sell more memory chips... :-) Actually, to shave the proverbial
10% off address generation in a microprocessor (the actual savings varies,
and depends on what you measure - cycle time, or factor in increased miss
ratios due to memory expansion, etc.)

Note, of course, that rearranging some structs can produce savings (although
not in this case), but C guarantees ordering of struct fields, although
not contiguity.

I'm interested in any holes that people can blow in this memory alignment
scheme. Send mail, or post in comp.arch.


Andy "Krazy" Glew. Gould CSD-Urbana.    1101 E. University, Urbana, IL 61801   
    aglew@gould.com     	- preferred, if you have MX records
    aglew@xenurus.gould.com     - if you don't
    ...!ihnp4!uiucuxc!ccvaxa!aglew  - paths may still be the only way
   
My opinions are my own, and are not the opinions of my employer, or any
other organisation. I indicate my company only so that the reader may
account for any possible bias I may have towards our products.