Help with adding new setq-based bytecodes (was: Help with adding an auxiliary bytecode table)

[Alex Gramiak]

Stefan Monnier <address@hidden> writes:

>> My initial reaction is that the stale bytecode is somehow incompatible,
>
> What/which stale bytecode?

I meant the bytecode of the previous byte compiler. It turned out not to
be the case (it was a faulty macro that caused this).

>> The problem is that since memq is a bytecode operation, it turns out
>> to be faster than vector-memq for small input
>
> Why is that a problem?

It'd be annoying (to me), since it would mean searching a small vector
of constants would be slower than searching a small list of constants.
Only by a bit, but still.

>> unless I make sure that memq isn't turned into a bytecode op.
>> So since the current space in the lookup table is limited, I figured
>> that a prefix command that looks up in a secondary table would be
>> a good solution.
>
> We don't have too many bytecodes left, indeed, but there are still some,
> IIRC, so it's not indispensable to go a 2-byte bytecodes.

No, but at least for vector-memq, I don't think it warrants taking up
that limited room. Also, I figured that there might be other primitives
that weren't added as a bytecode previously due to the lack of space
that could now be added to this secondary table. Possible candidates:

- append
- assoc
- string-match/match-string
- re-search-forward
- looking-at
- make-byte-code
- fboundp, functionp
- vector/vectorp
- apply
- gethash/puthash


Now I'm having a problem with adding certain bytecodes that (attempt to)
optimize these forms (since they're common in loops):

  (setq X (P X))
  (setq X (cons Y X))

But now when trying to build with the attached patch I get this error:

  make[2]: Entering directory '/home/alex/emacs-test/lisp'
    ELC      ../lisp/emacs-lisp/byte-run.elc

  emacs-lisp/byte-run.el:230:1:Error: Symbol’s value as variable is void: lambda


Is there a way to trigger the lisp debugger here? Calling (debug) before
the error line didn't help, nor did setting debug-on-error non-nil.

Do you have any idea what I did wrong? Making the optimization checks in
byte-compile-setq always fail allows me to build, and I've verified that
the checks don't pass false positives.

0001-Auxiliary-bytecode-table-WIP.patch
Description: WIP