Overflow confusion

[andrew]

I am trying to really nail down how overflow works. If you add 2 signed numbers and the result should be >127 or <-128 this will cause an overflow (kinda like carry for an unsigned number more than 256).

I have been reading this: http://www.righto.com/2012/12/the-6502- ... ained.html In it, there is an example where -48+-112=96.
So, we have 10010000 + 11010000 = 01100000 = 96, something is carried from 7th to 8th bit so C is set. The bit carried into 7 is different from whats carried out, so V is set.

Then, there is an example where 80 + 80 =-96.
So, we have 01010000 + 01010000 = 10100000 = 96, nothing is carried from 7th to 8th bit so C is not set. The bit carried into 7 is different from whats carried out, so V is set.

My question is how do we go from these wrong answers to the correct ones? For example one if we put the overflow bit in front ( like 1 01100000 ) we get the correct answer: -160. If we do that for the 2nd example ( 1 10100000 ) it is still incorrect. Can anyone please help?

Thanks

EDIT: got my carry flags mixed up

[Dr Jefyll]

Without specifically answering your question, allow me to direct you to the following excellent tutorials by 6502.org's own Bruce Clark.

The Overflow (V) Flag Explained

Beyond 8-bit Unsigned Comparisons


-- Jeff

[ttlworks]

Also, see here.

Cheers,
Dieter.

[GARTHWILSON]

Let me recommend again WDC's excellent 65xx programming manual, "Programming the 65816-Including the 6502, 65C02 and 65802" which no 65xx enthusiast should be without. The overflow-flag rule is spelled out clearly on p.173 of my paper version (which I think is the same as what they're selling online now). Written by David Eyes and Ron Lichty. This is definitely the best 65xx programming manual available, and a must-have for every 65xx programmer! It starts with the basics, followed by architecture, the CMOS 65c02's many improvements over the original NMOS 6502 including added instructions and addressing modes and fixing the NMOS's bugs and quirks, and then the natural progression to the 65816; a thorough tutorial, writing applications, then very detailed and diagrammed information on all 34 addressing modes, at least a page of very detailed description for each instruction, with info on every addressing mode available for that instruction, then instruction lists, tables, and groups, of all 255 active op codes, plus more. 469 pages. (.pdf) Note: There were many problems with the earlier .pdf version that were not in the original paper manual; but in late March 2015, WDC scanned and OCR'ed the paper manual and posted the new, repaired .pdf.

[andrew]

Dr Jefyll wrote:

Without specifically answering your question, allow me to direct you to the following excellent tutorials by 6502.org's own Bruce Clark.

The Overflow (V) Flag Explained

Beyond 8-bit Unsigned Comparisons


-- Jeff

Thanks for the response!
I've been reading through these just now and I am still quite confused sadly. I think I understand that it's telling you how the result is outside of -127 and 127, it's just how you can do something practical with that information I am unsure of. It seems that If I did a calculation that set V=1, is it simply trying to tell me to go back and redo it with a 16-bit number instead? There isn't a way to recover the 'real' answer?

[BigEd]

It's an interesting question -although an odd one, because you end up with a signed 9 bit number, not something you'd usually see.

I think I'd try to answer it by drawing up a table - there are only so many ways that two 8 bit numbers can combine with overflow set.

I would very much recommend working in hex though - using binary and decimal adds to the mental burden, I think.

[andrew]

BigEd wrote:

It's an interesting question -although an odd one

I think maybe I've got myself confused over something that maybe doesn't matter to much then haha I have been thinking of the Overflow flag as a way to "fix" the error - is that maybe not the best way to think of it? Is it just rather a way to tell you there has been an overflow, and it is not offering any particular solution? It's then up to you to decide what to do

BigEd wrote:

I would very much recommend working in hex though - using binary and decimal adds to the mental burden, I think.

Can you maybe expand on this a little? Do you mean it reduces the burden just because its a more human-readable format, or because we are using them as unsigned numbers, and therefore we cannot overflow?

Thanks!

[GARTHWILSON]

andrew wrote:

It's then up to you to decide what to do

Right. It's just telling you the high bit is not correctly telling you what the sign is. What you do about it is up to you.

Quote:

BigEd wrote:

I would very much recommend working in hex though - using binary and decimal adds to the mental burden, I think.

Can you maybe expand on this a little? Do you mean it reduces the burden just because its a more human-readable format, or because we are using them as unsigned numbers, and therefore we cannot overflow?

