From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Lynn Winebarger Newsgroups: gmane.emacs.devel Subject: Re: native compilation units Date: Tue, 14 Jun 2022 10:55:37 -0400 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000c034ab05e16999ea" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="16978"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Andrea Corallo , emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 14 16:57:53 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 1o17zM-0004F4-IP for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jun 2022 16:57:52 +0200 Original-Received: from localhost ([::1]:39200 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1o17zL-0001WW-A2 for ged-emacs-devel@m.gmane-mx.org; Tue, 14 Jun 2022 10:57:51 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:57166) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1o17xU-00085y-Cl for emacs-devel@gnu.org; Tue, 14 Jun 2022 10:55:59 -0400 Original-Received: from mail-vs1-xe32.google.com ([2607:f8b0:4864:20::e32]:39435) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1o17xP-0002Fl-Ru for emacs-devel@gnu.org; Tue, 14 Jun 2022 10:55:55 -0400 Original-Received: by mail-vs1-xe32.google.com with SMTP id n4so9199698vsm.6 for ; Tue, 14 Jun 2022 07:55:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=7xIW6YLWpLeUvA261AFqCmVEq+eWEDTEBHroICLYBWg=; b=ULqjX8MqGhhubbP6smkO8GvMR47cSCdUcHaUqmLOGkTAFPMANkft6zkdAqIrFqwHFZ /VyUMu3pC3IfJBQlJQQKr/2/uZGr4AHZUOioeiEnc3wN+0pZ1Jkodr9r8GV9U06j9ksX xb3/fRjItsvsO5WifSRGVb6IgCHng774LicUUvk7m5vjfN624C6vLz/ZtOKEHGAM0CEo NWS3YkNysUiMPDajToNyA1f2tchHoFOW4CDjMKmx+iRy5/VFoiKh+buV+q/Xgg+sNQIn nOjtPEz52PwSqAnBCvOVP/ZCuuDa6rdfNZaUx6Fkdd6WpkKtGcCWGjJNxQOi+NVSmO/1 Js3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=7xIW6YLWpLeUvA261AFqCmVEq+eWEDTEBHroICLYBWg=; b=TlaI1xhJj9rGTQcNWOsbQ9nqxkyrbO69D4CNl6x/BuUEXO8LMDNCOWhUkZg5Svdpn6 KYRcagUD5wDCEBK9ZRNfXJUu9/HEKxk5xts2hPoLUAlE2Q98rTjUODSIsYwuxLticOJa marFOPx/qnTZ+ijJteWuGtU3DtVaV1OyHZmbv8r8tEeTqotVR84DVNxEVeSxpBWbyU8X WPq/ZuVm9Se+eudHBFswzag6LTg4X5IyYfB40chALLK5DnCPRA/R4wveu0i3Gvcl/K7B x6Ffdme4+meThM29PI6l1QpUFl7614e8u5CHP3gVIoy/mbEFvtucxKHzvKKHk3VjO7uN dydw== X-Gm-Message-State: AJIora/Xx4tryWkraWhtaqR44UQ+getJohiv7UfC0rQKpFJ4/GJv81wi jka5Zmvw4e0TlDXeKgc1mmkiSPQdpRaEQLdVTsGD4zyCr38= X-Google-Smtp-Source: AGRyM1uC3SBULDKFRYXDVZSh+C2HexdlPkADPUFsOPsD4bIhOD01/XAh6MyzWulDmb9bNmaI+SNEEIL9hTkI1tnLpjU= X-Received: by 2002:a05:6102:6c5:b0:34c:498e:f78 with SMTP id m5-20020a05610206c500b0034c498e0f78mr2254817vsg.56.1655218550878; Tue, 14 Jun 2022 07:55:50 -0700 (PDT) In-Reply-To: Received-SPF: pass client-ip=2607:f8b0:4864:20::e32; envelope-from=owinebar@gmail.com; helo=mail-vs1-xe32.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, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 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" Xref: news.gmane.io gmane.emacs.devel:291180 Archived-At: --000000000000c034ab05e16999ea Content-Type: text/plain; charset="UTF-8" I think you may be remembering an intention to implement that. The issue came up in 2009 (before the byte-compiler even caught the error), and there's only the initial patch you committed to signal the error: https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/emacs-lisp/bytecomp.el?id=8476cfaf3dadf04379fde65cd7e24820151f78a9 and one more changing a variable name: https://git.savannah.gnu.org/cgit/emacs.git/commit/lisp/emacs-lisp/bytecomp.el?id=d9bbf40098801a859f4625c4aa7a8cbe99949705 so lines 954-961 of bytecomp.el still read: (dolist (bytes-tail patchlist) (setq pc (caar bytes-tail)) ; Pick PC from goto's tag. ;; Splits PC's value into 2 bytes. The jump address is ;; "reconstructed" by the `FETCH2' macro in `bytecode.c'. (setcar (cdr bytes-tail) (logand pc 255)) (setcar bytes-tail (ash pc -8)) ;; FIXME: Replace this by some workaround. (or (<= 0 (car bytes-tail) 255) (error "Bytecode overflow"))) I mainly quote this to say: see what I mean about losing starting off as putting aside temporarily? :-) I sent in the bug report. On Tue, Jun 14, 2022 at 8:23 AM Stefan Monnier wrote: > > Or, you could just create a vector with one thunk for each package and > > loop through it invoking each one. It wouldn't be as space > > efficient, but it would be trivially correct. > > IIRC the compiler has code to split a bytecode object into two to try > and circumvent the 64k limit and it should definitely be applicable here > (it's more problematic when it's inside a loop), which is why I think > it's a plain bug. > > > Stefan > > --000000000000c034ab05e16999ea Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
I think you may be remembering=C2=A0an intention to implem= ent that.=C2=A0 The issue came up in 2009 (before the byte-compiler=C2=A0even caught the error), and there's only the initial patch you commi= tted=C2=A0to signal the error:
and one more changing a variable name:
so lines 954-961 of bytecomp.el= still read:
    (dolist (bytes-tail =
patchlist)
      (setq pc (caar bytes-tail))	; Pick PC from goto's tag.
      ;; Splits PC's value into 2 bytes. The jump address is
      ;; "reconstructed" by the `FETCH2' macro in `bytecode.c=
'.
      (setcar (cdr bytes-tail) (logand pc 255))
      (setcar bytes-tail (ash pc -8))
      ;; FIXME: Replace this by some workaround.
      (or (<=3D 0 (car bytes-tail) 255) (error "Bytecode overflow&q=
uot;)))
I mainly quote this to say:=C2=A0 see what I mean about losing= starting off as putting aside temporarily? :-)
I sent in the bug= report.=C2=A0=C2=A0


On Tue, Jun 14, 2022 at 8:23= AM Stefan Monnier <monnier@= iro.umontreal.ca> wrote:
> Or, you could just create a vector with one thunk for = each package and
> loop through it invoking each one.=C2=A0 It wouldn't be as space > efficient, but it would be trivially correct.

IIRC the compiler has code to split a bytecode object into two to try
and circumvent the 64k limit and it should definitely be applicable here (it's more problematic when it's inside a loop), which is why I thi= nk
it's a plain bug.


=C2=A0 =C2=A0 =C2=A0 =C2=A0 Stefan

--000000000000c034ab05e16999ea--