🚀 go-pugleaf

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