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

[David Kastrup]

Eli Zaretskii <address@hidden> writes:

>> 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?

A change in the size of the Lisp data type.

>> 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.

Isn't that also changing the size of a Lisp cell?  And of integer
arithmetic?

>> 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.

But Lisp does.

> 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.

I repeat: we are talking about a 32-bit binary where restricting buffer
and string size to 32bit offsets would be reasonable and expected.  But
even if we assume that we want to support some larger size in the C
parts, that's just the matter of choosing a different type and a
different conversion from Lisp to C.

GUILE has all of

 -- C Function: char scm_to_char (SCM x)
 -- C Function: signed char scm_to_schar (SCM x)
 -- C Function: unsigned char scm_to_uchar (SCM x)
 -- C Function: short scm_to_short (SCM x)
 -- C Function: unsigned short scm_to_ushort (SCM x)
 -- C Function: int scm_to_int (SCM x)
 -- C Function: unsigned int scm_to_uint (SCM x)
 -- C Function: long scm_to_long (SCM x)
 -- C Function: unsigned long scm_to_ulong (SCM x)
 -- C Function: long long scm_to_long_long (SCM x)
 -- C Function: unsigned long long scm_to_ulong_long (SCM x)
 -- C Function: size_t scm_to_size_t (SCM x)
 -- C Function: ssize_t scm_to_ssize_t (SCM x)
 -- C Function: scm_t_ptrdiff scm_to_ptrdiff_t (SCM x)
 -- C Function: scm_t_int8 scm_to_int8 (SCM x)
 -- C Function: scm_t_uint8 scm_to_uint8 (SCM x)
 -- C Function: scm_t_int16 scm_to_int16 (SCM x)
 -- C Function: scm_t_uint16 scm_to_uint16 (SCM x)
 -- C Function: scm_t_int32 scm_to_int32 (SCM x)
 -- C Function: scm_t_uint32 scm_to_uint32 (SCM x)
 -- C Function: scm_t_int64 scm_to_int64 (SCM x)
 -- C Function: scm_t_uint64 scm_to_uint64 (SCM x)
 -- C Function: scm_t_intmax scm_to_intmax (SCM x)
 -- C Function: scm_t_uintmax scm_to_uintmax (SCM x)
     When X represents an exact integer that fits into the indicated C
     type, return that integer.  Else signal an error, either a
     ‘wrong-type’ error when X is not an exact integer, or an
     ‘out-of-range’ error when it doesn’t fit the given range.

     The functions ‘scm_to_long_long’, ‘scm_to_ulong_long’,
     ‘scm_to_int64’, and ‘scm_to_uint64’ are only available when the
     corresponding types are.

Choose a C type of your choosing for dealing with buffer offsets, create
aliases for its conversions, and you are good to go.  The Lisp side
supports arbitrary sizes, and the actual C-side limits (rather than
something like 26 bits or 29 bits or 30 bits or 61 bits) are established
when converting from Lisp types.

> And having 61-bit integers for integer arithmetics is also a valuable
> feature.

61-bit is some arbitrary junk number.  Transparently degrading from
29-bits to gmp numbers means that there are no arbitrary limits (or at
least you are unlikely to hit them) and the performance for the vast
majority of cases will be 29-bit performance.

> So the EMACS_INT type will have to be able to support that.

I don't see why when one can use GMP (which effectively uses the same
kind arithmetic for 61-bit numbers as C does but does not stop there).

-- 
David Kastrup