From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Helmut Eller Newsgroups: gmane.emacs.devel Subject: Re: MPS native subrs Date: Wed, 26 Jun 2024 17:15:53 +0200 Message-ID: <87r0cj91li.fsf@gmail.com> References: <87v823xvq1.fsf@localhost> <87frt63dvt.fsf@gmail.com> <86o77ulgk8.fsf@gnu.org> <87zfre1p3r.fsf@gmail.com> <87zfreo5u6.fsf@localhost> <87plsa1n8k.fsf@gmail.com> <87wmmio3vq.fsf@localhost> <87jzii1hbs.fsf_-_@gmail.com> <8734p61evv.fsf@gmail.com> <87iky0zvyz.fsf@gmail.com> <87ikxwamor.fsf_-_@gmail.com> <8734p09pw7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="6742"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Eli Zaretskii , emacs-devel@gnu.org, larsi@gnus.org To: Gerd =?utf-8?Q?M=C3=B6llmann?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 26 17:16:11 2024 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 1sMUNX-0001Zu-RA for ged-emacs-devel@m.gmane-mx.org; Wed, 26 Jun 2024 17:16:11 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1sMUNM-0002dG-DT; Wed, 26 Jun 2024 11:16:00 -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 1sMUNK-0002cv-Jz for emacs-devel@gnu.org; Wed, 26 Jun 2024 11:15:58 -0400 Original-Received: from mail-ed1-x532.google.com ([2a00:1450:4864:20::532]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1sMUNJ-0002gL-2G; Wed, 26 Jun 2024 11:15:58 -0400 Original-Received: by mail-ed1-x532.google.com with SMTP id 4fb4d7f45d1cf-57d05e0017aso525758a12.1; Wed, 26 Jun 2024 08:15:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1719414954; x=1720019754; darn=gnu.org; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:from:to:cc:subject:date :message-id:reply-to; bh=TTwedSdOk4piODmu7Q2tk/Wc77VFnE/JPE14S3nJf7w=; b=IDsGTYOQ38uHXBZU1LnkqgdF+BcrW+p17nrZdUnLYRkNxvZZgd7wmnpzB+yl+TFQ+P M3T7d2HmU5xXIhIL7FTh1gfs2AZWGDuJrbN7lBQa3FYMf2aei6MGqaB9VlgGqz4GcU0T zIxKiE/uxHTaTau9yMISp/lCjTBKukI46TsV+SwpGfu2XFjlLbx44UPvLr6+UgS7uDKz LNZqJz5nl4v4JkR01rTjDKvm42cUvCTllkMb+08VxrIZeyH8qGYHSMFCLKEW5hGCZenK ovXBlTesskDhWSGjxYVMSC68HXBtD5aIY5UFX7rj0d07FfWNLI4ynWaPCjOSfEjY7ywF D/DA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1719414954; x=1720019754; h=content-transfer-encoding:mime-version:user-agent:message-id:date :references:in-reply-to:subject:cc:to:from:x-gm-message-state:from :to:cc:subject:date:message-id:reply-to; bh=TTwedSdOk4piODmu7Q2tk/Wc77VFnE/JPE14S3nJf7w=; b=l1uPuMQjgAWCL+Oni7yxruuwOB3QpktgidqnZntSvbbms4jQAsudUSkwok35oqY0YK R+RfdoQy1hyuF9W47uhxLMxYAKbNaThU7fyDvkpaGoKCxXhVOJ3PqnPI1GLT1jwf19b7 kE3zL4O6jCEdFTTV90NhH69lCKDFFYSCkvHtw14xLtMRdb1y/TPsIQEJM7nI6Nmu1Qsa bEyArFzBjQZFVX/HZoB/Ivb4CM2TBE3DkylvZU40WO07GwWB/54ElpsI8tJM+pAZQAw6 ziSqbnUAj0oUEbR6x6SjQCppzzMxhkYmG7S/LWohBbHoY4+2yVDrWm0YrOYXRxgAVqdg HKRQ== X-Forwarded-Encrypted: i=1; AJvYcCUrPbhiIv318bmDhQUlO7oiQMdCmM36RNNizRWdc4CiVukk714Ph8cPkkfUohTX00J9Dxp8sFAkfmLLEl+jd5WqZ0XC X-Gm-Message-State: AOJu0YyFhoj8tCqg2lgzjBr0Kkr+7zvhn+XopDyXLLyvLs8oQw9BZ1oG KsLCdt0Smrv8HRjOlqOJbAtk2LAhi3QHxkPeY27w2JZ5Kqhl0rMp X-Google-Smtp-Source: AGHT+IFlt7OLvUJ9y3QV2s872hU4LSUS/8ZOwjtJGIkyYZydhT9cZA/jGVfvkZcTRb03mCbXJAvyCw== X-Received: by 2002:a50:a688:0:b0:578:60a6:7c69 with SMTP id 4fb4d7f45d1cf-57d457f61d5mr8978422a12.30.1719414954197; Wed, 26 Jun 2024 08:15:54 -0700 (PDT) Original-Received: from caladan (dial-187254.pool.broadband44.net. [212.46.187.254]) by smtp.gmail.com with ESMTPSA id 4fb4d7f45d1cf-57d3040f42esm7222149a12.27.2024.06.26.08.15.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 26 Jun 2024 08:15:53 -0700 (PDT) In-Reply-To: ("Gerd =?utf-8?Q?M=C3=B6llman?= =?utf-8?Q?n=22's?= message of "Wed, 26 Jun 2024 09:00:14 +0200") Received-SPF: pass client-ip=2a00:1450:4864:20::532; envelope-from=eller.helmut@gmail.com; helo=mail-ed1-x532.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 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, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham 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:320712 Archived-At: On Wed, Jun 26 2024, Gerd M=C3=B6llmann wrote: >> More generally, it seems that the DEFUN macro works much like the DEFVAR >> macro, in the sense that it creates a struct and puts it in a static >> variable. So the Lisp_Subrs structs for primitives are, just like the >> Lisp_Fwd structs, already in the data section. We could re-use them >> instead of re-creating them in the dump. Of course, only if we can get >> rid of the command_modes field. > > And it would again greatly simplify things. Maybe we should just do it :-) Curiously, igc-info doesn't show any PVEC_SUBRS. I think this is going on: The pdumper does something special for primitives and builtin symbols (and threads). Those are dumped to the discardable section. On load, it first performs relocations and then copies everything from the discardable section to the data section. All builtin symbols can be copied with a single memcpy to lispsym because they are sorted and dumped in the correct order. The same happens for primitives: those are adjacent because the DEFUN macro sets the SUBR_SECTION_ATTRIBUTE. This explains why igc-info doesn't show any PVEC_SUBRS (unless configured with native compilation). So we already have what we want. It's probably no problem that we don't trace the subr section, because the command_modes field is nil anyway. I'm not sure why it is done this way; maybe it makes walking the object graph more uniform.