Re: Data Structure Reorganizing Optimizations

yuri@shimari.cmf.nrl.navy.mil (Yuri Trifanov)
Mon, 31 Oct 1994 22:27:55 GMT

          From comp.compilers

Related articles
CProf cache profiling system available david@cs.wisc.edu (1994-10-13)
Re: Data Structure Reorganizing Optimizations john@iastate.edu (1994-10-22)
Re: Data Structure Reorganizing Optimizations robertb@HING.LCS.MIT.EDU (1994-10-26)
Re: Data Structure Reorganizing Optimizations johnm@cory.EECS.Berkeley.EDU (1994-10-22)
Re: Data Structure Reorganizing Optimizations stripes@uunet.uu.net (1994-10-27)
Re: Data Structure Reorganizing Optimizations bret@icicle.winternet.com (1994-10-23)
Data Structure Reorganizing Optimizations leichter@zodiac.rutgers.edu (1994-10-31)
Re: Data Structure Reorganizing Optimizations yuri@shimari.cmf.nrl.navy.mil (1994-10-31)
Re: Data Structure Reorganizing Optimizations ddg@cci.com (1994-10-31)
Re: Data Structure Reorganizing Optimizations amos@nsof.co.il (1994-11-01)
Re: Data Structure Reorganizing Optimizations pardo@cs.washington.edu (1994-10-31)
Re: Data Structure Reorganizing Optimizations fjh@munta.cs.mu.OZ.AU (1994-11-02)
Re: Data Structure Reorganizing Optimizations jeremy@sour.sw.oz.au (1994-11-02)
Re: Data Structure Reorganizing Optimizations prochak@cibadiag.com (1994-11-02)
[12 later articles]
| List of all articles for this month |

Newsgroups: comp.arch,comp.compilers
From: yuri@shimari.cmf.nrl.navy.mil (Yuri Trifanov)
Keywords: C, optimize
Organization: Followers of Vince
References: 94-10-108 94-10-156
Date: Mon, 31 Oct 1994 22:27:55 GMT

Andy Glew <glew@ichips.intel.com> wrote:


}I believe that C's rules about data structure organization are
}obsolete. Certainly, they are not in the ken of the usual programmer
}using C or C++. Why not permit compilers to do such "illegal" data
}structure reorganizations, bringing the performance gains Lebeck and
}Wood describes to the standard application?


and john@iastate.edu (John Hascall) responded


> Perhaps a "struct" should be paddable and/or reorganizable
> and a "packed struct" should not.


one of the problems that this causes is in trying to write code for
networking and other applications where more than one compiler/machine
type will be looking at the same bytes.


since there are other issues involved in these circumstances (such as
byte ordering and floating point format), it seems healthy to separate
those instances where the organization of bytes in memory is
important, as distinct from the compiler trying to provide the best
possible speed for a higher level contruct (member access)


having that distinction recognized by the compiler (as suggested
above) can mean significant savings over the use of an
encoding/decoding library both in function call overhead and inlining
with contextual optimization.
--


Post a followup to this message

Return to the comp.compilers page.
Search the comp.compilers archives again.