Re: native compilation units

[Lynn Winebarger]

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