At 10:28 PM 3/8/2001 +0000, Nicholas Clark wrote:
>On Thu, Mar 08, 2001 at 04:28:48PM -0500, Dan Sugalski wrote:
> > At 08:43 PM 3/8/2001 +0000, Nicholas Clark wrote:
>
> > I think most processors that do 32x32 multiply provide a way to get the
> > 64-bit result. Whether *we* can is another matter, of course, but if
> > platform folks want to drop to assembly I'm fine with that.
>
>Yeah. Cool. :-)
>Much code to maintain :-(
As opposed to all the rest? :)
Seriously, I'd like to be able to set things up so that ports for
individual OS/processor combos can wedge in performance enhancements in the
appropriate places. Most of the core it won't matter, but in some spots
(like, say, the extended precision math code...:) it can make a huge
difference.
> > The potential vagaries of platform math is why I was thinking of 31-bit
> > things, because then all you need do is:
> >
> > int overflow = 0x80000000 & (c = a + b)
> >
> > which isn't quite so clever, but still not too bad. :)
>
>
>Do we need to settle on 31 or 32 at this point?
Nope. It can stay a platform-variant with a default implementation, if we
want. Which, thinking about it, probably wouldn't be bad, seeing as I have
access to extended precision math routines in the system libraries on my
VMS boxes.
>Do we need to settle on anything - can it vary by platform so that 64 bit
>platforms can use 64 bit, in which case the 32/31 choice could even be by
>platform (or always 32 if we find it works well)
Well, we'll need an implementation sooner or later...
Dan
--------------------------------------"it's like this"-------------------
Dan Sugalski even samurai
[EMAIL PROTECTED] have teddy bears and even
teddy bears get drunk
