From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Time to merge scratch/correct-warning-pos into master, perhaps? Date: Fri, 04 Feb 2022 21:46:06 +0200 Message-ID: <838ruq2z5t.fsf@gnu.org> References: <6a5bb5a08b3d764611f9@heytings.org> <6a5bb5a08b6337d733c5@heytings.org> <83leyq3kfk.fsf@gnu.org> <83a6f631k3.fsf@gnu.org> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="33973"; mail-complaints-to="usenet@ciao.gmane.io" Cc: larsi@gnus.org, mattiase@acm.org, gregory@heytings.org, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: Alan Mackenzie Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Feb 04 21:13:31 2022 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1nG4xX-0008gn-Ip for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Feb 2022 21:13:31 +0100 Original-Received: from localhost ([::1]:56918 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nG4xW-0008R8-H6 for ged-emacs-devel@m.gmane-mx.org; Fri, 04 Feb 2022 15:13:30 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:36448) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nG4XN-0006Nw-F8 for emacs-devel@gnu.org; Fri, 04 Feb 2022 14:46:29 -0500 Original-Received: from [2001:470:142:3::e] (port=57272 helo=fencepost.gnu.org) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nG4XH-0005lw-Jq; Fri, 04 Feb 2022 14:46:26 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=sFuDvkxGrEyQI2JEAR5BIxVEXQW6Byfg42n8G0MlF2Q=; b=adnTvGlwtLis b2lIYKBHtkC86khnuqDyz8oWksqjDxPwua++Iqg41D0eF88KjEgvjaQ3Hsumr+ACGpRzl8U2A+cuS Pxzke9nyyajQWhbwiZtiUCo/Z/rdmDbtSmD3zEEDj8x3WOQX8CLhm/60MluTLVHJCYGrsiRbAkWP/ 4UmBkO0U1kiqju9CqDC6f4fR/KDL9oQZ34KEOY5w7qKHQqn1vu9sCceHzoaPonRwyJeU6sl0ZPGVt 5ZGaNA30Sl3/40bvk6g1ziCxD5f/9WT8tBPXdjYVm9XghDC+gcIEL55TxVF0lwsuh+yyVCB2PW3j0 /70mKb9ONyATe8UA2vXhJg==; Original-Received: from [87.69.77.57] (port=4237 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nG4X9-00021m-PX; Fri, 04 Feb 2022 14:46:21 -0500 In-Reply-To: (message from Alan Mackenzie on Fri, 4 Feb 2022 19:33:28 +0000) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 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-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:285872 Archived-At: > Date: Fri, 4 Feb 2022 19:33:28 +0000 > Cc: gregory@heytings.org, monnier@iro.umontreal.ca, mattiase@acm.org, > larsi@gnus.org, emacs-devel@gnu.org > From: Alan Mackenzie > > > > > . comparison of a symbol and symbol-with-pos should only compare the > > > > symbol part, and disregard the "pos" part, right? > > Yes. > > > > > . if so, couldn't we implement symbol-with-pos as a struct that has > > > > the symbol at its beginning, and then use memcmp to compare only > > > > that part? > > > > > Or what am I missing? > > > > I don't think we can get anywhere that way. What gets compared in EQ > > > are the Lisp_Object's, which are typically already in processor > > > registers. I don't think we typically have a pointer to memory > > > containing the symbol with position. > > > Sorry, I don't understand how this answers my questions. > > OK, I don't think we can improve the performance by the use of a struct > containing the symbol followed by the position. I'm not sure what more I > can add. Then let me ask guiding questions. First, are symbols-with-pos supposed to happen in bytecode that doesn't deal with byte compilation? If yes, why/when would such objects appear in GP bytecode? > We cannot extend struct Lisp_Symbol with the position, since a single > symbol typically occurs several times in different positions. So? That would just mean there could be several different Lisp objects whose "symbol parts" are identical, but the position parts are different. Right? > > What is there in a symbol-with-pos except the symbol and the position? > > There is the symbol, the position, and a pseudovector header. The pseudovector part is not needed if we just extend Lisp_Symbol to have an additional field 'position'.