Re: Making --with-wide-int the default

[Eli Zaretskii]

> From: David Kastrup <address@hidden>
> Cc: address@hidden,  address@hidden,  address@hidden
> Date: Fri, 16 Oct 2015 11:18:31 +0200
> 
> Eli Zaretskii <address@hidden> writes:
> 
> >> From: David Kastrup <address@hidden>
> >> Cc: Eli Zaretskii <address@hidden>, Juanma Barranquero
> >> <address@hidden>, address@hidden
> >> Date: Fri, 16 Oct 2015 10:18:26 +0200
> >> 
> >> Instead of going to 64-bit unilaterally it would seem to make more sense
> >> to me to degrade gracefully into gmp.
> >
> > How can GMP help extend the maximum size of buffers and strings beyond
> > what a 32-bit EMACS_INT allows?
> 
> By choosing an appropriate data type for representing buffer/string
> sizes in C and converting back-and-forth from the Lisp type as needed.
> Pretty much the same way we do it now.

Sorry, I don't foollow: what "appropriate data type"?  Would that be
'long long'?  If so, that's exactly what we do now, which you say is
"going to 64-bit unilaterally".  What am I missing?

> I think it would be a reasonable restriction to keep to 2GB size of
> strings and buffers when working with a 32bit executable.  That's
> what people expect on a 32-bit architecture.

That's what we have now in 32-bit builds --with-wide-int.  So I'm not
sure why you mention that as some kind of change related to this
discussion.

> > And how can GMP be faster than (or even close to) the native 64-bit
> > integral types supported by the C compiler?
> 
> GMP will not get to see the vast majority of numbers passing through
> Emacs, and on a 32-bit system 32-bit integral types will be faster than
> 64-bit integral types.
> 
> When you are editing gigabyte files, at some point of time, the Lisp
> representation of the respective offsets in the high part of the buffer
> will become the responsibility of GMP, yes.  I'm not worried about that.

I don't understand.  C doesn't have dynamic types.  If the variable
that holds buffer positions needs to support 61-bit offsets, it will
have to be a 64-bit integral data type from the get-go.

And having 61-bit integers for integer arithmetics is also a valuable
feature.  So the EMACS_INT type will have to be able to support that.