With Win32forth this worked fine...returning the same result for both
inputs.
I took a quick look at the code and it does a /MOD NIP. /MOD makes a call
to IDIV, but I didn't look in to it any further.

----- Original Message -----
From: "SF Talk" <sftalk_at_forth.com>
To: "SF Talk" <sftalk_at_forth.com>
Sent: Monday, May 08, 2000 11:06 AM
Subject: Re: [sftalk] Binary question

Date: Mon, 08 May 2000 08:53:36 -0700
From: "Rick VanNorman" <rvn_at_forth.com>
Subject: Re: [sftalk] Binary question

>From: "Michael Kemper" <mikek_at_metretek.com>
>
>Rick,
>I was coding a crc algorithm and ran across this peculiarity. It may be
>normal operation, but seems inconsistant to me:
>
>If I do the following
>$CEE1289A $100 / h.
>>$FFCEE129
>
>but if I perform the following:
>$CEE1289A 2/ 2/ 2/ 2/ 2/ 2/ 2/ 2/ h.
>>$FFCEE128
>which is what I'd expect from both versions. Both versions bring the sign
>bit into the result, but the first rounds the result, which I wouldn't
>expect from the standard "/" word. Is this normal?

Mike,

My expectations are the same as yours, and I was very surprised to find
the results you cite. Here is the quote straight from Intel's pentium
instruction reference for the IDIV instruction:

<quote>

Non-integral results are truncated (chopped) towards 0. The sign of
the remainder is always the same as the sign of the dividend.
The absolute value of the remainder is always less than the
absolute value of the divisor. Overflow is indicated with
the #DE (divide error) exception rather than with the OF (overflow) flag.

</quote>

I use the IDIV instruction in / so it will (should) behave like this.
Consider if the "truncated (chopped) towards 0" is implemented in
hardware without consideration for the sign bit. This would produce
the exact result we are seeing.

I don't know what the correct answer is. Can anyone run this on
another 32-bit Forth and report the results?

Thanks,

Rick

.
Received on Mon May 08 2000 - 08:53:36 PDT