From mboxrd@z Thu Jan 1 00:00:00 1970 Path: main.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Alignment of Lisp_Subr Date: 12 Nov 2003 11:22:33 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1068657749 10533 80.91.224.253 (12 Nov 2003 17:22:29 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Wed, 12 Nov 2003 17:22:29 +0000 (UTC) Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Wed Nov 12 18:22:25 2003 Return-path: Original-Received: from quimby.gnus.org ([80.91.224.244]) by deer.gmane.org with esmtp (Exim 3.35 #1 (Debian)) id 1AJyhF-00062G-00 for ; Wed, 12 Nov 2003 18:22:25 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AJyhF-0001xZ-00 for ; Wed, 12 Nov 2003 18:22:25 +0100 Original-Received: from localhost ([127.0.0.1] helo=monty-python.gnu.org) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AJzXX-0002EC-9b for emacs-devel@quimby.gnus.org; Wed, 12 Nov 2003 13:16:27 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AJywK-0003yj-HS for emacs-devel@gnu.org; Wed, 12 Nov 2003 12:38:00 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AJyvl-0003tl-GU for emacs-devel@gnu.org; Wed, 12 Nov 2003 12:37:56 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AJyin-0001pu-I2 for emacs-devel@gnu.org; Wed, 12 Nov 2003 12:24:01 -0500 Original-Received: from vor.iro.umontreal.ca (vor.iro.umontreal.ca [132.204.24.42]) by mercure.iro.umontreal.ca (8.12.9/8.12.9) with ESMTP id hACGMXbj010674 for ; Wed, 12 Nov 2003 11:22:33 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id 44D423C547; Wed, 12 Nov 2003 11:22:33 -0500 (EST) Original-To: emacs-devel@gnu.org Original-Lines: 49 User-Agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50 X-DIRO-MailScanner: Found to be clean X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.2 Precedence: list List-Id: Emacs development discussions. List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Xref: main.gmane.org gmane.emacs.devel:17779 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17779 So I have finally gotten around to move my tags from the top 3 to the bottom 3 bits of a Lisp_Object so that Lisp_Objects can now be allocated anywhere. Here are the problems I'm facing (all of them due to the new constraint that objects need to be aligned on 8 byte boundaries) and I'm wondering what is the best solution for them: - Lisp_Misc has currently a size that is not a multiple of 8. I solved that by adding some padding with /* A miscellaneous object, when it's on the free list. */ struct Lisp_Free { int type : 16; /* = Lisp_Misc_Free */ unsigned gcmarkbit : 1; int spacer : 15; union Lisp_Misc *chain; #ifdef USE_LSB_TAG /* Try to make sure that sizeof(Lisp_Misc) is a multiple of 8. This assumes that Lisp_Marker is the largest of the alternatives. */ char padding[8 * ((sizeof (struct Lisp_Marker) - 1) / 8 + 1) - sizeof (struct Lisp_Intfwd)]; #endif }; I think this solution is acceptable since it only increases the size of Lisp_Misc objects from 5 words to 6 words (i.e. by 20%) on typical 32bit machines. Maybe we could reduce this cost by making use of this extra word, although I'm not sure how. - Structures of type Lisp_Subr are statically allocated and are not guaranteed to be aligned on a multiple of 8. I currently solve this by adding __attributes__ ((__aligned__ (8))), but this only works for GCC AFAIK. The only alternative I can think of is to add a padding field to Lisp_Subr and when its address is not a multiple of 8, memmove it by a few bytes (I think `defsubr' is the only place where we refer to these statically allocated Sfoo variables). Any comment on which approach is preferable ? - malloc does not guarantee on all systems that the returned value will be a multiple of 8 (or does it?). How can I check it so as to automatically determine whether I can set USE_LSB_TAG (i.e. in `configure'). Is a heuristic check of calling malloc a few times with a few different odd sizes sufficient? Stefan