Programadores machistas, memoria de batería y un análisis forense del código máquina de la década de 1960

Los programadores reales no usan PASCAL

Los programadores de hoy crean aplicaciones distribuidas y redes neuronales artificiales. Utilizan programación reactiva funcional, marcos web de código abierto y entornos sin servidor. Sin embargo, el síndrome del impostor es real y los programadores aún se critican entre sí por no ser "programadores reales".

Trabajé como docente para el Museo de Historia de la Computación durante años. El tropo de un "programador real" ha existido desde el comienzo del software. Y puedo probarlo con una historia.

La historia comienza con una carta de 1983, Los programadores reales no usan PASCAL, escrita por Ed Post. La carta fue publicada en Datamation y discutió el lado "macho" de la programación. Aguijoneó a aquellos que menosprecian a los usuarios de lenguajes de alto nivel como no "programadores reales".

The Story of Mel es una respuesta en línea a esa carta. Fue publicado en Usenet el 21 de mayo de 1983 por Ed Nather.

Mel y Ed eran colegas de una empresa de máquinas de escribir que se había diversificado en la construcción de computadoras. Su gran éxito fue el LGP-30: una computadora con memoria de batería con un teclado Flexowriter y un lector de cinta de papel. (La imagen del encabezado de este artículo es el tablero de un LGP-30.) A Mel se le asignó la tarea de reescribir un programa popular para la computadora sucesora, la RPC-4000.

¿Puerto? Qué significa eso?

Después de que Mel dejó la empresa, a Ed se le asignó la tarea de reescribir parte de este programa. En la historia, descubre un bucle infinito en el código, que de alguna manera no impide que el programa funcione:

Quizás mi mayor sorpresa fue cuando encontré un bucle inocente que no tenía ninguna prueba.

Sin prueba. Ninguna.

El sentido común decía que tenía que ser un ciclo cerrado, donde el programa circularía, para siempre, sin fin.

Sin embargo, el control del programa lo atravesó y salió con seguridad por el otro lado.

Ed descubrió que el circuito cerrado estaba provocando un desbordamiento, que reescribió el código de instrucción. El resultado del desbordamiento fue una instrucción de salto , moviendo el control del programa a una ubicación de memoria diferente.

Es una gran historia. ¿Pero echa un vistazo?

Análisis de código forense: ¿La historia es correcta?

Nuestro primer paso es buscar los detalles técnicos de la máquina para la que se escribió el programa. Si bien la historia menciona extensamente el LGP-30, el programa en realidad se estaba ejecutando en un RPC-4000. (Recuerde, era necesario reescribirlo para esta nueva máquina).

Ambas máquinas utilizaron memoria de tambor para almacenar programas. (Dato curioso: ¡el equivalente aproximado de su disco duro moderno era la memoria del tambor, la cinta de papel, las tarjetas perforadas o la cinta magnética!) Una sola línea de cabezales electromagnéticos leería / escribiría datos mientras el tambor giraba a una velocidad constante debajo de ellos. Aquí hay una referencia visual:

Los datos se almacenaron y recuperaron de los diversos sectores y pistas del tambor. Para obtener más información sobre el formato de los datos, podemos consultar el manual de programación RPC-4000, que archive.org ha escaneado y conservado en línea.

En la página 20 del manual, encontramos el siguiente diagrama de palabras de datos:

La palabra de comando se divide en:

  • 5 bits para el comando
  • 13 bits para la ubicación de la pista / sector del operando
  • 13 bits para la pista / sector de la dirección del siguiente comando

El bit 31 es la etiqueta de índice que, cuando se establece, activa el registro de índice:

[El registro de índice] permitió al programador escribir un ciclo de programa que usaba una instrucción indexada en su interior; cada vez, el número en el registro de índice se agregó a la dirección de esa instrucción, por lo que se referiría al siguiente dato de una serie.

La historia menciona que el "bit de índice" es " el bit que se encuentra entre la dirección y el código de operación en la palabra de instrucción ". Sin embargo, el diagrama anterior muestra que el bit de la etiqueta de índice está realmente en el bit 31, más allá del comando y las direcciones. Personalmente, atribuyo esto a un error de recuerdo del autor en los años transcurridos entre la revisión del código y la grabación de la historia.

Afortunadamente, esto no afecta el aspecto de desbordamiento de la historia. Dado que la palabra de instrucción fue que se tira en la memoria y se incrementa, aún tendría que establecer el bit de índice en el fin para el incremento a desbordar la siguiente dirección .

Para recrear las palabras de instrucción en el ciclo, necesitamos saber más sobre cómo funcionaba el programa. Aquí hay una cita de la parte crítica de la historia:

Había localizado los datos en los que estaba trabajando cerca de la parte superior de la memoria.

las ubicaciones más grandes que las instrucciones podrían abordar -

entonces, después de que se manejó el último dato, incrementar la dirección de instrucción haría que se desbordara.

El acarreo agregaría uno al código de operación, cambiándolo al siguiente en el conjunto de instrucciones: una instrucción de salto.

Efectivamente, la siguiente instrucción del programa estaba en la ubicación de la dirección cero, y el programa siguió felizmente su camino.

Implementación hipotética: "¡Muéstrame los bits!"

Aquí hay una instrucción potencial que puede ser la instrucción de salto a la que se hace referencia en la historia:

Podemos ver que los bits de comando son 10111 . Si el Control de sucursal está desactivado, "la siguiente instrucción es la especificada en el campo Siguiente dirección". Entonces, una situación hipotética sería que, después del desbordamiento, el registro (usando tuberías para denotar separaciones entre campos de bits) lea:

10111 | 0000000 | 0000000 | 0

Extrapolando hacia atrás, antes del incremento y desbordamiento, el registro habría leído:

10110 | 1111111 | 1111111 | 1

Un efecto secundario interesante de trabajar con esta implementación es que la instrucción utilizada realmente no importa. Cada instrucción en el RPC-4000 incluye la dirección de la siguiente instrucción. Un desbordamiento en el bit de índice en el siguiente campo de dirección resultará en un salto a esa dirección independientemente de los bits de comando.

Epílogo

Mel Kaye (en la foto de pie, más a la derecha) continuó trabajando y finalmente se retiró. Un fan llamado Anthony Cuozzo publicó en 2014 que trató de ponerse en contacto con Mel:

Finalmente logré ponerme en contacto con Mel, pero desafortunadamente lo asusté. Esa es una historia para otro día…: - / (fuente)

Por respeto a la privacidad de Mel, no publicaré ninguna información personal y me ceñiré al programa y a la historia. Si alguien sabe cómo se siente Mel acerca de su fama en Internet, me encantaría saber de ti.

No me he mantenido en contacto con Mel, así que no sé si alguna vez se rindió a la avalancha de cambios que se han apoderado de las técnicas de programación desde aquellos lejanos días. Me gusta pensar que no lo hizo. - Ed Nather

Otras fuentes:

  • Página de Wikipedia sobre la historia de Mel
  • Manual de Mel para el juego de blackjack RPC-4000
  • La verdad nunca se interpone en el camino de una buena historia por Jan Howard Brunvand

Dave trabaja en relaciones con desarrolladores en IBM. Por alguna razón, IBM no tiene un SDK para el RPC-4000.