Decimal does not line up neatly with where the over/underflow happens (and certainly does not easily let on what bits are on, something that is particularly important in address decoding). When programming at the lowest levels (assembly language), it seems to usually be best to use hex and let the computer work that way, and only have it convert to and from decimal when necessary for human end-user I/O.

[barrym95838]

I haven't tested my idea thoroughly, but what the heck, I'll share it anyway and let you guys shoot holes in it if it turns out to not be bullet-proof. When the V flag sets as the result of a signed add or subtract, this is an indication that the twos complement result cannot fit properly in the 8-bit accumulator. However, the correct result will always still fit properly in nine bits, and this 9-bit twos complement result can be utilized by simply appending the C flag to the high end of the accumulator as the "ninth bit".

[BigEd]

I think that idea ought to be tested, Mike! The difficulty in my mind is that you didn't start with two signed 9 bit numbers, so bit 7 (the eighth bit) carries a different meaning. It still might be that you're right.

For test cases I'd suggest numbers like $00, $01, $02, $7E, $7F, $80, $81, $FE, $FF. And I'd look separately at addition and subtraction. ($80 is a difficult case because it can't be negated.)

But indeed Andrew, using hex one can readily see what's happening with bits 6 and 7, and whether the numbers are large or small. Well, with a bit of practice, but it's worth getting to that stage.

I think, in most cases, if you have signed 8 bit numbers and you see unexpected overflow, you have an exception, so your calculation should fail and you should revisit your program. Perhaps sometimes you could detect overflow and produce a saturated result - but I expect you'd need to check the signs of your inputs to figure out what that result should be. And, again, treat addition and subtraction separately.

[DerTrueForce]

Signed overflow occurs when the sign bits of the addend and augend are the same, but the sign bit of the result is different. This is what the V status bit indicates.

I took a very quick look at it, and it looks like it does come out as a 9-bit signed number if an 8-bit operation overflows, but I only looked at one test case:

Code: Select all

-112 - 30 = -112 + -30

-112 = 1001 0000
 -30 = 1110 0010 +
      -----------
     1 0111 0010 = -142 (9-bit 2s-complement) <- correct
   C=1
   A = 0111 0010 = +114 (8-bit 2s-complement) <- incorrect
   N = 0
   V = 1

This seems to indicate that it does come out as a 9-bit signed number if it overflows the 8 bits of the accumulator(which would make the term "overflow" very appropriate).
But even if this holds for all overflows, I don't think that treating it as a valid signed number is all that useful in practice. It would require a whole extra byte to store, which is rather wasteful, and you'd have to handle that extra byte, so at that point, it's probably easier just to use 16-bit 2s-complement.

[BigEd]

I'll admit I'm intrigued by the question, and it would be nice if Mike's simple suggestion is the whole truth.

But I do agree that the ninth bit would seem to be of limited use. Perhaps it makes it much easier to implement saturating arithmetic?

[DerTrueForce]

I just looked up saturating arithmetic(Wikipedia page for if anyone else hasn't heard the term before). Seems like it could be very useful in some situations.
Almost trivial to implement, too. V indicates whether you clamp the value or not, and C tells you whether you clamp it to the positive or negative limit.
Assuming it holds, of course...

[barrym95838]

BigEd wrote:

I'll admit I'm intrigued by the question, and it would be nice if Mike's simple suggestion is the whole truth.

But I do agree that the ninth bit would seem to be of limited use. Perhaps it makes it much easier to implement saturating arithmetic?

Hey, even a blind old dog might sniff out a bone once in a while. If true, it should allow an easy run-time "promotion" from 9-bit to 16-bit as well (no time for a code example ... gotta get to work).

[ttlworks]

DerTrueForce wrote:

Seems like it could be very useful in some situations.

For instance, when implementing a PID controller with your computer, and you are adding the partial sums with, let's say, 32 Bit fixed point math:
before writing the result into a 16 Bit D\A converter with a +10V\-10V output range, you need to limit/clip the result to +32767 (+10V) and -32768 (-10V).

Else, if your 32 Bit result would be, for instance, +32768 (+10.0003V), that's hexadecimal $00008000.
For the 16 Bit D\A converter, it would be just $8000, that's -32768 decimal, so it would give out -10V (a big negative voltage instead of a big positive voltage),
and your servo loop would have a tendency to sometimes go "off track" for no appearent reason.