Xref: utzoo comp.arch:13343 comp.lang.c:25308
Path: utzoo!utgpu!jarvis.csri.toronto.edu!cs.utexas.edu!rutgers!deimos!dino!hascall
From: hascall@cs.iastate.edu (John Hascall)
Newsgroups: comp.arch,comp.lang.c
Subject: Re: RISC Machine Data Structure Word Alignment Problems?
Message-ID: <369@dino.cs.iastate.edu>
Date: 24 Jan 90 01:48:42 GMT
References: <111@melpar.UUCP> <1990Jan21.224826.1699@esegue.segue.boston.ma.us> <LJ81OX3ggpc2@ficc.uu.net> <51245@bbn.COM> <21361@weitek.WEITEK.COM>
Sender: usenet@dino.cs.iastate.edu
Followup-To: comp.arch
Organization: Iowa State Univ. Computation Center
Lines: 39

In article <21361> weaver@weitek.UUCP (Michael Gordon Weaver) writes:
}In article <51245> slackey@BBN.COM (Stan Lackey) writes:
}>There are a number of interesting applications that build many
}>instances of small data structures, each containing varied data types.
}>It was said that logic simulators do this.  In a machine that forces
}>you to always have data aligned, this can result in lots of wasted
}>memory.  Not because the programmer is stupid, but because of the
}>nature of the application.
 
}I want to point out here that this data alignment problem can be 
}mostly worked around for application programs. 
 
} [sort elements of structures by decreasing size...]


  It seems to me that now we have a conflict between "software engineering"
  and architecture.

  It surely seems to me that, from a programming point of view, you would
  want your structures in some meaningful order as an aid to program
  understanding.  Shouldn't elements that are used together, be located
  together?

  And doesn't everyone pretty much expect certain elements at the top
  of structures, for example:

    struct FOO {                   struct BAR {
        struct FOO  *next;             struct BAR  *left;
        struct FOO  *prev;             struct BAR  *right;
          :                              :
    };                             };

  And on machines with "displacement mode" addressing (i.e., 32(R4) addresses
  the element 32 bytes into the structure at the address in register four)
  there is often a bonus (e.g., speed or code size) for elements within some
  distance (i.e., 127 bytes) from the start of the structure.  So if you put
  the big elements first, you minimize the number of "close" elements.

John Hascall  /  ISU Comp Ctr