From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Stefan Monnier Newsgroups: gmane.emacs.devel Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG. Date: Wed, 22 Feb 2012 15:25:16 -0500 Message-ID: References: NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: dough.gmane.org 1329942329 23254 80.91.229.3 (22 Feb 2012 20:25:29 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Wed, 22 Feb 2012 20:25:29 +0000 (UTC) Cc: emacs-devel@gnu.org To: Paul Eggert Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Wed Feb 22 21:25:29 2012 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([140.186.70.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1S0Ikd-0004gv-1p for ged-emacs-devel@m.gmane.org; Wed, 22 Feb 2012 21:25:23 +0100 Original-Received: from localhost ([::1]:34659 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Ikc-00022X-AA for ged-emacs-devel@m.gmane.org; Wed, 22 Feb 2012 15:25:22 -0500 Original-Received: from eggs.gnu.org ([140.186.70.92]:45282) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0Ika-00022H-14 for emacs-devel@gnu.org; Wed, 22 Feb 2012 15:25:20 -0500 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1S0IkY-0005Jn-8r for emacs-devel@gnu.org; Wed, 22 Feb 2012 15:25:19 -0500 Original-Received: from ironport2-out.teksavvy.com ([206.248.154.181]:64979) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1S0IkY-0005JW-6M for emacs-devel@gnu.org; Wed, 22 Feb 2012 15:25:18 -0500 X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Av0EAABORU9Ld/XJ/2dsb2JhbABEDrI9gQiBdAEFViMQCzQSFBgNJL8ejF1hFwYFAwKFFwqEGwSIT5YjhHaEBlU X-IronPort-AV: E=Sophos;i="4.73,465,1325480400"; d="scan'208";a="164210753" Original-Received: from 75-119-245-201.dsl.teksavvy.com (HELO pastel.home) ([75.119.245.201]) by ironport2-out.teksavvy.com with ESMTP/TLS/ADH-AES256-SHA; 22 Feb 2012 15:25:16 -0500 Original-Received: by pastel.home (Postfix, from userid 20848) id 7865D59173; Wed, 22 Feb 2012 15:25:16 -0500 (EST) In-Reply-To: (Paul Eggert's message of "Wed, 22 Feb 2012 07:55:46 -0800") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/24.0.93 (gnu/linux) X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 206.248.154.181 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:148712 Archived-At: > +/* On hosts where VALBITS is greater than the pointer width in bits, > + USE_LSB_TAG is: > + a. unnecessary, because the top bits of an EMACS_INT are unused, > + b. slower, because it typically requires extra masking, and Is this just a gut-feeling, or is there some actual measurement behind this assertion? What kind of extra masking are you referring to? The XFASTINT? Note that the LSB masking can be cheaper than the MSB masking (because the mask is a smaller value which fits more easily in an immediate value). I haven't made any measurements (the motivation for LSB tags was not speed but addressing range), but I'd find it surprising if LSB tags are generally slower. > + c. harmful, because it can create Lisp_Object values that are so scrambled > + that mark_maybe_object cannot decipher them. mark_maybe_object assumes > + that EMACS_INT values are contiguous, but a host where EMACS_INT is > + wider than a pointer might allocate the top half of an EMACS_INT in > + (say) a 32-bit word on the stack, putting the bottom half in a 32-bit > + register that is saved elsewhere in a jmp_buf. When this happens, > + since USE_LSB_TAG is not defined the bottom half alone is a valid > + pointer that mark_maybe_pointer can follow; but if USE_LSB_TAG were > + defined, the bottom half would not be a valid pointer and neither > + mark_maybe_object nor mark_maybe_pointer would follow it. I see. So "VALBITS is greater than the pointer width in bits" is not the exactly right condition (e.g. if we have 48bit pointers and 61 VALBITS then the problem should not appear). Maybe a better fix is to add code to the stack marking loop, conditional on WIDE_EMACS_INT and USE_LSB_TAGS, which passes pointer-sized words to mark_maybe_object after expanding them to EMACS_INT size. Stefan