unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* Question regarding Lisp_Object representation of symbols
@ 2024-03-06  6:48 Gerd Möllmann
  2024-03-06  8:41 ` Po Lu
  2024-03-06 12:14 ` Eli Zaretskii
  0 siblings, 2 replies; 6+ messages in thread
From: Gerd Möllmann @ 2024-03-06  6:48 UTC (permalink / raw)
  To: emacs-devel

Symbols are currently encoded as words with tag = 0 (= Lisp_Symbol
enumerator), that when untagged are an offset from lispsym (the array of
built-in symbols), not a pointer to some structure like it is done for
other Lisp types. That makes the word 0x0 = Qnil, 0x1 = Qt, and so on.

My question comes from playing with another GC library, where this
unique encoding is, well, quite inconvenient. So, I'd like to ask two
questions:

- Does someone remember the reasons why this has been done?

- Is there something that relies on this? Maybe something that
  relies on 0x0 being a valid Lisp_Object?

Thanks!



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Question regarding Lisp_Object representation of symbols
  2024-03-06  6:48 Question regarding Lisp_Object representation of symbols Gerd Möllmann
@ 2024-03-06  8:41 ` Po Lu
  2024-03-06  8:56   ` Gerd Möllmann
  2024-03-06 12:14 ` Eli Zaretskii
  1 sibling, 1 reply; 6+ messages in thread
From: Po Lu @ 2024-03-06  8:41 UTC (permalink / raw)
  To: Gerd Möllmann; +Cc: emacs-devel

Gerd Möllmann <gerd.moellmann@gmail.com> writes:

> - Does someone remember the reasons why this has been done?

To speed up comparisons between objects and Qnil, I think.

> - Is there something that relies on this? Maybe something that
>   relies on 0x0 being a valid Lisp_Object?

Yes, in the many places where memset/memclear is invoked to initialize
Lisp_Object fields or variables, for instance.  It's supposed to be the
case that these instances are marked with NIL_IS_ZERO for easy locating
if the representation of Qnil is ever to be changed, but that convention
is not observed in practice, or is actively circumvented, as by callers
of memclear, which defeat the purpose of that marker by calling this one
of its bearers to initialize a variety of structures that may or may not
comprise only Lisp_Objects, greatly inflating the number of callers that
must be examined before such a change in object representation.



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Question regarding Lisp_Object representation of symbols
  2024-03-06  8:41 ` Po Lu
@ 2024-03-06  8:56   ` Gerd Möllmann
  0 siblings, 0 replies; 6+ messages in thread
From: Gerd Möllmann @ 2024-03-06  8:56 UTC (permalink / raw)
  To: Po Lu; +Cc: emacs-devel

Po Lu <luangruo@yahoo.com> writes:

> Gerd Möllmann <gerd.moellmann@gmail.com> writes:
>
>> - Does someone remember the reasons why this has been done?
>
> To speed up comparisons between objects and Qnil, I think.
>
>> - Is there something that relies on this? Maybe something that
>>   relies on 0x0 being a valid Lisp_Object?
>
> Yes, in the many places where memset/memclear is invoked to initialize
> Lisp_Object fields or variables, for instance.  It's supposed to be the
> case that these instances are marked with NIL_IS_ZERO for easy locating
> if the representation of Qnil is ever to be changed, but that convention
> is not observed in practice, or is actively circumvented, as by callers
> of memclear, which defeat the purpose of that marker by calling this one
> of its bearers to initialize a variety of structures that may or may not
> comprise only Lisp_Objects, greatly inflating the number of callers that
> must be examined before such a change in object representation.

Thank you very much, that was really helpful!



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Question regarding Lisp_Object representation of symbols
  2024-03-06  6:48 Question regarding Lisp_Object representation of symbols Gerd Möllmann
  2024-03-06  8:41 ` Po Lu
@ 2024-03-06 12:14 ` Eli Zaretskii
  2024-03-06 20:32   ` Paul Eggert
  1 sibling, 1 reply; 6+ messages in thread
