From mint-bounce@lists.fishpool.fi Tue Jan 22 17:29:09 2008 X-Original-To: fnaumann@mail.boerde.de Delivered-To: fnaumann@mail.boerde.de Message-ID: Date: Sun, 25 Nov 2007 13:17:13 +0100 From: "Thomas Huth" To: "=?UTF-8?Q?Vincent_Rivi=C3=A8re?=" , emutos-devel@lists.sourceforge.net Subject: Re: [MiNT] [Emutos-devel] Emutos and gcc-4.2.2 Cc: mint@fishpool.com In-Reply-To: <47476378.1080906@users.sourceforge.net> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Disposition: inline References: <4745708C.5010104@users.sourceforge.net> <20071123005939.11adea43@phineus> <47476378.1080906@users.sourceforge.net> X-ecartis-version: Ecartis v1.0.0 Sender: mint-bounce@lists.fishpool.fi Errors-To: mint-bounce@lists.fishpool.fi X-original-sender: th.huth@googlemail.com Precedence: bulk List-help: List-unsubscribe: List-Id: X-List-ID: List-subscribe: List-owner: List-post: X-Virus-Scanned: by amavisd-new at relay.boerde.de X-Spam-Checker-Version: SpamAssassin 2.63 (2004-01-11) on relay.boerde.de X-Spam-Status: No, hits=-1.0 tagged_above=-50.5 required=7.0 tests=BAYES_00 X-Spam-Level: Content-Transfer-Encoding: 8bit X-MIME-Autoconverted: from base64 to 8bit by freemint id m0MGP1as004618 Status: X-Status: X-Keywords: Hi! On Nov 24, 2007 12:34 AM, Vincent Rivière wrote: > I'm very happy you used my compiler ! So you recompiled it ? On which > system ? It's always interesting to hear success stories ! I had to recompile it since I am running Linux on my PowerMac (Silver G4), so that I can not use the pre-compiled binaries. Thanks to your "build script howtos" the recompilation was very easy! Kudos to you for that! > In my next build, I'll disable the a0/d0 stuff, in order to make a more > standard compiler. It's really easy, just some defines to remove. Great :-) > I would like to speak about another "feature" : alignment. > > By default, GCC aligns structure members on 4-byte boundaries, producing > useless 2-byte holes in a structure where longs and shorts are mixed. I > patched it long ago to use a 2-byte default alignment, so no space is > wasted. Some people said that the 68020+ CPU have faster memory access > to longs aligned on 32-bit boundaries. Is it true on Atari computers ? I've heard that, too, but I am not an expert here ... that's maybe a better question to the MiNT developers since they are more likely working on 68030 machines than the folks here on the EmuTOS mailing list. > I recently discovered another "feature" of GCC. When function arguments > are pushed on the stack, they are aligned on an "int" boundary. When > compiling with -mshort, there is no additional filler. But when -mshort > is not used, pushing a short then a long causes the long to be aligned 2 > bytes further. A short filler is inserted between the 2 values. Just > like structure alignment, it seems to me that such alignment is useless > on the Atari platform. I plan to remove this alignment in my next build. Well, I think the default size of items that are pushed on the stack should be sizeof(int). For example when you have declared following function in one file: int myfunc(int a, int b) { return a + b; } And in another file you call myfunc(3, 5), but there is no prototype for myfunc before... ... this is perfectly valid C (despite it's ugly due to the missing prototype), but it will fail as soon as you disable this "filler" values on the stack. I think it's better not to disable these "fillers". Thomas