Al agregar números binarios, ¿cómo simplemente ignora el desbordamiento?

Hay muchas maneras de explicarlo. Acá hay uno.

El binario con signo de ocho bits puede representar números enteros tan bajos como -128 _DECIMAL y tan altos como +127 _DECIMAL . Entonces, ¿por qué no puede representar el siguiente entero mayor, +128 _DECIMAL ?

Respuesta: podría representar +128 _DECIMAL . El problema es que la representación sería la misma que la de -128 _DECIMAL . Ver:

DECIMAL   BINARY
-128      1000 0000
-127      1000 0001
-126      1000 0010
...
+126      0111 1110
+127      0111 1111
+128      1000 0000
+129      1000 0001
+130      1000 0010
...

Observar:

• +128 _DECIMAL es indistinguible de -128 _DECIMAL ;
• +129 _DECIMAL es indistinguible de -127 _DECIMAL ;
• +130 _DECIMAL es indistinguible de -126 _DECIMAL ;
• etcétera.

Al mantener el bit de acarreo (en realidad no es un bit de desbordamiento; el desbordamiento es otra cosa), estaría afirmando la representación falsa, ¿no es así? Intentalo. Verás.

No quieres ese bit de acarreo.

NOTAS SOBRE EL DESBORDAMIENTO

Si quieres saber qué es el desbordamiento, es lo que sucede cuando intentas (por ejemplo) sumar 96 _DECIMAL + 64 _DECIMAL . El resultado es -32 _DECIMAL , lo cual es incorrecto porque el registro de suma se ha desbordado.

Tenga en cuenta que el ejemplo, por cierto, no tiene acarreo.

Llevar y desbordar no son lo mismo.

El MSB de un número en complemento a 2 es el bit de signo. La parte de la que estás hablando es la realización de la adición de los MSB. Hay un "desbordamiento" solo si los signos de los operandos son idénticos Y el bit de signo del resultado y ese acarreo no son idénticos. Si los signos de los operandos son diferentes, entonces no puede haber un desbordamiento, independientemente del estado del acarreo.

Pruebe algunos ejemplos para ver cómo funciona.

Recogiendo este bit específico:

Cuando agrega los números de complemento de 2, ¿siempre significa que tiene que trabajar en un número predefinido de bits y, de ser así, por qué?

Sí, necesita saber la cantidad de bits con los que va a trabajar, porque eso determina cómo se verá la representación en complemento a dos de su número negativo.

Entonces, en tu ejemplo, tienes:

  +27    0001 1011b
+ -17    1110 1111b
-------------------
  +10    0000 1010b

donde habría un "carry" fuera del 8th ^-bit . Si hiciéramos incorrectamente el mismo cálculo usando más bits y tomando nota del acarreo del octavo ^bit , obtendríamos la respuesta incorrecta:

  +27    0000 0001 1011b
+ -17    0000 1110 1111b     << WRONG representation of "-17" in 12 bits.
------------------------
 +266    0001 0000 1010b     << WRONG answer in 12 bits.

Sin embargo, si volvemos a hacer esto, pero usando la representación correcta de 12 bits de -17, obtenemos nuevamente el resultado correcto, aunque aquí estamos "ignorando" la ejecución del bit ^{12 :}

  +27    0000 0001 1011b
+ -17    1111 1110 1111b     << Correct representation of "-17" in 12 bits.
------------------------
 + 10    0000 0000 1010b     << Correct answer in 12 bits.

Conceptualmente, puede pensar en la representación "verdadera" en complemento a dos de -17como una cadena infinita de 1s, que termina en ...10 1111. Al hacer cálculos con un número finito de bits, toma solo lo suficiente de esos 1s para llenar su registro y descarta cualquier "carry" que esté fuera de ese tamaño.