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 16:03:09 +0200
> 
> >> Isn't that also changing the size of a Lisp cell?  And of integer
> >> arithmetic?
> >
> > Part of it, yes.  But since a Lisp cell can hold buffer or string
> > position, what else can you expect?
> 
> That buffer or string positions not representable in the 29 bits or so
> available for integers in a Lisp cell are instead represented using a
> gpm number for which there is a reference in the Lisp cell.

But a GPM number is nothing more or less that some C data type.  It's
not some magic wand that can solve problems just by being there.

> You are apparently unable to deal with the concept of a Lisp type being
> represented by fewer bits than the integral type used in C for things
> like buffer/string positions outside of the 29-bit integer range.

Let's agree to keep such comments out of this discussion, OK?
Otherwise, I will simply end it.

> How do you think Emacs managed 64-bit doubles "inside" of a 32-bit
> integral type used for representing Lisp cells?

So you are suggesting to make a Lisp integer represented like a Lisp
float, i.e. accessible via a pointer?  But that in itself will slow
down integer arithmetics, due to the need to dereference the pointer,
won't it?

> GMP needs to be called only when leaving the range of "small integers"
> (which is all we even have right now).  64-bit arithmetic in your plan
> would be required for every single operation.  Yes, when GMP kicks in,
> it will be slower than operations using exactly 64-bit (not more, not
> less).  But it's the exception rather than the rule.

But there has to be a test for when the exception happens, and that
test is going to exert its price on every operation, whether it
succeeds or fails the test.  I'm not at all sure it will be a net win.

> So much the
> exception that we could entirely make do without it so far.  It _will_
> occur frequently when editing files larger than 1GB or so.  But only in
> the _Lisp_ representations of those buffer positions.  Everything
> implemented in C will use the integral data type we choose for that,
> throwing an error when it gets exceeded.

So you are suggesting to give up the transparent exposure of members
of Lisp objects that are integers?

> Yes, not all of the possible offsets will be representable in one
> Lisp cell.

So you are suggesting that a buffer position will not always be a
simple number, but will sometimes be a cons cell?