CoreWin Bug?

pauldkline.TakeThisOut@aol.com <pauldkline.TakeThisOut@aol.com> kirjoitti 27.01.2008:
> I've been pushing CoreWin to the limit and found what I think is a
> bug. If you step this program:
>
> qA equ 2001
> qB equ 2002
> qC equ 2003
> tA dat 0 ,(qA*qB*qC)
> begin mov.a #qB ,tA
> mul.a #qA ,tA
> mul.a #qC ,tA
> sne.ab tA ,tA
> jmp #0
> end begin
>
> you will see that tA.a <> tA.b

So which one is wrong? In a 8000-instruction core, the result
*should* be 6006 (or -1994).

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
 >> Stay informed about: CoreWin Bug? 

David M provided the solution to force mod8000:

> > tA dat 0 ,(((qA*qB)%CORESIZE)*qC)

P. Kline
 >> Stay informed about: CoreWin Bug? 

pauldkline DeleteThis @aol.com <pauldkline DeleteThis @aol.com> kirjoitti 01.02.2008:
> David M provided the solution to force mod8000:
>
>> > tA dat 0 ,(((qA*qB)%CORESIZE)*qC)

Ah, yes, of course: 32-bit integer overflow. I suspect pMARS has the
same bug. Indeed, it's not really fixable entirely without switching
to unlimited-precision integer arithmetic (a.k.a. bignums), since we
*do* want expressions such as CORESIZE/2 to produce the expected
(i.e. non-zero) result, which precludes doing the math entirely modulo
CORESIZE.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
 >> Stay informed about: CoreWin Bug? 

pMARS has the same problem.

Multiplication could be calculated modulo the highest multiple of
CORESIZE below sqrt(maxint).

Addition and subtraction could be done modulo the highest multiple of
CORESIZE below maxint/2.

This should fix overflow and expressions like CORESIZE/2 or even
(3*CORESIZE)/7 will still work.

Regards,

John

On Feb 3, 11:02 pm, Ilmari Karonen <usen....RemoveThis@vyznev.invalid> wrote:
> pauldkl....RemoveThis@aol.com <pauldkl....RemoveThis@aol.com> kirjoitti 01.02.2008:
>
> > David M provided the solution to force mod8000:
>
> >> > tA dat 0 ,(((qA*qB)%CORESIZE)*qC)
>
> Ah, yes, of course: 32-bit integer overflow. I suspect pMARS has the
> same bug. Indeed, it's not really fixable entirely without switching
> to unlimited-precision integer arithmetic (a.k.a. bignums), since we
> *do* want expressions such as CORESIZE/2 to produce the expected
> (i.e. non-zero) result, which precludes doing the math entirely modulo
> CORESIZE.
>
> --
> Ilmari Karonen
> To reply by e-mail, please replace ".invalid" with ".net" in address.
 >> Stay informed about: CoreWin Bug? 

On Feb 4, 11:09 am, digital.wildern... RemoveThis @googlemail.com wrote:
>
> Multiplication could be calculated modulo the highest multiple of
> CORESIZE below sqrt(maxint).
>
> Addition and subtraction could be done modulo the highest multiple of
> CORESIZE below maxint/2.
>
> This should fix overflow and expressions like CORESIZE/2 or even
> (3*CORESIZE)/7 will still work.

Thanks, John! I had been ignoring the 32-bit overflow problem as being
too difficult to fix, but your proposal is a fairly easy workaround.
I'll build that into the next CoreWin release.

My apologies to all for any bounced emails you may have gotten; I've
recently changed both my job and my home ISP. You can get my new email
address from my profile.

Regards,

- Chip
 >> Stay informed about: CoreWin Bug? 

digital.wilderness.RemoveThis@googlemail.com <digital.wilderness.RemoveThis@googlemail.com> kirjoitti 04.02.2008:
>
> Multiplication could be calculated modulo the highest multiple of
> CORESIZE below sqrt(maxint).
>
> Addition and subtraction could be done modulo the highest multiple of
> CORESIZE below maxint/2.
>
> This should fix overflow and expressions like CORESIZE/2 or even
> (3*CORESIZE)/7 will still work.

Note that, on a 32-bit system with signed integers, sqrt(MAXINT) is
only (slightly less than) 46341. (With unsigned integers it's of
course just under 65536.) The largest multiple of 8000 which is less
than 46341 is only 5*8000 = 40000. For larger coresizes the margin
gets even narrower.

Of course, the larger the coresize is, the more likely one is to bump
into integer size limits in the compiler anyway. Having thought about
this a bit more, I actually feel that doing all math with bignums in
the compiler might be the best solution. Or, if not that, at least
switch to 64-bit integers to get a bit more headroom.

--
Ilmari Karonen
To reply by e-mail, please replace ".invalid" with ".net" in address.
 >> Stay informed about: CoreWin Bug?