Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Are/were the relative goto instructions ever emitted? #17

Closed
pipcet opened this issue Dec 22, 2017 · 7 comments
Closed

Are/were the relative goto instructions ever emitted? #17

pipcet opened this issue Dec 22, 2017 · 7 comments

Comments

@pipcet
Copy link
Collaborator

pipcet commented Dec 22, 2017

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.

@rocky
Copy link
Owner

rocky commented Dec 22, 2017

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.

@pipcet
Copy link
Collaborator Author

pipcet commented Dec 22, 2017

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.

@rocky
Copy link
Owner

rocky commented Dec 24, 2017

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.

@larsbrinkhoff
Copy link
Collaborator

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.

@rocky
Copy link
Owner

rocky commented Apr 5, 2018

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

@larsbrinkhoff
Copy link
Collaborator

Thanks. Your proposed change looks good to me.

No link necessary.

@rocky
Copy link
Owner

rocky commented Apr 5, 2018

I think we've beat this issue to death.

@rocky rocky closed this as completed Apr 5, 2018
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants