From mint-bounce@lists.fishpool.fi Sun Jan 11 11:48:16 2009 From: Eero Tamminen Organization: Koti To: mint@lists.fishpool.fi Subject: Re: [MiNT] struct align Date: Sun, 11 Jan 2009 18:41:27 +0200 User-Agent: KMail/1.9.9 Cc: "Miro Kropacek" , "Mint list" References: <200901111800.25776.oak@helsinkinet.fi> In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: 7bit Content-Disposition: inline Message-Id: <200901111841.28063.oak@helsinkinet.fi> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-to: mint-bounce@lists.fishpool.fi X-original-sender: oak@helsinkinet.fi Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: Hi, On Sunday 11 January 2009, Miro Kropacek wrote: > > No, the alignment is decided based on what the CPU requires and which > > is faster. > > [...] > > I see your point, I know all this stuff. I was wondering why gcc/68k does > this -- for CPU >= 68020 (definitely for 060) is faster to align stuff on > 4 bytes boundaries (16 bytes if reading bigger chunks). Which CPU model you were specifying for the compiler? > So either gcc is > such smart and it sees I'm picking up values one-by-one in that order > (but this doesn't explain that gap for 2 bytes align) or gcc simply > should align it on 4 byte boundary when it's long variable. Or do you > have any other explanation for it? I don't say gcc is wrong I just want > to know the reason why it behaves in this way :) I don't know, maybe it's a reasonable default compromise? The whole data size affects the performance too (does it fit into cache) and I think for that kind of stuff gcc is quite dumb and uses default values (which programmer can override) which are reasonable for a wide variety of programs. - Eero