From: Eli Zaretskii @ 2024-03-06 12:14 UTC (permalink / raw)
  To: Gerd Möllmann, Paul Eggert; +Cc: emacs-devel

> From: Gerd Möllmann <gerd.moellmann@gmail.com>
> Date: Wed, 06 Mar 2024 07:48:31 +0100
> 
> Symbols are currently encoded as words with tag = 0 (= Lisp_Symbol
> enumerator), that when untagged are an offset from lispsym (the array of
> built-in symbols), not a pointer to some structure like it is done for
> other Lisp types. That makes the word 0x0 = Qnil, 0x1 = Qt, and so on.
> 
> My question comes from playing with another GC library, where this
> unique encoding is, well, quite inconvenient. So, I'd like to ask two
> questions:
> 
> - Does someone remember the reasons why this has been done?
> 
> - Is there something that relies on this? Maybe something that
>   relies on 0x0 being a valid Lisp_Object?

Paul, can you help us answer these questions?



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Question regarding Lisp_Object representation of symbols
  2024-03-06 12:14 ` Eli Zaretskii
@ 2024-03-06 20:32   ` Paul Eggert
  2024-03-07  4:28     ` Gerd Möllmann
  0 siblings, 1 reply; 6+ messages in thread
From: Paul Eggert @ 2024-03-06 20:32 UTC (permalink / raw)
  To: Eli Zaretskii, Gerd Möllmann; +Cc: emacs-devel

On 2024-03-06 04:14, Eli Zaretskii wrote:
>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>
>> - Does someone remember the reasons why this has been done?

Speed. It's significantly more efficient.


>> - Is there something that relies on this? Maybe something that
>>    relies on 0x0 being a valid Lisp_Object?

Yes, these assumptions are present in other places. I tried to mark all 
these places with "verify (NIL_IS_ZERO)" a decade ago, though I wouldn't 
be surprised if I missed one or two at the time, or if other 
dependencies have crept in since then (notably in src/comp.c, which I 
haven't audited for this).



^ permalink raw reply	[flat|nested] 6+ messages in thread

* Re: Question regarding Lisp_Object representation of symbols
  2024-03-06 20:32   ` Paul Eggert
@ 2024-03-07  4:28     ` Gerd Möllmann
  0 siblings, 0 replies; 6+ messages in thread
From: Gerd Möllmann @ 2024-03-07  4:28 UTC (permalink / raw)
  To: Paul Eggert; +Cc: Eli Zaretskii, emacs-devel

Paul Eggert <eggert@cs.ucla.edu> writes:

> On 2024-03-06 04:14, Eli Zaretskii wrote:
>>> From: Gerd Möllmann <gerd.moellmann@gmail.com>
>>>
>>> - Does someone remember the reasons why this has been done?
>
> Speed. It's significantly more efficient.
>
>>> - Is there something that relies on this? Maybe something that
>>>    relies on 0x0 being a valid Lisp_Object?
>
> Yes, these assumptions are present in other places. I tried to mark
> all these places with "verify (NIL_IS_ZERO)" a decade ago, though I
> wouldn't be surprised if I missed one or two at the time, or if other
> dependencies have crept in since then (notably in src/comp.c, which I
> haven't audited for this).

Thanks, Paul. I've also looked around a bit yesterday, and my impression
in the end was that making !NIL_IS_ZERO fly could easily be more work
than trying to somehow marry it with the library I'm evaluating.



^ permalink raw reply	[flat|nested] 6+ messages in thread

end of thread, other threads:[~2024-03-07  4:28 UTC | newest]

Thread overview: 6+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2024-03-06  6:48 Question regarding Lisp_Object representation of symbols Gerd Möllmann
2024-03-06  8:41 ` Po Lu
2024-03-06  8:56   ` Gerd Möllmann
2024-03-06 12:14 ` Eli Zaretskii
2024-03-06 20:32   ` Paul Eggert
2024-03-07  4:28     ` Gerd Möllmann

Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).