Are/were the relative goto instructions ever emitted?
pipcet opened this issue · 7 comments
Are BRgoto etc. ever emitted? If no, were they, and in which versions?
I can't find any live code that would emit them, and I don't think they're disassembled properly. On the other hand, bytecode.c does seem to handle them.
As you no doubt know, but I'll put it here for others, bytecode.c lists obsolete instructions, although it is silent about this one and the one in #26.
Stefan explains the rationale for handling obsolete opcodes in
https://lists.gnu.org/archive/html/emacs-devel/2017-12/msg00778.html
although I think this is a little bit misguided. At a minimum, obsolete instructions 0153 scan_buffer and 0163 set_mark are not currently handled.
I don't think Stefan's claim is strictly true, but I get the impression we're talking about some very few really ancient Emacs versions here. However, there might not really be a way to find out other than actually digging through the repository and maybe even building the old versions.
There's also this bit in lread.c:
readevalloop (Qget_file_char, &input, hist_file_name,
0, Qnil, Qnil, Qnil, Qnil);
else
{
/* We can't handle a file which was compiled with
byte-compile-dynamic by older version of Emacs. */
specbind (Qload_force_doc_strings, Qt);
readevalloop (Qget_emacs_mule_file_char, &input, hist_file_name,
0, Qnil, Qnil, Qnil, Qnil);
}
...which seems contradictory. Either we can't handle those files and should bail out, or we can handle them, by forcing eager loading of docstrings, in which case the comment is misworded.
In going over the history, looks like this was added in the infamous Emacs 19 release where jwz and Hallvard made a number of big changes. "unbind-all" as never used, so these might be in that category too. Although it was Hallvard who made the change here.
Note that it may not just be Emacs itself that is using peculiar opcodes. E.g. I have made a Forth assembler for the full range of Emacs bytecodes. Admittedly, these use cases are rare.
@larsbrinkhoff I have just corrected this and added text to the "lars" branch. Please review. We can also add a link to your forth assembler, if you think it worthy.
Thanks. Your proposed change looks good to me.
No link necessary.
I think we've beat this issue to death.