Subject: overflow....

From: "Marc H" <[email-masked]>
Date: Sun, 10 Oct 2010 13:57:20 -0000

Would someone verify these statement for me please....

1) if I add 30000 to 30000 the overflow bit is set ?
2) if I add 20000 to 30000 the overflow bit is NOT set ?

3) if I subtract 100 from 50 the overflow bit is set ?
4) if I subtract 50 from 100 the overflow bit is not set ?

---

From: "fredkaal" <[email-masked]>
Date: Mon, 11 Oct 2010 17:05:27 -0000

1) 30000 + 30000 = 60000
or >7530 + >7530 = >EA60

It depends what meaning you give to this numbers: 
unsigned: >EA60 is correct, ignore the overflow bit. It is you, the programmer, to deside.
signed: result is suddenly negative as the overflow bit tells you so.

2) Are you sure? or do you mean 2000 + 30000 = 32000 is < 32767 is still positive  thus correct.

3) Change in sign, correct.

4) Correct.

Fred ;-)

---

From: Marc Hull <[email-masked]>
Date: Mon, 11 Oct 2010 11:08:10 -0700 (PDT)

Thanks for the answer.  I was hoping the overflow wasn't tied to the sign but rather would only be set on a logical over/under flow.  No such luck ;-)

--- On Mon, 10/11/10, fredkaal <[email-masked]> wrote:

From: fredkaal <[email-masked]>
Subject: [TI994A] Re: overflow....
To: [email-masked]
Date: Monday, October 11, 2010, 12:05 PM

  

      1) 30000 + 30000 = 60000

or >7530 + >7530 = >EA60

4) Correct.

Fred ;-)

--- In [email-masked], "Marc H" <marc.hull@...> wrote:

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 11 Oct 2010 18:17:33 -0000

Hello Marc,

just wrote an assembly language program. Tested on MESS, and hex-outputting the status value, I get

> 1) if I add 30000 to 30000 the overflow bit is set ?

8C00 = 1000 1100 0000 0000

> 2) if I add 20000 to 30000 the overflow bit is NOT set ?

8800 = 1000 1000 0000 0000
 
> 3) if I subtract 100 from 50 the overflow bit is set ?

8000 = 1000 0000 0000 0000

> 4) if I subtract 50 from 100 the overflow bit is not set ?

D000 = 1101 0000 0000 0000

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 11 Oct 2010 18:30:19 -0000

Correction, forgot to clear the status register first.

> > 1) if I add 30000 to 30000 the overflow bit is set ?
8800 = 1000 1100 0000 0000

Michael

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 11 Oct 2010 18:41:56 -0000

Once more ... bits were not correct.

> > > 1) if I add 30000 to 30000 the overflow bit is set ?

Actually, I would not have expected them to show a difference. If, however, you wanted to write 2000 + 30000, you'd get

C000 = 1100 0000 0000 0000

Carry always has to do with passing 0. Overflow is a matter of passing 8000. 

(BTW, just checked my results to verify I used the right order in the operands: EA60, 7D00, FFCE, 0032.)

Michael

---

From: "kabldb" <[email-masked]>
Date: Mon, 11 Oct 2010 20:58:18 -0000

3)
50 - 100 = -50 
still within range, no overflow
range is >8000 thru >7fff (-32768 thru 32767)

--- In [email-masked], "fredkaal" <fgkaal@...> wrote:
> --- In [email-masked], "Marc H" <marc.hull@> wrote:
> >

---

From: mark wills <[email-masked]>
Date: Mon, 11 Oct 2010 23:07:53 +0100 (BST)

Correct. More specifically:

"The overflow bit is set when the result of an arithmetic operation is too large 
or too 

small to be represented correctly in two's complement representation."

Since -50 can be adequately represented in 2'sC, the OV bit remains off.

Confusing as hell, isn't it!?

----- Original Message ----
> From: kabldb <[email-masked]>
> Sent: Mon, 11 October, 2010 21:58:18

---

From: "Michael Zapf" <[email-masked]>
Date: Mon, 11 Oct 2010 23:09:27 -0000

> Confusing as hell, isn't it!?

No, it's reasonable. :-)

You have to look at it in another way. When you add two positive numbers, you would not expect it to become negative. Similarly, subtracting from a negative number should not become positive. This is an exceptional condition which happens when you cross the 0x8000 border. For unsigned (logical) numbers it's ok, but not for signed numbers. 

The carry bit is more confusing. Check the outputs that I posted some hours ago. When you calculate 100-50, you get a carry of 1. When you have 50-100, carry is 0. This seems to be explainable if you assume that the first operand gets an implicit + 0x10000 (so it has a carry of 1) which will be cleared when you get below 0.

Michael