cwj@ecs.soton.ac.uk (Chris Johnson) (02/01/90)
chris@mimsy.umd.edu (Chris Torek) writes: >In article <1810@sunquest.UUCP> terry@sunquest.UUCP (Terry Friedrichsen) >writes: >>Borrow Pascal's idea of "records" and "packed records". ... >This does not really cover all the possibilities. I think these >attributes do: > A. unordered structures: the compiler may rearrange these ... > B. packed unordered structures: the compiler may rearrange these... > C. external (packed and ordered) structures: the compiler may ... In general this should be specified by the programmer, not restricted to a few possibilities that may exclude some cases. We are dealing with two aspects of the data: logical structure (component names for creation and retrieval functions), and storage mapping. >(I would redirect this to comp.lang.c, but it does not really belong >there either.) This IS a language issue, as can be seen by considering Ada for a moment, rather than C: in Ada the representation/implementation mapping properties can be specified cleanly, separately from the type declarations, by using an unadorned structured type (record, array...) declaration and a separate but associated Representation Clause. Representations can specify exact bitfield placements for data within a program. Sure, the compiler has to do more work in translation, but alignment properties are fully under the programmer's control and the logic of the program remains portable (take away the representation cluase and the program should still work on another machine, albeit with some wasted space for default alignments and component ordering). The problem of trasmitting data between processors still exists, but that's a different area... see Lamb's IDL system software for instance.
rmb@mipon2.intel.com (Bob Bentley) (02/02/90)
In article <22197@mimsy.umd.edu> chris@mimsy.umd.edu (Chris Torek) writes: > >This does not really cover all the possibilities. I think these >attributes do: > > 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. > Note that Ada (gulp!) already supports these 3 paradigms : A - corresponds to the standard record type B - is provided via pragma PACK, which ".. specifies that storage minimization should be the main criterion when selecting the representation of a record or array type" C - is provided via a representation clause, which ".. can be provided to give more efficient representation or to interface with features that are outside the domain of the language (for example, peripheral hardware)" See Chapter 13 of the Ada LRM (ANSI/MIL-STD-1815A) for more details. As a point of information, the Intel 80960 architecture allows unaligned data accesses to and from memory with some performance penalty (moderate if the access falls entirely within a single 16-byte block, more severe if it spans a 16-byte boundary). Bob Bentley -------------------------------------------------------------------------------- | Intel Corp., M/S JF1-58 UUCP: rmb@omefs3.intel.com | | 5200 N.E. Elam Young Parkway Phone: (503) 696-4728 | | Hillsboro, Oregon 97124 Fax: (503) 696-4515 | --------------------------------------------------------------------------------
roelof@idca.tds.PHILIPS.nl (R. Vuurboom) (02/02/90)
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