Datos General MV / 8000 virtudes de "Sin bit de modo"

Estoy leyendo "El alma de una nueva máquina" de Tracy Kidder, donde un equipo de Data General diseña una nueva máquina (con el nombre clave "Eagle", más tarde llamado MV / 8000). Es una extensión de 32 bits de una arquitectura anterior (el Eclipse de 16 bits). Parece que uno de los temas giratorios es que no quieren crear una máquina con un bit de modo y que lo lograron.

Sin embargo, deja de lado cómo se logra esto técnicamente, y tampoco explica por qué era tan atractivo crear una máquina sin un bit de modo. El libro no es un libro técnico, por lo que podría ser que los detalles se distorsionaron de alguna manera. Sin embargo, tiene la sensación de leer ese libro que una solución de "bit de modo" era común (y por lo tanto factible) en ese momento, pero los ingenieros lo consideraron poco atractivo quizás por razones estéticas. El libro también hace que parezca una tarea inmensamente difícil crear un diseño sin un bit de modo, que de alguna manera fue superado por este equipo en particular.

Encontré esta descripción de cómo se logró:

http://people.cs.clemson.edu/~mark/330/kidder/no_mode_bit.txt

Básicamente, se trata de usar una parte no utilizada previamente del espacio de código de operación para las nuevas instrucciones. Debo admitir que estaba un poco decepcionado de que fuera "solo eso". También creo que esto todavía deja algunas preguntas sin respuesta:

En primer lugar, ¿cómo vivían los procesos de 16 bits en el espacio de direcciones de 32 bits? Porque creo que ese es el desafío clave para hacer una extensión de 32 bits "sin un bit de modo". Extender el conjunto de instrucciones, por otro lado, es una tarea relativamente común. Como no hay una descripción de cómo sucedió, uno podría suponer que el código de 16 bits simplemente accede a la memoria como siempre lo hizo, tal vez ve algún tipo de vista virtualizada / almacenada de la memoria (con nuevos registros de CPU que controlan dónde está la primera dirección) o algo como eso. Pero no sé si hay más que eso. En ese caso, se podría argumentar que era una solución de "bit de modo". Los procesos en modo de 16 bits podrían ejecutarse junto con otros procesos en virtud de características especiales agregadas a la CPU.

En segundo lugar, ¿por qué fue tan atractivo crear una máquina sin un bit de modo? Muchos de los beneficios promocionados en el libro es que los clientes querían ejecutar software antiguo. Pero esto no parece hablar en contra de un bit de modo, ya que todo el propósito de usar un bit de modo es tener compatibilidad con versiones anteriores. Cuando AMD extendió x86 a 64 bits, al menos de acuerdo con mi comprensión de la palabra "bit de modo", lo que hicieron exactamente fue agregar un bit de modo. Un bit especial que haría que la CPU en modo de 64 bits. Y otro bit que haría que un proceso se ejecute en un "submodo" del modo de 64 bits (para permitir la compatibilidad con aplicaciones de 32 bits). La esencia del submodo es que la CPU interpreta el flujo de instrucciones como las antiguas instrucciones de 32 bits pero que los accesos a la memoria de 32 bits realizados se resuelven utilizando el nuevo formato de tablas de páginas (configurado por el sistema operativo compatible con 64 bits) y eventualmente mapeado al espacio completo de direcciones físicas. Además, el código de 32 bits puede ser reemplazado por el código de 64 bits. Al igual que la solución Data General, esto también permitió que un programa de 32 bits se ejecutara bajo programas de 64 bits (16 bits frente a 32 bits en el caso de DG). Entonces, desde el punto de vista del cliente, no parece haber ninguna diferencia. Por lo tanto, el único beneficio podría haber sido en la implementación, simplificando el diseño, pero el libro no lo hace sonar así, ya que el modo parecía ser común incluso en ese momento (y parece que las arquitecturas posteriores también lo han hecho). lo empleé como lo muestra el caso x64).

Estoy seguro de que hay algo que me perdí, por lo que sería genial si alguien pudiera discutir más sobre los detalles técnicos y las virtudes de este diseño "sin bits de modo".

La respuesta es que Ed deCastro, presidente de Data General Management, había establecido un equipo de ingenieros en Carolina del Norte específicamente para diseñar la próxima generación de CPU. Nos asignó la tarea de apoyo y mejoras incrementales a nosotros, el equipo de Massachusetts. Tres veces propusimos una nueva arquitectura importante, cada vez con un bit de modo muy sensible, y la describimos como una mejora incremental modesta. Cada vez, Ed vio a través de nuestro disfraz y rechazó la propuesta, esperando que el equipo de Carolina del Norte tuviera éxito. Ed creía que, independientemente de cómo intentamos disfrazar nuestras propuestas, sabría que era una arquitectura de nueva generación si tuviera un poco de modo. Así que tuvimos que proponer una arquitectura de nueva generación sin bit de modo, incluso si eso la hacía menos eficiente. Así es como lo superamos Ed deCastro. Ver El alma de una nueva máquina,

$2^{16}$

Con un bit de modo, el antiguo sistema operativo de 16 bits habría tenido que modificarse para determinar si el programa era de 16 o 32 bits y luego establecer el bit de modo de manera adecuada antes de iniciar el programa.

En la práctica, parece que el MV / 8000 realmente tenía un bit de modo. En otra parte de la página web de Mark Smotherman en Clemson, ha publicado los Datos Generales, Principios de Operación ECLIPSE MV / 8000 , 1980 . Si observa el Apéndice E (a partir de la página 369) verá que el MV / 8000 tenía dos mecanismos de tabla de páginas completamente diferentes. La máquina específica con la que el MV / 8000 era compatible era el C / 350, y el C / 350 tenía una Unidad específica de asignación y protección de memoria de 16 bits, con formas específicas de controlar esa unidad. Para el funcionamiento lógico a físico de 32 bits, debe activar la Unidad de traducción de direcciones (descrita en el Capítulo 3, comenzando en la página 31).

En la práctica, lo que eso significa es que cuando ejecuta una instrucción de 16 bits en modo de 32 bits, se especifica que los 16 bits altos de la dirección lógica se configuran en 0. También debe haber alguna especificación sobre lo que sucede con el alto 16 bits de una dirección cuando ejecuta una instrucción de 32 bits en modo de 16 bits, pero no pude encontrarla durante mi breve lectura del manual.

Por lo tanto, no se trata de si un bit de modo es bueno o malo. Es más que no había una razón particularmente buena para usar un bit de modo para diferenciar entre las instrucciones de 16 y 32 bits. Las instrucciones de 16 bits usan 16 bits de dirección lógica (con los 16 bits superiores establecidos en 0) y registros de 16 bits, y las instrucciones de 32 bits usan 32 bits de dirección lógica y registros de 32 bits. El sistema operativo antiguo "simplemente funciona" en la nueva máquina, pero también puede probar las nuevas instrucciones ejecutando un nuevo programa en el sistema operativo antiguo.