Discussion:
Arithmetic functions and signed overflow
(too old to reply)
EECS Instructional Account
2008-07-27 08:45:20 UTC
Permalink
Raw Message
I am slightly confused as to what exactly the addition and subtraction
functions of the ALU are supposed to do, and how they relate to signed and
unsigned overflow.

1. Do the add and subtract functions of the ALU (select 010 and 011) treat
the two 16-bit inputs as sign-magnitude numbers, or as simple binary
numbers (ie. what should be the result output)? For example, if I add
100...001 and 000...001 should I get 000...000 or 100...010 as the result?
Consequently, should we be able to represent negative numbers in the
result or not?

2. What exactly is signed overflow? Is it simply an indicator that goes
high when the resulting number can no longer be represented in 16-bit
sign-magnitude form?

Sorry if these questions are kind of elementary, the homework
specification and the lecture slides didn't exactly talk about this in too
much detail.

Rohit
EECS Instructional Account
2008-07-27 19:01:00 UTC
Permalink
Raw Message
I just realized that everywhere I wrote sign-magnitude, I actually meant
twos complement. The questions still stand.

Rohit
Post by EECS Instructional Account
I am slightly confused as to what exactly the addition and subtraction
functions of the ALU are supposed to do, and how they relate to signed and
unsigned overflow.
1. Do the add and subtract functions of the ALU (select 010 and 011) treat
the two 16-bit inputs as sign-magnitude numbers, or as simple binary numbers
(ie. what should be the result output)? For example, if I add 100...001 and
000...001 should I get 000...000 or 100...010 as the result? Consequently,
should we be able to represent negative numbers in the result or not?
2. What exactly is signed overflow? Is it simply an indicator that goes high
when the resulting number can no longer be represented in 16-bit
sign-magnitude form?
Sorry if these questions are kind of elementary, the homework specification
and the lecture slides didn't exactly talk about this in too much detail.
Rohit
[Instr] Albert Chae
2008-07-27 21:36:36 UTC
Permalink
Raw Message
Post by EECS Instructional Account
1. Do the add and subtract functions of the ALU (select 010 and 011) treat
the two 16-bit inputs as sign-magnitude numbers, or as simple binary numbers
(ie. what should be the result output)? For example, if I add 100...001 and
000...001 should I get 000...000 or 100...010 as the result?
Consequently,
Post by EECS Instructional Account
should we be able to represent negative numbers in the result or not?
I know you corrected yourself to 2's complement, but in your
original question, you used the example of adding -1 (0xFFFF)
and 1 (0x0001) (both in sign and magnitude) and asked whether
you treated the inputs as signed or not. This is indeed
complicated for sign and magnitude, which we thankfully aren't
using. The greatest benefit of using 2's complement instead is
that addition of unsigned numbers or negative numbers is the
same. For example, adding 0xFFFF and 0x0001 gives us 0x0000
(1 bit fell off the upper end).

This is correct whether we treated the original numbers as
unsigned (65 535 + 1 = 0 with overflow)
or as signed (-1 + 1 = 0, no overflow).

Here's another example, 0x8FFF + 0x0001

0b 1000 1111 1111 1111
+ 0b 0000 0000 0000 0001
==========================
0b 1001 0000 0000 0000 = 0x9000

unsigned
0x8FFFF = 38 863
0x00001 = 1
=================
38 864 = 0x9000

signed
0x8FFFF = -28 673
0x00001 = 1
=================
-28 672 = 0x9000


This means we can use the same adder/subtracter regardless
of whether we are treating the inputs as signed/unsigned.
Post by EECS Instructional Account
2. What exactly is signed overflow? Is it simply an indicator that goes high
when the resulting number can no longer be represented in 16-bit
sign-magnitude form?
Signed overflow is overflow that occurs when we are treating
the output as signed. For example, say we add
0x8000 + 0x8000 = 0x0000
This is signed overflow because we tried to add -32 768 to -32 768,
which should be -65 536, but that doesn't fit in 16 bits of 2's comp
and we end up with 0 as the result.

Another example of signed overflow is 0x4000 + 0x4000 = 0x8000.
In this case, we did 16 384 + 16 384 = 32 768, which is a number
that doesn't fit in 16 bits of 2's comp, so instead our result is
-32 768.


