Skip to main content
Electrical Engineering

Return to Answer

added 8 characters in body
Source Link
Chris Stratton
Chris Stratton
  • 33.6k
  • 3
  • 45
  • 90

Adding signed integers which yield a sum outside of the range of representation is formally invalid.

To make it practically work, you would need software logic to figure out what happened and create a correct result in some viable representation, for example you could test that both operands were positive and re-interpret the result as a positive value in a wider (or simply unsigned) format.

However the most common higher-level language scheme (for example in C) is to require that you first change the representation of the arguments to one wide enough to hold the result, so for example you would store your 8-bit values in 16-bit registers and add them to produce a 16-bit result. While in one view inefficient (if this is wider than your ALU and thus requiring multiple additions), from another perspective this actually is efficient, since the operations are always the same irrespective of the data, and in (later) pipelined and otherwise accelerated designs, making program-flow decisions can cost more time than performing arithmetic.

Adding signed integers which yield a sum outside of the range of representation is formally invalid.

To make it practically work, you would need software logic to figure out what happened and create a correct result in some viable representation, for example you could test that both operands were positive and re-interpret the result as a positive value in a wider (or simply unsigned) format.

However the most common higher-level language scheme (for example in C) is to require that you first change the representation of the arguments to one wide enough to hold the result, so for example you would store your 8-bit values in 16-bit registers and add them to produce a 16-bit result. While in one view inefficient (if this is wider than your ALU and thus requiring multiple additions), from another perspective this actually is efficient, since the operations are always the same irrespective of the data, and in pipelined and otherwise accelerated designs, making program-flow decisions can cost more time than performing arithmetic.

Adding signed integers which yield a sum outside of the range of representation is formally invalid.

To make it practically work, you would need software logic to figure out what happened and create a correct result in some viable representation, for example you could test that both operands were positive and re-interpret the result as a positive value in a wider (or simply unsigned) format.

However the most common higher-level language scheme (for example in C) is to require that you first change the representation of the arguments to one wide enough to hold the result, so for example you would store your 8-bit values in 16-bit registers and add them to produce a 16-bit result. While in one view inefficient (if this is wider than your ALU and thus requiring multiple additions), from another perspective this actually is efficient, since the operations are always the same irrespective of the data, and in (later) pipelined and otherwise accelerated designs, making program-flow decisions can cost more time than performing arithmetic.

Source Link
Chris Stratton
Chris Stratton
  • 33.6k
  • 3
  • 45
  • 90

Adding signed integers which yield a sum outside of the range of representation is formally invalid.

To make it practically work, you would need software logic to figure out what happened and create a correct result in some viable representation, for example you could test that both operands were positive and re-interpret the result as a positive value in a wider (or simply unsigned) format.

However the most common higher-level language scheme (for example in C) is to require that you first change the representation of the arguments to one wide enough to hold the result, so for example you would store your 8-bit values in 16-bit registers and add them to produce a 16-bit result. While in one view inefficient (if this is wider than your ALU and thus requiring multiple additions), from another perspective this actually is efficient, since the operations are always the same irrespective of the data, and in pipelined and otherwise accelerated designs, making program-flow decisions can cost more time than performing arithmetic.