On Wed, Dec 27, 2000 at 01:00:14PM -0500, Dan Sugalski wrote:
> At 09:07 AM 12/27/00 -0800, Benjamin Stuhl wrote:
> >--- Dan Sugalski <[EMAIL PROTECTED]> wrote:
> > > Why? For variables, math is math--2+2=4 regardless of
> > > whether you're one or
> > > two's complement, or BCD-encoded, or use the EBCDIC
> > > signed characters,
> > > or... Mandating representations seems rather too
> > > low-level to me, though if
> > > you've got a good argument I'm OK with it.
> >
> >Mostly because it seems to be a requirement for intelligent
> >integer-preserving maths (cf. PERL_PRESERVE_IVUV in perl5).
>
> Fair enough, though I'm not convinced it's enough to mandate it. I'm not
It seems it's a requirement for fast intelligent integer-preserving maths.
(in that Jarkko's implementation didn't assume it and used 1 subtraction,
1 add and 2 comparisons for (overflow test & add) whereas mine did, and used
only 1 add and 2 comparisons. And mine seems to be fractionally faster than
the old floating point only code, whereas Jarkko's was slower. But it's
almost certainly not quite that simple, as I also found that I needed to
make nearly all the operations integer aware before I clawed back the
slowdown)
It's not a requirement for integer-preserving maths.
> sure if there are any non-two's complement machines out there anymore,
However, as perl5 has a few 2s complement assumptions already polluting the
source, unless we can find a 1s complement (or other) machine to test on, it
seems sensible (to me at least) to say that the initial implementation will
assume 2s complement as we have nothing to test that we've got all the 2s
complement assumptions out or the conditionally compiled non 2s complement
code correct.
> >My question here is whether each supported platform is
> >going to need to provide its own overflow
> >detection/autoconversion decision routines, since the
> >portable part of perl6 will have now idea how far it can go
> >with native numbers.
>
> Yes, they will. Each chip family, at least. I'm thinking we'll have a
> generic CHECK_OVERFLOW macro that's redefined on a per-CPU basis and
> handled by whoever's doing the port for that system, with some generic
Were you (both) meaning integer, floating point, or both sorts of overflow
detection here?
Nicholas Clark
