Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Stefan Monnier]

>     Prefer memset to repeatedly assigning Qnil

I don't know if I like this idea very much.  It's nice to make Qnil be
represented by 0, but should we really rely on this all over the place,
making it quasi-impossible to revisit this choice in the future?


        Stefan

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 533 bytes --]

On 01/19/2015 06:33 AM, Stefan Monnier wrote:
>>     Prefer memset to repeatedly assigning Qnil
> 
> I don't know if I like this idea very much.  It's nice to make Qnil be
> represented by 0, but should we really rely on this all over the place,
> making it quasi-impossible to revisit this choice in the future?

If we can't rely on Qnil being 0, what's the point of making Qnil == 0
in the first place? If we can rely on Qnil being 0, we can put Lisp
variables in BSS, use memset, and perform other nice optimizations.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Stefan Monnier]

> If we can't rely on Qnil being 0, what's the point of making Qnil == 0
> in the first place?

Allow the compiler to make some optimizations.

> If we can rely on Qnil being 0, we can put Lisp variables in BSS, use
> memset, and perform other nice optimizations.

Right.  But Lisp_Object representation has changed several times over
the years (tags in MSB, then tags in LSB, unions, structs, ...) and
I wouldn't be surprised if tens years from now it'll be obvious that "we
should drop the Qnil==0 thingy so we can perform <foo> optimization".

It's OK to make a few targeted optimizations based on Qnil==0, but it
should stay sufficiently confined that it we can sufficiently easily
enumerate the places where we make such assumptions and change them.


        Stefan

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Daniel Colascione]

[-- Attachment #1: Type: text/plain, Size: 902 bytes --]

On 01/19/2015 08:37 PM, Stefan Monnier wrote:
> Right.  But Lisp_Object representation has changed several times over
> the years (tags in MSB, then tags in LSB, unions, structs, ...) and
> I wouldn't be surprised if tens years from now it'll be obvious that "we
> should drop the Qnil==0 thingy so we can perform <foo> optimization".
> 
> It's OK to make a few targeted optimizations based on Qnil==0, but it
> should stay sufficiently confined that it we can sufficiently easily
> enumerate the places where we make such assumptions and change them.

The problem with this approach is that we'll have sections of code that
exist only to account for an uncommon configuration. They'll bitrot, and
the code will grow implicit dependencies on Qnil being zero anyway.
It'll be just like GCPRO. I'd rather just declare that Qnil will always
be zero and take full advantage of the change.


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Stefan Monnier]

> The problem with this approach is that we'll have sections of code that
> exist only to account for an uncommon configuration.

We don't need to keep the code for the "Qnil!=0" case, but we should
limit the reliance on "Qnil==0" to a few specific places where rewriting
it differently is fairly easy difficult.  E.g. a few macros in lisp.h
for example.

> They'll bitrot, and the code will grow implicit dependencies on Qnil
> being zero anyway.

That'll happen any way, indeed, by accident.  Just like we had places
which relied on 0==make_number(0), which we've had to find the hard way
(and there might still be some such places we haven't yet noticed).

But if we only consciously rely on Qnil==0 in a few special places, then
we're less likely to introduce such dependencies by accident all over
the place.

> It'll be just like GCPRO. I'd rather just declare that Qnil will always
> be zero and take full advantage of the change.

Regarding GCPRO, I'd be happy to get rid of them, but AFAIK they're
still used on a few platforms.  If we can fix those remaining platforms
we can get rid of GCPRO.


        Stefan

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Paul Eggert]

On 01/20/2015 11:10 AM, Stefan Monnier wrote:
> We don't need to keep the code for the "Qnil!=0" case

In that case I jumped the gun by adding that code.  I just now removed it.

> But if we only consciously rely on Qnil==0 in a few special places

To help identify these I put 'verify (NIL_IS_ZERO)' in each such place I 
know about (there are a half dozen).

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Stefan Monnier]

>> We don't need to keep the code for the "Qnil!=0" case
> In that case I jumped the gun by adding that code.  I just now removed it.
>> But if we only consciously rely on Qnil==0 in a few special places
> To help identify these I put 'verify (NIL_IS_ZERO)' in each such place
> I know about (there are a half dozen).

Can you try and bring most of those cases together in a .h file (presumably
lisp.h)?  I suggest to rename memsetnil to memset_zero_and_nil and to
use it at those places where we set to nil as well as those places where
we set a mix of Lisp_Objects and other fields to zeros and nils.


        Stefan

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Paul Eggert]

Stefan Monnier wrote:
> Can you try and bring most of those cases together in a .h file (presumably
> lisp.h)?  I suggest to rename memsetnil to memset_zero_and_nil and to
> use it at those places where we set to nil as well as those places where
> we set a mix of Lisp_Objects and other fields to zeros and nils.

Sure, I gave that a shot in commit 74244d239e9093035c369721b469529a5fdaf1c6. 
This uses the name 'memclear', though, as 'memset_zero_and_nil' was so long that 
it made indenting a pain.  There are now just two places that directly assume 
Qnil is zero, and both are marked with 'verify (NIL_IS_ZERO)'.

Re: [Emacs-diffs] master b7f83ad: Prefer memset to repeatedly assigning Qnil

[Paul Eggert]

Stefan Monnier wrote:
> should we really rely on this all over the place,
> making it quasi-impossible to revisit this choice in the future?

Yes, this might be a bit drastic now.  Perhaps in the long run we'll be 
comfortable with the assumption, but as we just started assuming it and may want 
to change back, it makes sense to not rely on it quite just yet.  To do that, I 
just now installed commit 347e01447194e511daaeee8835bcb86d2505e642.