From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Marius Vollmer Newsgroups: gmane.lisp.guile.user Subject: Re: Issues in ia64 Date: 02 Jul 2002 21:01:25 +0200 Sender: guile-user-admin@gnu.org Message-ID: <87u1nij6nu.fsf@zagadka.ping.de> References: <20020629160009.7829.18795.Mailman@fencepost.gnu.org> <3D20F5D8.B92EE575@synopsys.com> NNTP-Posting-Host: localhost.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: main.gmane.org 1025637361 7257 127.0.0.1 (2 Jul 2002 19:16:01 GMT) X-Complaints-To: usenet@main.gmane.org NNTP-Posting-Date: Tue, 2 Jul 2002 19:16:01 +0000 (UTC) Cc: yluo@synopsys.com, guile-user@gnu.org Return-path: Original-Received: from fencepost.gnu.org ([199.232.76.164]) by main.gmane.org with esmtp (Exim 3.33 #1 (Debian)) id 17PT84-0001sf-00 for ; Tue, 02 Jul 2002 21:16:00 +0200 Original-Received: from localhost ([127.0.0.1] helo=fencepost.gnu.org) by fencepost.gnu.org with esmtp (Exim 3.34 #1 (Debian)) id 17PSvX-0003uT-00; Tue, 02 Jul 2002 15:03:03 -0400 Original-Received: from dialin.speedway43.dip26.dokom.de ([195.138.43.26] helo=zagadka.ping.de) by fencepost.gnu.org with smtp (Exim 3.34 #1 (Debian)) id 17PSuI-0003qJ-00 for ; Tue, 02 Jul 2002 15:01:52 -0400 Original-Received: (qmail 2159 invoked by uid 1000); 2 Jul 2002 19:01:25 -0000 Original-To: ttn@glug.org In-Reply-To: Original-Lines: 41 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.2 Errors-To: guile-user-admin@gnu.org X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.0.11 Precedence: bulk List-Help: List-Post: List-Subscribe: , List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: Xref: main.gmane.org gmane.lisp.guile.user:690 X-Report-Spam: http://spam.gmane.org/gmane.lisp.guile.user:690 Thien-Thi Nguyen writes: > alignment for 64 bit machines and such introduces to the specification > an MBZ field, let's call it machine-alignment-immediate-slack. There are two kinds of minimum alignment involved: the one needed for our tag system to work, and the one needed by the machine. We only need 8-byte alignment for the tag system, even when scm_t_cell is larger than 8 byte. On machines with 64 bit pointers, where scm_t_cell is 16 byte, we _could_ make use of the additional bit afforded by aligning scm_t_cell:s on 16-byte boundaries, but we don't need to. Given that we want to support 32-bit machines in the foreseeable future, it is probably easier to let the extra bit go to waste than to use two different tagging schemes on 32-bit and 64-bit platforms. Thus, for our tagging scheme, we don't need to align cells on 16 byte boundaries on 64-bit machines. The alignment needed by the machine is a different issue, we need to guarantee it no matter what. The machine alignment is guaranteed by malloc, and thus also by scm_gc_malloc, etc. Since we are using the memeory returned by malloc only as arrays of scm_t_bits and thus only use offsets that are (in bytes) a whole multiple of sizeof(scm_t_bits), we are not violating the alignment when creating the strange 'struct' layout. Or, with numbers: on a 32-bit platform the tag alignment is 8, the machine alignment is at most 4, which gives a total alignment of 8. On 64-bit platforms, the tag alignment is still 8, and the machine alignment is at most 8, which gives again a total of 8. So we are safe. This > /* Adjust it even further so it's aligned on an eight-byte boundary. */ > p = (scm_t_bits *) (((scm_t_bits) p + 7) & ~7); is only there the satisfy the alignment for the tag system, which is 8 bytes, regardless of pointer size. Therefore, I don't see the point of your patch. Did I get this wrong? _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://mail.gnu.org/mailman/listinfo/guile-user