From: Stefan Monnier <monnier@iro.umontreal.ca>
To: Paul Eggert <eggert@cs.ucla.edu>
Cc: emacs-devel@gnu.org
Subject: Re: [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG.
Date: Wed, 22 Feb 2012 15:25:16 -0500 [thread overview]
Message-ID: <jwvvcmyy6jk.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <E1S0EsZ-0006bE-5w@vcs.savannah.gnu.org> (Paul Eggert's message of "Wed, 22 Feb 2012 07:55:46 -0800")
> +/* On hosts where VALBITS is greater than the pointer width in bits,
> + USE_LSB_TAG is:
> + a. unnecessary, because the top bits of an EMACS_INT are unused,
> + b. slower, because it typically requires extra masking, and
Is this just a gut-feeling, or is there some actual measurement behind
this assertion?
What kind of extra masking are you referring to? The XFASTINT?
Note that the LSB masking can be cheaper than the MSB masking (because
the mask is a smaller value which fits more easily in an immediate
value).
I haven't made any measurements (the motivation for LSB tags was not
speed but addressing range), but I'd find it surprising if LSB tags are
generally slower.
> + c. harmful, because it can create Lisp_Object values that are so scrambled
> + that mark_maybe_object cannot decipher them. mark_maybe_object assumes
> + that EMACS_INT values are contiguous, but a host where EMACS_INT is
> + wider than a pointer might allocate the top half of an EMACS_INT in
> + (say) a 32-bit word on the stack, putting the bottom half in a 32-bit
> + register that is saved elsewhere in a jmp_buf. When this happens,
> + since USE_LSB_TAG is not defined the bottom half alone is a valid
> + pointer that mark_maybe_pointer can follow; but if USE_LSB_TAG were
> + defined, the bottom half would not be a valid pointer and neither
> + mark_maybe_object nor mark_maybe_pointer would follow it.
I see. So "VALBITS is greater than the pointer width in bits" is not
the exactly right condition (e.g. if we have 48bit pointers and 61
VALBITS then the problem should not appear).
Maybe a better fix is to add code to the stack marking loop, conditional
on WIDE_EMACS_INT and USE_LSB_TAGS, which passes pointer-sized
words to mark_maybe_object after expanding them to EMACS_INT size.
Stefan
next parent reply other threads:[~2012-02-22 20:25 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <E1S0EsZ-0006bE-5w@vcs.savannah.gnu.org>
2012-02-22 20:25 ` Stefan Monnier [this message]
2012-02-23 1:20 ` [Emacs-diffs] /srv/bzr/emacs/trunk r107377: * src/lisp.h: Improve comment about USE_LSB_TAG Paul Eggert
2012-02-23 3:15 ` Stefan Monnier
2012-02-23 6:31 ` Paul Eggert
2012-02-23 7:42 ` Stefan Monnier
2012-02-25 7:00 ` Paul Eggert
2012-02-25 10:06 ` Stefan Monnier
2012-02-25 19:46 ` Paul Eggert
2012-02-23 3:57 ` YAMAMOTO Mitsuharu
2012-02-23 6:28 ` Paul Eggert
2012-05-09 17:56 ` Paul Eggert
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvvcmyy6jk.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=eggert@cs.ucla.edu \
--cc=emacs-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.