Re: native compilation units

[Lynn Winebarger <owinebar@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 1636 bytes --]

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 <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.  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
>
>

[-- Attachment #2: Type: text/html, Size: 2528 bytes --]