Bignums and stuff

[Hrvoje Niksic]

"Stephen J. Turnbull" <stephen at xemacs.org> writes:

>>>>>> "Hrvoje" == Hrvoje Niksic <hniksic at xemacs.org> writes:
>
>     Hrvoje> Actually, it's one of the fastest interpreters around.
>     Hrvoje> Last time I checked, XEmacs was significantly faster than
>     Hrvoje> Python, Perl, librep, FSF Emacs, and the likes.
>
> Well, the issue isn't how fast we can execute no-ops, it's how fast we
> can do useful work.

I still think we're as fast as the others I mentioned.  But, before
Michael criticizes me, I'll note that I intentionally mentioned the
(more or less) *popular* interpreters, not the competently implemented
ones.

So yes, we could be a lot faster.  It doesn't mean that it's OK to
arbitrarily slow down the current code base while waiting for a "Lisp
engine switch" or whatever.

> The question is what functions have to return integers to "support"
> bignums the way the other languages you mention do?

I don't really understand the question.  We already have all the
needed code, Jerry added it.  What I'm talking about is making
--use-bignums mandatory and shipping a bignum implementation (such as
GNU MP) with the source to cater to people who don't have one.

Since we're not making bignums mandatory any time soon, by popular
opinion, the context of the discussion is irrelevant.

> You said add, subtract, multiply, divide, modulus isn't enough.

When did I say that?  I think we're talking about completely and
wildly different things.  The sheer magnitude of the misunderstanding
is astounding.  :-)

>     Hrvoje> You're missing the point.  See my previous post for the
>     Hrvoje> context of this whole discussion.  Since you vetoed
>     Hrvoje> relying on bignums, the context of needing to ship a
>     Hrvoje> bignum implementation is obsolete.
>
> Where did I do that?  I said there's no hurry, but that depends on
> (a) what you mean by relying on bignums, which turns out to be
> basically what I had in mind, and (b) who's volunteering to do the
> work.

"There's no hurry" == veto in the present

That's OK, though.  It was just an idea.

> This is what I had in mind:
>
> static EMACS_INT some_variable;
> Fixnum another;
> DEFVAR_FULLINT ("some-variable", &some_variable ...);
>
> another = some_variable;
>
> Of course the compiler can't catch that at all, no matter what the
> Lisp_Object representation is.

Exactly; this is why I was confused by your reference to union type.
But the nice thing would be that, if DEFVAR_FULLINT turns out to work
well, *all* (or the large majority of) our variables might become
DEFVAR_FULLINT.  Then that problem goes away.