Path: utzoo!utgpu!jarvis.csri.toronto.edu!clyde.concordia.ca!uunet!mcsun!hp4nl!philapd!ssp11!roelof
From: roelof@idca.tds.PHILIPS.nl (R. Vuurboom)
Newsgroups: comp.arch
Subject: Re: structures (was RISC Machine Data Structure Word Alignment Problems)
Message-ID: <640@ssp11.idca.tds.philips.nl>
Date: 2 Feb 90 14:36:00 GMT
References: <1810@sunquest.UUCP> <22197@mimsy.umd.edu>
Organization: Philips Telecommunication and Data Systems, The Netherlands
Lines: 45

In article <22197@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes:
>(I would redirect this to comp.lang.c, but it does not really belong
>there either.)

I feel a little guilty too...

>
> A. unordered structures: the compiler may rearrange these to save
>    space.
> B. packed unordered structures: the compiler may rearrange these, and
>    should favor space over time everywhere, to the extent of generating
>    slow instruction sequences.
> C. external (packed and ordered) structures: the compiler may neither
>    rearrange them, nor insert any padding.  These structures must also
>    allow bit fields and bit and byte level ordering.
>
Well, almost agreed but I view it a little differently.
The discussion appears to have revealed 3 market requirements:

	- time optimzation:
	  the compiler may do whatever it wants (within reason :-) to 
	  achieve maximum performance; this could include padding and/or 
	  reordering

	- space optimization:
	  the compiler may do whatever it wants to achieve maximum
	  data space efficiency; this could include no padding and/or
	  reordering (your B). Data size access may also be larger
	  if this is convenient to the hardware (a long word access to memory 
	  even if only a byte is needed). 

	- no optimization
	  the compiler must do whatever it can to leave the structure
	  as is: no padding and no reordering (your C). Data width
	  access must be that of the requested field size if possible.
	  (don't want to upset your device) 




-- 
You'ld be surprised how much plastic is used in a Citroen BX.
(Try rear-ending somebody sometime...)
Roelof Vuurboom  SSP/V3   Philips TDS Apeldoorn, The Netherlands   +31 55 432226
domain: roelof@idca.tds.philips.nl             uucp:  ...!mcvax!philapd!roelof