From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ihor Radchenko Newsgroups: gmane.emacs.devel Subject: Re: Shrinking the C core Date: Mon, 21 Aug 2023 05:06:15 +0000 Message-ID: <87pm3h56ig.fsf@localhost> References: <20230809094655.793FC18A4654@snark.thyrsus.com> <874jkub40o.fsf@dataswamp.org> <87jztqdw2l.fsf@localhost> <87msym9i4r.fsf@dataswamp.org> <877cpp914t.fsf@localhost> <83fs4dwwdo.fsf@gnu.org> <874jkt90a5.fsf@localhost> <87y1i57jqi.fsf@localhost> <87pm3h7h8k.fsf@localhost> <87h6ot7cf3.fsf@localhost> <87edjx7c0b.fsf@localhost> <831qfxw2cx.fsf@gnu.org> <87v8d95918.fsf@localhost> <87zg2lav4b.fsf@yahoo.com> <87sf8d57wf.fsf@localhost> <87r0nxatu1.fsf@yahoo.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15463"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , ams@gnu.org, incal@dataswamp.org, emacs-devel@gnu.org To: Po Lu Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Aug 21 07:06:43 2023 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 1qXx7i-0003qF-Tr for ged-emacs-devel@m.gmane-mx.org; Mon, 21 Aug 2023 07:06:42 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qXx6z-0004g7-Kc; Mon, 21 Aug 2023 01:05:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXx6y-0004ft-3y for emacs-devel@gnu.org; Mon, 21 Aug 2023 01:05:56 -0400 Original-Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qXx6t-0000xk-Dk for emacs-devel@gnu.org; Mon, 21 Aug 2023 01:05:55 -0400 Original-Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 838A0240104 for ; Mon, 21 Aug 2023 07:05:49 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1692594349; bh=wPZ0DirkUQcppqslFMFTl1lDHbpkYp4vLosf1tFePH8=; h=From:To:Cc:Subject:Date:Message-ID:MIME-Version:From; b=TZgpc71LhKrBwA+JDCVWxEWE47g7M3yjn0S9/cD5IN8o6GQeUZ4aPZaPZBDsNli/+ GuD9s1l3dgrDFXj1vrSgcYA6yaT0mLmft8fRWqAh30rmQRMeujm0GZu6r6Qk8s36gE H4oQuwdDQu6vzk7weejL9OzhOS/czLBrkUgONIa3jhYU8YUkk8Rkg8Iu/bTGlmfJXf Pugsjvs9ZGIBRVoAnAhLhbaXYYVZSn7YHRYWskHYuZz3rakIdJRNae5exiS0fbqo25 o65jMkVKnACAYHu9BJvIANJWrI+tg93MSOIbG10g0TUcFXO4RiyTkQgIzTsWJ2w1A8 N5o9PtRMMAb3w== Original-Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4RTgRJ6L1Yz6txP; Mon, 21 Aug 2023 07:05:48 +0200 (CEST) In-Reply-To: <87r0nxatu1.fsf@yahoo.com> Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -53 X-Spam_score: -5.4 X-Spam_bar: ----- X-Spam_report: (-5.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H5=-1, RCVD_IN_MSPIKE_WL=-0.01, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309020 Archived-At: Po Lu writes: >> `car' implementation is very unlikely to change in future. > > Why not? Mostly because such basic functions are rarely changed. Of course, it is not impossible that `car' is changed in future. >> But `floor' and other functions (we should not be limited to `floor') >> may change their implementations. The extra "native comp" copy of the >> implementation will need to be always synchronized with the original >> implementation. I doubt that it is practical maintenance-wise. > > How and why so? How are Fcar and Ffloor divergent in this department? `floor' might also be rather stable. I was mostly referring to "we should not be limited to `floor'" - it may be a problem for other functions. But let me rephrase it in other terms: what you propose will require maintaining two separate implementations of subroutines - one in C, and one specially tailored to GCC JIT psudocode. This may be doable for a small set of core primitives, but not scalable if we want to make more subroutines benefit from GGC JIT optimizations. Another idea, if rewriting in Elisp is not feasible, could be somehow structuring the internal C code in such a way that we can derive GCC JIT pseudocode right from the C function bodies. For example, Ffloor could be (1) split into smaller functions dedicated to certain argument type combinations; (2) record a metadata readable by native comp code about which small function correspond to different argument types. Then, native comp can emit direct calls to these smaller (and faster) functions when the type is known. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at