From owner-freebsd-alpha@FreeBSD.ORG Mon Mar 15 00:48:19 2004 Return-Path: Delivered-To: freebsd-alpha@freebsd.org Received: from mx1.FreeBSD.org (mx1.freebsd.org [216.136.204.125]) by hub.freebsd.org (Postfix) with ESMTP id 86D3116A4CE for ; Mon, 15 Mar 2004 00:48:19 -0800 (PST) Received: from smtp4.jp.viruscheck.net (smtp4.jp.viruscheck.net [154.33.69.55]) by mx1.FreeBSD.org (Postfix) with ESMTP id 60FBD43D1F for ; Mon, 15 Mar 2004 00:48:19 -0800 (PST) (envelope-from bland@freebsd.org) Received: from scan3.jp.viruscheck.net ([154.33.69.38] helo=mail1.jp.viruscheck.net) by smtp4.jp.viruscheck.net with esmtp (Exim 3.36 #1) id 1B2nlZ-00077K-00; Mon, 15 Mar 2004 17:48:09 +0900 Received: from [219.167.14.54] (helo=noc.orchid) by mail1.jp.viruscheck.net with esmtp (Exim 3.36 #3) id 1B2nlZ-0005Jj-00; Mon, 15 Mar 2004 17:48:09 +0900 Received: from FreeBSD.org (horse.orchid [89.60.10.11]) by noc.orchid (8.12.11/8.12.11) with ESMTP id i2F8m8Nv049919; Mon, 15 Mar 2004 17:48:08 +0900 (JST) (envelope-from bland@FreeBSD.org) Message-ID: <40556DC8.2060900@FreeBSD.org> Date: Mon, 15 Mar 2004 17:48:08 +0900 From: Alexander Nedotsukov User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.1; en-US; rv:1.7a) Gecko/20040219 X-Accept-Language: en-us, en MIME-Version: 1.0 To: ticso@cicely.de References: <405554D9.4000208@FreeBSD.org> <20040315072848.GW55325@cicely12.cicely.de> In-Reply-To: <20040315072848.GW55325@cicely12.cicely.de> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit cc: alpha@FreeBSD.org Subject: Re: Is the way static data alligned correct? X-BeenThere: freebsd-alpha@freebsd.org X-Mailman-Version: 2.1.1 Precedence: list List-Id: Porting FreeBSD to the Alpha List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 15 Mar 2004 08:48:19 -0000 Bernd Walter wrote: >On Mon, Mar 15, 2004 at 04:01:45PM +0900, Alexander Nedotsukov wrote: > > >>Guys, >> >>Recently doing some development I hit alignment problem on alpha >>machines. Problem solved but the way I did it in fact the reason why I >>asking pros to judge who is wrong here. >>Inside code I have linked-in data blocks generated by external tool. >>They looks like this: >> const unsigned char raw_data_block[] = { bla-bla-bla }; >>Internal block content is 8 bytes aligned. Each block resides in a >>single .c file. So after compilation I have a set of .o files linked >>later into single shared object (library). Taking an address of such >>data block and casting it to pointer to some real structure was a >>problem because it is not necesary 8 byte aligned. Obvious solution was >>to ask explicitly for such alignment: >> const unsigned char raw_data_block[] __attribute__ ((alligned(8))) = >>{ bla-bla-bla }; >>But I wonder is this gcc bug or space optimization for char arrays only? >> >> > >You request an array of bytes and you get the natural alignment of >bytes - why should the compiler waste bytes that are not required for >the variable you define? > > Mmm... It was my pure speculation around the fact that Alpha can read memory only from addreses divisible by eight or raise an alignment error. So natural byte alignment was not so natural for Alpha in my understanding. Btw on stack (automatic variables) where space savings may have more sence than in .data segment char[] allocations are always 8 bytes aligned. But I sholud admit that my expirience in alpha programming not much bigger than beast uptime :-) >A portable way would be to define it as a union with an int64_t. > >But the real point is that you shouldn't access any variable with >stricter alignment than they are. >If you have const data as in your example then define it as the >correct structure. > > Thanks for the portability tip. I think originally code was written this way to avoid differences in generated binary file supposed to be shared across different platforms and linked-in parts. I'll try to do things right in next code review. >If it's not constant data then bcopy it into your structure or >directly read it in a malloc'ed buffer. > > >