Albert
[Instr] Albert Chae
2008-07-27 22:56:43 UTC
Permalink
Raw Message
Yes, the logic to determine signed overflow was in the slides,
but he seemed to want a more conceptual explanation, which is
why I gave it.

Albert
The logic is right in the notes, right, having to do with Cn and Cn-1?
Post by EECS Instructional Account
Post by EECS Instructional Account
1. Do the add and subtract functions of the ALU (select 010 and 011)
treat
Post by EECS Instructional Account
the two 16-bit inputs as sign-magnitude numbers, or as simple binary
numbers
Post by EECS Instructional Account
(ie. what should be the result output)? For example, if I add 100...001
and
Post by EECS Instructional Account
000...001 should I get 000...000 or 100...010 as the result?
Consequently,
Post by EECS Instructional Account
should we be able to represent negative numbers in the result or not?
I know you corrected yourself to 2's complement, but in your
original question, you used the example of adding -1 (0xFFFF)
and 1 (0x0001) (both in sign and magnitude) and asked whether
you treated the inputs as signed or not. This is indeed
complicated for sign and magnitude, which we thankfully aren't
using. The greatest benefit of using 2's complement instead is
that addition of unsigned numbers or negative numbers is the
same. For example, adding 0xFFFF and 0x0001 gives us 0x0000
(1 bit fell off the upper end).
This is correct whether we treated the original numbers as
unsigned (65 535 + 1 = 0 with overflow)
or as signed (-1 + 1 = 0, no overflow).
Here's another example, 0x8FFF + 0x0001
0b 1000 1111 1111 1111
+ 0b 0000 0000 0000 0001
==========================
0b 1001 0000 0000 0000 = 0x9000
unsigned
0x8FFFF = 38 863
0x00001 = 1
=================
38 864 = 0x9000
signed
0x8FFFF = -28 673
0x00001 = 1
=================
-28 672 = 0x9000
This means we can use the same adder/subtracter regardless
of whether we are treating the inputs as signed/unsigned.
Post by EECS Instructional Account
2. What exactly is signed overflow? Is it simply an indicator that goes
high
Post by EECS Instructional Account
when the resulting number can no longer be represented in 16-bit
sign-magnitude form?
Signed overflow is overflow that occurs when we are treating
the output as signed. For example, say we add
0x8000 + 0x8000 = 0x0000
This is signed overflow because we tried to add -32 768 to -32 768,
which should be -65 536, but that doesn't fit in 16 bits of 2's comp
and we end up with 0 as the result.
Another example of signed overflow is 0x4000 + 0x4000 = 0x8000.
In this case, we did 16 384 + 16 384 = 32 768, which is a number
that doesn't fit in 16 bits of 2's comp, so instead our result is
-32 768.
Albert
[Instr] Albert Chae
2008-07-30 06:38:14 UTC
Permalink
Raw Message
Post by [Instr] Albert Chae
Post by EECS Instructional Account
2. What exactly is signed overflow? Is it simply an indicator that goes
high
Post by EECS Instructional Account
when the resulting number can no longer be represented in 16-bit
sign-magnitude form?
Signed overflow is overflow that occurs when we are treating
the output as signed. For example, say we add
0x8000 + 0x8000 = 0x0000
This is signed overflow because we tried to add -32 768 to -32 768,
which should be -65 536, but that doesn't fit in 16 bits of 2's comp
and we end up with 0 as the result.
Another example of signed overflow is 0x4000 + 0x4000 = 0x8000.
In this case, we did 16 384 + 16 384 = 32 768, which is a number
that doesn't fit in 16 bits of 2's comp, so instead our result is
-32 768.
Albert
How is this different from unsigned overflow then? I'm starting to get a bit
confused, aren't we always going to be treating our output as signed for this
homework? Aren't the two overflows going to overlap?
Yes, they do overlap, but not always. For example, 0xFFFF + 0xFFFF should
cause an unsigned overflow, but not a signed overflow (because -1+-1=-2).
Another example is 0x4000+0x4000. This causes a signed overflow but not
an unsigned overflow.

Albert

Loading...