[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: native compilation units

From: Lynn Winebarger
Subject: Re: native compilation units
Date: Tue, 14 Jun 2022 10:55:37 -0400

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:
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 (<= 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.


reply via email to

[Prev in Thread] Current Thread [Next in Thread]