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: Re: tags in the 3 lowest bits Date: 20 Nov 2003 00:14:07 -0500 Sender: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Message-ID: References: NNTP-Posting-Host: deer.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: sea.gmane.org 1069305348 23873 80.91.224.253 (20 Nov 2003 05:15:48 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Thu, 20 Nov 2003 05:15:48 +0000 (UTC) Cc: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+emacs-devel=quimby.gnus.org@gnu.org Thu Nov 20 06:15:45 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 1AMhAP-0002P0-00 for ; Thu, 20 Nov 2003 06:15:45 +0100 Original-Received: from monty-python.gnu.org ([199.232.76.173]) by quimby.gnus.org with esmtp (Exim 3.35 #1 (Debian)) id 1AMhAP-0008IF-00 for ; Thu, 20 Nov 2003 06:15:45 +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 1AMi7F-0006yg-Ir for emacs-devel@quimby.gnus.org; Thu, 20 Nov 2003 01:16:33 -0500 Original-Received: from list by monty-python.gnu.org with tmda-scanned (Exim 4.24) id 1AMi78-0006tG-Gh for emacs-devel@gnu.org; Thu, 20 Nov 2003 01:16:26 -0500 Original-Received: from mail by monty-python.gnu.org with spam-scanned (Exim 4.24) id 1AMi6T-0006JP-Dc for emacs-devel@gnu.org; Thu, 20 Nov 2003 01:16:16 -0500 Original-Received: from [132.204.24.67] (helo=mercure.iro.umontreal.ca) by monty-python.gnu.org with esmtp (Exim 4.24) id 1AMi6L-0006BP-80 for emacs-devel@gnu.org; Thu, 20 Nov 2003 01:15:37 -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 hAK5E8bj013223; Thu, 20 Nov 2003 00:14:08 -0500 Original-Received: by vor.iro.umontreal.ca (Postfix, from userid 20848) id ED2543C63E; Thu, 20 Nov 2003 00:14:07 -0500 (EST) Original-To: storm@cua.dk (Kim F. Storm) In-Reply-To: Original-Lines: 40 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:17945 X-Report-Spam: http://spam.gmane.org/gmane.emacs.devel:17945 > The only reason I can see for this is that there is a small > performance penalty on XFASTINT with LSB -- but I'd prefer that > penalty rather than having to support two different methods. I doubt the performance penalty is an issue. After all, manipulating MSB is generally slightly more costly than LSB, so the performance impact might even be positive. But I expect it's a wash. > Or are there systems which cannot use LSB? The LSB code needs pointers values that are multiples of 8. On some systems, malloc does not guarantee it. Probably we can use gmalloc.c for those systems, but we'll need to make sure that's an option and we'll need to figure out when that's nmecessary. Also, there might be systems that are word-addressed rather than byte-addressed. I don't know if such systems are still in use and whether Emacs runs on them, but if yes, we'll probably need to find some other way to deal with them, maybe keeping the old behavior. I also hope we can switch to LSB everywhere, but I don't think we can do that right now. I suggest to start with something like along the lines of #if defined GLIBC || defined GNU_MALLOC #define USE_LSB_TAG #endif And then slowly increase the number of systems where we use LSB. Basically, the same as is/was done for the conservative stack marking (that was recently turned on in MacOS). BTW, the patch has only seen fairly light testing. It works for me with PCL-CVS, Gnus, and bunch of other things but there might still be bugs lurking. I strongly suggest to run it with ENABLE_CHECKING (which my patch decouples from NO_UNION_TYPE). Stefan