Should wide-int be registered in features?

Should wide-int be registered in features?

[Rocky Bernstein]

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

.. or in system-configuration. And/or shown in emacs-version?

Recently I was reading the thread "Floating-point constant folding in Emacs
byte compiler", and it looks like, as of now, most (or all) of the issues
raised have been resolved in the byte-code optimizer.

Although I'm happy that things are fixed now, there a part of me that asks:
what might have help detection and prevention of such a problem?

I think there should be a simple program to do some sanity checking of
bytecode *before* it gets run to warn of potential problems or worse does
partial execution work and then crashes.

I've mentioned this in the past, but I now realize that I can write such a
lint checker in Elisp Lisp as a side package.

But there are a couple additional features that might be helpful, both in
such a bytecode lint program and independent of that: whether emacs was
built with --with-wide-int.

My understanding of the floating-point-constant bug is that the behavior is
different between optimizaition on builds that differ using this option.

Other things like x-toolkit, gtk, multi-tty, are listed in features. Should
wide-int be something like this?

[-- Attachment #2: Type: text/html, Size: 2501 bytes --]

Re: Should wide-int be registered in features?

[Stefan Monnier]

> But there are a couple additional features that might be helpful, both in
> such a bytecode lint program and independent of that: whether emacs was
> built with --with-wide-int.

I don't see why that would be relevant: --with-wide-int should give
pretty much the same result as building on a 64bit system.


        Stefan

Re: Should wide-int be registered in features?

[rocky]

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

Stefan Monnier wrote
>> But there are a couple additional features that might be helpful, both
>> in> such a bytecode lint program and independent of that: whether emacs
>> was> built with --with-wide-int.I don't see why that would be relevant:
>> --with-wide-int should givepretty much the same result as building on a
>> 64bit system.        Stefan

"should" is not the same thing as "does". If I have this correct knowing
this and knowing how the bytecode was created would have been helpful. Are
there more bugs of this nature where setting the option has a differening
behavior? Also, I believe there are performance differences and differences
in capabilities. e.g --with-wide-int adds: 
>  buffer and string size up to 2GB on 32-bit hosts, at the cost of 10% to
> 30% slowdown of Lisp

and how inside of Emacs is one supposed to know if this is in effect? 



--
Sent from: http://emacs.1067599.n8.nabble.com/Emacs-Dev-f108916.html

[-- Attachment #2: Type: text/html, Size: 1494 bytes --]

Re: Should wide-int be registered in features?

[Noam Postavsky]

On 5 April 2018 at 18:34, rocky <rocky@gnu.org> wrote:

> and how inside of Emacs is one supposed to know if this is in effect?

You can check `system-configuration-options'.

Re: Should wide-int be registered in features?

[rocky]

Thanks - that answers my question/concern. 



--
Sent from: http://emacs.1067599.n8.nabble.com/Emacs-Dev-f108916.html

Re: Should wide-int be registered in features?

[Stefan Monnier]

> "should" is not the same thing as "does". If I have this correct knowing
> this and knowing how the bytecode was created would have been helpful.

You seem to refer to a known case where you think this would have been
useful, but I don't know what that case is.  AFAIK the recent
discussions were mostly concerned about whether Emacs's integers were
30bit or 62bit, which you can readily test by looking at
most-positive-fixnum or by checking something like (zerop (expt 2 40)).

> Also, I believe there are performance differences and differences
> in capabilities. e.g --with-wide-int adds: 
>>  buffer and string size up to 2GB on 32-bit hosts, at the cost of 10% to
>> 30% slowdown of Lisp
> and how inside of Emacs is one supposed to know if this is in effect? 

Why/when would Elisp need to know?  The same slowdown could occur
because of load on the machine.  Similar object size limits could come
from the OS rather than from the way Emacs was compiled.




        Stefan

Re: Should wide-int be registered in features?

[Andreas Schwab]

On Apr 05 2018, Rocky Bernstein <rb@dustyfeet.com> wrote:

> But there are a couple additional features that might be helpful, both in
> such a bytecode lint program and independent of that: whether emacs was
> built with --with-wide-int.

You have that already: most-positive-fixnum.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

Re: Should wide-int be registered in features?

[Ulrich Mueller]

>>>>> On Thu, 5 Apr 2018, Rocky Bernstein wrote:

> .. or in system-configuration. And/or shown in emacs-version?

It is already registered if it is passed as a configure option:

   system-configuration-options is a variable defined in ‘emacs.c’.
   Its value is
   "[...] --without-wide-int [...]"