Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.milw.wisc.edu!leah!rpi!batcomputer!cornell!rochester!pt.cs.cmu.edu!PLAY.MACH.CS.CMU.EDU!bsy
From: bsy@PLAY.MACH.CS.CMU.EDU (Flexi-thumbs)
Newsgroups: comp.arch
Subject: Re: Sorting struct members for alignment (was Re: Unaligned Accesses)
Keywords: alignment
Message-ID: <4582@pt.cs.cmu.edu>
Date: 28 Mar 89 03:26:05 GMT
References: <37196@bbn.COM> <1989Mar16.190043.23227@utzoo.uucp> <24889@amdcad.AMD.COM> <355@bnr-fos.UUCP> <13@microsoft.UUCP> <362@bnr-fos.UUCP> <59@microsoft.UUCP> <11118@pur-ee.UUCP>
Organization: Cranberry Melon
Lines: 61

In article <11118@pur-ee.UUCP> hankd@pur-ee.UUCP (Hank Dietz) writes:
>In article <59@microsoft.UUCP> w-colinp@microsoft.uucp (Colin Plumb) writes:
>>> Granted, by careful (human) reordering of the fields within a complex
>>> structure, one can almost always reduce wasted space to less than one
>>> machine word/line per allocated item. [...]
>>Actually, it can be done by machine. [...]
>
>All true.  In the compilers courses I teach, I've been mentioning structure
>member re-arrangement as an integral part of data structure allocation
>within a compiler.  It works really well for languages like Pascal, however,
>there is a big problem with this for C code.
>
>In C, it has been a very common idiom to ASSUME that the address of the first
>member of a struct IS the address of the struct.  For example: [elided]

I brought this up as an advanced discussion topic in 211 which I TA.

The big problem that you're referring to is probably the injunction against
reordering structure members, viz., Section A8.3 of K&R 2nd Ed (pg 213).
You'll find it in the ANSI std too.  So, the assumption is valid for all
architectures that do not require padding before the first element of the
struct.  Does anybody know of any?  I'd conjecture that no machine is that
silly.

There are many uses for not reordering.  The first is just plain old
simplicity -- the KISS rule.  If you're writing a device driver, you'd like
to have fine control over member placement.  If you're interfacing to
foreign language routines, you'd like to have fine control over member
placement (accessing common blocks f77 on Vaxen, for example, is done via
using an extern struct/union with the name of the struct/union being that of
the common block with an underscore postpended).  Even if all you want is to
make it simple to interface with assembler, then you'd still want no
reordering:  you'd want easily understood member placement rules so your
assembler writer will have a chance -- and the leave-it-alone rule is the
easiest.

C is a low/mixed level language.  I want C compilers to do exactly what I
told it to do (whatever that may be -- look to the language specs)!  Like
structure member ordering, I want C compilers to listen when I tell it to
put something in a register -- if I don't bother, then it can do all the
analysis it wants, but if I _do_....  There are too many `optimizing'
compilers that (1) can't quite optimize the code as much as I'd like and (2)
when given hand tuned C code that should translate nicely to the underlying
machine code, bungle things because it wasn't willing to listen.  Why hand
tune C and not assembler?  Portability and maintainability.  When I hand
tune a program for a particular machine, it's nice to be able to run it on
another without having to rewrite code.

Until there's a keyword to explicitly allow/disallow member reordering (ala
register), it is an implementation flaw to reorder structure members.
Storage compaction by aggregate reordering is fine in a higher level
language -- but if you want your language to be able to express
systems-level code, leave it out!  Just because something is possible
doesn't mean it should be done.

-bsy
-- 
Internet:  bsy@cs.cmu.edu		Bitnet:	 bsy%cs.cmu.edu%smtp@interbit
CSnet:     bsy%cs.cmu.edu@relay.cs.net	Uucp:    ...!seismo!cs.cmu.edu!bsy
USPS:      Bennet Yee, CS Dept, CMU, Pittsburgh, PA 15213-3890
Voice:     (412) 268-7571
--