Dnix

DNIX (ortografía original: D-Nix) es un sistema operativo en tiempo real similar a Unix descontinuado de la empresa sueca Dataindustrier AB (DIAB). Se desarrolló una versión llamada ABCenix para la computadora ABC 1600 de Luxor. Daisy Systems también tenía un sistema llamado Daisy DNIX en algunas de sus estaciones de trabajo de diseño asistido por computadora (CAD). No estaba relacionado con el producto de DIAB.

Historia

Inicio en DIAB en Suecia

Binders de sistema para DIAB DS90 y D-NIX

Dataindustrier AB (traducción literal: compañía accionaria de industrias informáticas) fue iniciada en 1970 por Lars Karlsson como un fabricante de computadoras de placa única en Sundsvall, Suecia, produciendo una computadora basada en Zilog Z80 llamada Data Board 4680. En 1978, DIAB comenzó a trabajar con la compañía de televisión sueca Luxor AB para producir las series de computadoras para el hogar y la oficina ABC 80 y ABC 800.

En 1983, DIAB desarrolló de forma independiente la primera máquina compatible con Unix, DIAB DS90, basada en la CPU Motorola 68000. D-NIX aquí hizo su aparición, basado en una licencia UNIX System V de AT&T Corporation. Sin embargo, DIAB era una empresa de sistemas de control industrial (automatización) y necesitaba un sistema operativo en tiempo real, por lo que la empresa reemplazó el kernel UNIX suministrado por AT&T con su propia variante en tiempo real desarrollada internamente pero compatible. Este kernel se inspiró en un kernel Z80 llamado OS.8 creado para la división Monroe Systems de Litton Industries.

Con el tiempo, la empresa también reemplazó varias de las herramientas de espacio de usuario estándar de UNIX con sus propias implementaciones, hasta el punto en que no se derivó ningún código de UNIX, y sus máquinas se podían implementar independientemente de cualquier licencia AT&T UNIX. Dos años más tarde y en cooperación con Luxor, se desarrolló una computadora llamada ABC 1600 para el mercado de oficina, mientras que, en paralelo, DIAB continúa produciendo versiones mejoradas de la computadora DS90 utilizando versiones más nuevas de las CPU de Motorola, como Motorola 68010, 68020, 68030. y finalmente 68040. En 1990, DIAB fue adquirida por Groupe Bull, que continuó produciendo y dando soporte a las máquinas DS bajo la marca DIAB, con nombres como DIAB 2320, DIAB 2340 etc., aún ejecutando la versión DIABs de DNIX.

Derivado en ISC Systems Corporation

ISC Systems Corporation (ISC) compró el derecho de usar DNIX a fines de la década de 1980 para usarlo en su línea de computadoras bancarias basadas en Motorola 68k. (Más tarde, Olivetti compró ISC y, a su vez, la revendió a Wang, que luego fue comprada por Getronics. Esta entidad corporativa, a la que se suele hacer referencia como 'ISC', ha respondido a una desconcertante variedad de nombres a lo largo de los años.) Esta rama del código era la versión compatible con SVR2, y recibió una amplia modificación y desarrollo en sus manos. Las características notables de este sistema operativo fueron su compatibilidad con paginación a demanda, estaciones de trabajo sin disco, multiprocesamiento, entrada/salida (E/S) asincrónica, la capacidad de montar procesos (controladores) en directorios en el sistema de archivos y paso de mensajes. Su soporte en tiempo real consistía en gran parte en colas internas impulsadas por eventos en lugar de mecanismos de búsqueda de listas (sin 'rebaño atronador'), prioridades de procesos estáticos en dos clases (ejecutar hasta el final y en intervalos de tiempo), soporte para archivos contiguos (para evitar la fragmentación de recursos críticos) y bloqueo de memoria. La calidad de la implementación de eventos asincrónicos ortogonales aún no se ha igualado en los sistemas operativos comerciales actuales, aunque algunos se acercan a ella. (El concepto que aún no se ha adoptado es que el punto de clasificación síncrono de toda la actividad asíncrona también podría ser asíncrono, ad infinitum. DNIX manejó esto con aplomo). La función de E/S asíncrona evitó la necesidad de sockets Berkeley select o el mecanismo poll de STREAMS de SVR4, aunque había una biblioteca de emulación de socket que conservaba la semántica del socket para la compatibilidad con versiones anteriores. Otra característica de DNIX era que ninguna de las utilidades estándar (como ps, un delincuente frecuente) hurgaba en la memoria del kernel para hacer su trabajo. En su lugar, se usaron llamadas al sistema, y esto significaba que la arquitectura interna del kernel podía cambiarse libremente según fuera necesario. El concepto de controlador permitió que las pilas de protocolos de red estuvieran fuera del núcleo, lo que facilitó enormemente el desarrollo y mejoró la confiabilidad general, aunque a un costo de rendimiento. También permitió que los sistemas de archivos externos fueran procesos a nivel de usuario, nuevamente para mejorar la confiabilidad. El sistema de archivos principal, aunque podría haber sido (y una vez fue) un proceso externo, se introdujo en el kernel por motivos de rendimiento. Si no fuera por esto, DNIX bien podría haber sido considerado un microkernel, aunque no se desarrolló formalmente como tal. Los controladores pueden aparecer como cualquier tipo de 'nativo' El archivo Unix, la estructura de directorios o el dispositivo y las solicitudes de E/S de archivos que el controlador no pudo procesar podrían pasarse a otros controladores, incluido el subyacente en el que se montó el controlador. Las conexiones del controlador también podrían existir y pasarse independientemente del sistema de archivos, como una tubería. Un efecto de esto es que el terminal de texto (TTY) como dispositivos podría emularse sin necesidad de una función de pseudo terminal basada en kernel.

Un ejemplo de donde un controlador salvó el día fue en el soporte de estación de trabajo sin disco de ISC, donde un error en la implementación significaba que el uso de canalizaciones con nombre en la estación de trabajo podría provocar un bloqueo de recursos no deseado en el servidor de archivos. Se creó un controlador en la estación de trabajo para acceder a los campos de las canalizaciones con nombre afectadas hasta que se pudieran desarrollar las correcciones de kernel adecuadas. Este controlador requirió aproximadamente 5 kilobytes de código para implementar, una indicación de que un controlador no trivial no necesitaba ser grande.

ISC también recibió el derecho de fabricar las máquinas DS90-10 y DS90-20 de DIAB como sus servidores de archivos. Sin embargo, los DS90-20 de multiprocesador eran demasiado caros para el mercado objetivo e ISC diseñó sus propios servidores y les transfirió DNIX. ISC diseñó sus propias estaciones de trabajo sin disco basadas en GUI para usar con estos servidores de archivos y portó DNIX nuevamente. (Aunque ISC usó estaciones de trabajo Daisy que ejecutaban Daisy DNIX para diseñar las máquinas que ejecutarían el DNIX de DIAB, hubo una confusión interna insignificante ya que el personal de diseño y diseño rara vez hablaba con el personal de software. Además, el personal de diseño de hardware no ¡No uses cualquiera sistema! > ellos.") El soporte de E/S asíncrona de DNIX permitió una fácil programación basada en eventos en las estaciones de trabajo, que funcionaron bien a pesar de que tenían recursos relativamente limitados. (La estación de trabajo sin disco GUI tenía un procesador 68010 de 7 MHz y solo se podía usar con 512 K de memoria, de los cuales el kernel consumía aproximadamente la mitad. La mayoría de las estaciones de trabajo tenían 1 MB de memoria, aunque hubo versiones posteriores de 2 MB y 4 MB, junto con 10 MHz.) Una instalación completa podría constar de un servidor (16 MHz 68020, 8 MB de RAM y un disco duro de 200 MB) y hasta 64 estaciones de trabajo. Aunque su arranque es lento, una matriz de este tipo funcionaría aceptablemente en una aplicación de cajero bancario. Además de la eficiencia innata de DNIX, el compilador DIAB C asociado fue clave para un alto rendimiento. Generó un código particularmente bueno para el 68010, especialmente después de que ISC terminara con él. (ISC también lo redirigió al coprocesador de gráficos TMS34010 de Texas Instruments que se usó en su última estación de trabajo). El compilador DIAB C se usó, por supuesto, para construir DNIX, que fue uno de los factores que contribuyó a su eficiencia, y todavía está disponible en alguna forma, a través de Wind River Systems.

Estos sistemas todavía están en uso a partir de este escrito en 2006, en las sucursales del antiguo Seattle-First National Bank ahora con la marca Bank of America. Puede haber, y probablemente haya, otros clientes de ISC que todavía usan DNIX de alguna manera. A través de ISC hubo una presencia considerable de DNIX en América Central y del Sur.

Eventos asíncronos

La llamada al sistema nativa de DNIX era la función de biblioteca dnix(2), análoga a la función estándar de Unix unix(2) o syscall(2) función. Tomó múltiples argumentos, el primero de los cuales fue un código de función. Semánticamente, esta única llamada proporcionó toda la funcionalidad apropiada de Unix, aunque sintácticamente era diferente de Unix y tenía, por supuesto, numerosas extensiones exclusivas de DNIX.

Los códigos de función DNIX se organizaron en dos clases: Tipo 1 y Tipo 2. Los comandos de Tipo 1 eran aquellos que estaban asociados con la actividad de E/S, o cualquier cosa que pudiera causar que el proceso de emisión se bloqueara. Los principales ejemplos fueron, F_OPEN, F_CLOSE, F_READ, F_WRITE, F_IOCR, F_IOCW, F_WAIT y F_NAP. El tipo 2 era el resto, como F_GETPID, F_GETTIME, etc. El núcleo podría satisfacerlos inmediatamente.

Para invocar la asincronía, se tuvo que haber creado un descriptor de archivo especial llamado cola de trampa a través del código de operación Tipo 2, F_OTQ. Una llamada de tipo 1 tendría el bit F_NOWAIT OR-ed con su valor de función, y uno de los parámetros adicionales para dnix(2) era el descriptor del archivo de cola de trampas.. El valor de retorno de una llamada asíncrona no era el valor normal sino un identificador asignado por el núcleo. En el momento en que se complete la solicitud asincrónica, un read(2) (o F_READ) del descriptor del archivo de la cola de trampa devolverá una pequeña estructura definida por el kernel que contiene el identificador y estado del resultado. La operación F_CANCEL estaba disponible para cancelar cualquier operación asincrónica que aún no se hubiera completado, uno de sus argumentos era el identificador asignado por el kernel. (Un proceso solo podía cancelar solicitudes que actualmente eran de su propiedad. La semántica exacta de la cancelación dependía del controlador de cada solicitud, fundamentalmente solo significaba que cualquier espera debía terminar. Se podía devolver una operación parcialmente completada.) Además del identificador asignado por el núcleo, uno de los argumentos dados a cualquier operación asincrónica era un identificador asignado por el usuario de 32 bits. Esto generalmente hacía referencia a un puntero de función a la subrutina adecuada que manejaría el método de finalización de E/S, pero esto era simplemente una convención. Fue la entidad que leyó los elementos de la cola de trampas la responsable de interpretar este valor.

struct itrq {} /* Estructura de los datos leídos en la cola trampa. */ corto it_stat; * Situación* corto it_rn; * Número de solicitud* largo it_oid; /* Identificación del propietario a petición */ largo it_rpar; * Parámetro devuelto */};

Cabe destacar que los eventos asincrónicos se recopilaron a través de operaciones normales de lectura del descriptor de archivo, y que dicha lectura también pudo ser asíncrona. Esto tuvo implicaciones para los paquetes de manejo de eventos asincrónicos semiautónomos que podrían existir dentro de un proceso. (DNIX 5.2 no tenía procesos o subprocesos livianos). También cabe destacar que cualquier operación potencialmente bloqueadora podría ejecutarse de manera asincrónica, por lo que DNIX estaba bien equipado para manejar muchos clientes con un solo proceso de servidor. Un proceso no estaba restringido a tener solo una cola de trampas, por lo que las solicitudes de E/S podrían priorizarse en gran medida de esta manera.

Compatibilidad

Además de la llamada nativa dnix(2), un conjunto completo de 'estándar' Las llamadas de interfaz libc estaban disponibles. abrir(2), cerrar(2), leer(2), escribir(2), etc. Además de ser útiles para la compatibilidad con versiones anteriores, estos se implementaron de manera compatible con binarios con la computadora NCR Tower, de modo que los binarios compilados para ella se ejecutarían sin cambios bajo DNIX. El núcleo DNIX tenía dos despachadores de trampas internamente, uno para el método DNIX y otro para el método Unix. La elección del despachador dependía del programador, y era aceptable usar ambos indistintamente. Semánticamente, eran idénticos dondequiera que la funcionalidad se superpusiera. (En estas máquinas se usaba la instrucción 68000 trap #0 para las llamadas a unix(2), y la instrucción trap #4 para dnix(2) Los dos manipuladores de trampas eran muy similares, aunque la llamada [normalmente oculta] unix(2) contenía el código de función en el registro D0 del procesador, mientras que dnix(2) lo mantuvo en la pila con el resto de los parámetros).

DNIX 5.2 no tenía pilas de protocolos de red internamente (a excepción de la delgada pila de protocolos Ethernet basada en X.25 agregada por ISC para su paquete de soporte de estaciones de trabajo sin disco), todas las redes se realizaban leyendo y escribiendo en los controladores. Por lo tanto, no había un mecanismo de socket, pero existía un libsocket(3) que usaba E/S asíncrona para comunicarse con el controlador TCP/IP. El típico programa de red derivado de Berkeley podría compilarse y ejecutarse sin cambios (módulo a los problemas habituales de portabilidad de Unix), aunque podría no ser tan eficiente como un programa equivalente que usara E/S asincrónica nativa.

Manejadores

Bajo DNIX, se podría usar un proceso para manejar solicitudes de E/S y para extender el sistema de archivos. Este proceso se denominaba Manejador y era una característica importante del sistema operativo. Un controlador se definió como un proceso que poseía al menos una cola de solicitudes, un descriptor de archivo especial que se obtenía de dos formas: con un F_ORQ o un Llamada F_MOUNT. El primero inventó una cola de solicitud aislada, un extremo de la cual normalmente se entregaba a un proceso secundario. (Los programas de ejecución remota de la red, de los cuales había muchos, usaban este método para proporcionar rutas de E/S estándar a sus hijos). Este último se conectaba al sistema de archivos para que los controladores pudieran adoptar las solicitudes de E/S de archivos. (Los programas de inicio de sesión en red, de los cuales había incluso más, utilizaron este método para proporcionar rutas de E/S estándar a sus hijos, ya que la semántica de inicio de sesión en Unix requiere una forma para que múltiples procesos quizás no relacionados entren en el estándar Ruta de E/S al operador). Una vez montado en un directorio en el sistema de archivos, el controlador recibió todas las llamadas de E/S hasta ese punto.

Un controlador leería entonces pequeñas estructuras de datos de solicitud asignadas por el núcleo desde la cola de solicitudes. (Dicha lectura podría realizarse de forma síncrona o asíncrona, según lo desee el autor del controlador). El controlador haría entonces lo que sea necesario para satisfacer cada solicitud, a menudo usando el DNIX F_UREAD y F_UWRITE llama para leer y escribir en el espacio de datos de la solicitud, y luego terminaría la solicitud apropiadamente usando F_TERMIN. Un controlador privilegiado podría adoptar los permisos de su cliente para solicitudes individuales a controladores subordinados (como el sistema de archivos) a través de la llamada F_T1REQ, por lo que no necesitaba reproducir el controlador subordinado. esquema de permisos de s. Si un controlador no pudo completar una solicitud solo, la función F_PASSRQ podría usarse para pasar solicitudes de E/S de un controlador a otro. Un controlador podría realizar parte del trabajo solicitado antes de pasar el resto a otro controlador. Era muy común que un controlador estuviera orientado a la máquina de estado, por lo que las solicitudes que estaba enviando desde un cliente se realizaban de forma asíncrona. Esto permitió que un solo controlador respondiera a las solicitudes de varios clientes simultáneamente sin que se bloquearan entre sí innecesariamente. Parte de la estructura de la solicitud era la identificación del proceso y su prioridad para que un controlador pudiera elegir en qué trabajar primero en función de esta información, no había ningún requisito de que el trabajo se realizara en el orden en que se solicitó. Para ayudar en esto, fue posible sondear las colas de solicitudes y trampas para ver si había más trabajo por considerar antes de abrocharse el cinturón para hacerlo realmente.

struct ireq {} /* Estructura de la solicitud entrante */ corto ir_fc; * Código de función */ corto Ir; * Número de solicitud* largo ir_opid; /* ID de propietario que dio en abierto o en montaje */ largo ir_bc; * Cuenta de byte */ largo ir_upar; * Parámetro de usuario */ largo ir_rad; * Dirección aleatoria */ ushort Ir.; /* ID de usuario */ ushort ir_gid; * Grupo de usuarios */ time_t ir_tiempo; * Tiempo de solicitud */ ulong ir_nph; ulong ir_npl; /* Nodo y proceso ID */};

No había ninguna restricción particular sobre el número de colas de solicitudes que podía tener un proceso. Esto se usó para proporcionar instalaciones de red para chroot jails, por ejemplo.

Ejemplos

Para dar una idea de la utilidad de los manejadores, en ISC existían manejadores para:

• sistemas de archivos extranjeros
  • FAT
  • CD-ROM/ISO9660
  • archivos de imagen de disco
  • RAM disco (para uso con discos de arranque protegidos por escrito)
• protocolos de redes
  • DNET (esencialmente X.25 sobre Ethernet, con capacidad multicast)
  • X.25
  • TCP/IP
  • DEC LAT
  • AppleTalk
• sistemas de archivos remotos
  • DNET /net/machine/path/from/its/root...
  • NFS
• Acceso remoto
  • ncu (DNET)
  • telnet
  • rlogin
  • wcu (DNET GUI)
  • X.25 PAD
  • DEC LAT
• Ejecución remota
  • rx (DNET)
  • Remsh
  • Rexec
• extensión del sistema
  • windowman (GUI)
  • vterm (como xterm)
  • document (passbook) printer
  • dmap (analógico de ruptura)
  • windowmac (GUI gateway to Macintosh)
• parches del sistema
  • llamado mango de tubería

Extensiones de ISC

ISC compró las versiones 5.2 (compatible con SVR2) y 5.3 (compatible con SVR3) de DNIX. En el momento de la compra, DNIX 5.3 aún estaba en desarrollo en DIAB, por lo que se implementó DNIX 5.2. Con el tiempo, los ingenieros de ISC incorporaron la mayoría de las funciones de su kernel 5.3 en 5.2, principalmente memoria compartida e IPC, por lo que hubo cierta divergencia de funciones entre DIAB y las versiones de ISC de DNIX. Es probable que la versión 5.3 de DIAB contuviera más funciones de SVR3 que la versión 5.2 de ISC. Además, DIAB pasó a DNIX 5.4, un sistema operativo compatible con SVR4.

En ISC, los desarrolladores ampliaron considerablemente su versión de DNIX 5.2 (solo se enumeran las características relacionadas con el kernel) según sus necesidades y las tendencias generales de la industria de Unix:

• Soporte de estación de trabajo desmontable. El sistema de archivos del núcleo de la estación de trabajo fue eliminado y reemplazado por un stub de comunicaciones Ethernet basado en X.25. El núcleo del servidor de archivos también se amplió con un componente de apareamiento que recibió las solicitudes remotas y las entregó a un grupo de procesos del núcleo para el servicio, aunque un manipulador estándar podría haber sido escrito para hacerlo. (Más tarde en su ciclo de vida de producto, ISC implementó servidores estándar Unix basados en SVR4 en lugar de los servidores DNIX. Estos STREAMS usados y un programa de servidor de archivos escrito a medida. A pesar de la estructuración menos eficiente, la fuerza de caballo cruda de las plataformas utilizadas para un servidor mucho más rápido. Es lamentable que este programa del servidor de archivos no haya soportado toda la funcionalidad del servidor DNIX nativo. Cosas repugnantes, como tuberías no funcionan en absoluto. Esta fue otra justificación para el proceso de manejo de tuberías llamado.)
• gdb soporte de relojería utilizando las características del MMU de ISC.
• Asynchronous I/O to the file system was made real. (Originalmente bloqueó de todos modos.) Se utilizaron procesos de kernel (kprocs o hilos) para hacer esto.
• Soporte para un programa de tress o similares a los estratos. Además de algunas reparaciones a errores en el estándar Unix Ptrace Mecanismo de un solo sistema, esto requería añadir una instalación de adopción de procesos temporales para que el rastreador pudiera utilizar el mecanismo estándar de un solo sistema en los procesos existentes.
• Extensiones del mecanismo de señal SVR4. Principalmente para el nuevo STOP y CONT señales, pero abarcando las nuevas llamadas de control de señales también. Debido a la falta de código fuente del ISC para el adb y sdb depura la u-page no se pudo modificar, por lo que las nuevas señales sólo podían ser bloqueadas o recibir el manejo predeterminado, no podían ser capturadas.
• Soporte para el olfato de red. Esto requiere ampliar el controlador Ethernet para que un solo evento pueda satisfacer más de una solicitud de I/O, e implementar condicionalmente el filtrado de hardware en software para apoyar el modo promiscuo.
• Disk espejoing. Esto se hizo en el sistema de archivos y no en el controlador de dispositivo, por lo que un poco (o incluso completamente) diferentes dispositivos todavía podrían ser reflejados juntos. Mirroring a un pequeño disco duro al disquete era una manera popular de probar el espejo al expulsar el disquete era una manera fácil de inducir errores de disco.
• 32-bit inode, 30 caracteres nombre de archivo, enlace simbólico y extensiones de directorio pegajosas al sistema de archivos. Añadido /dev/zero, /dev/noise, /dev/stdXXX, y /dev/fd/X dispositivos.
• Listas del grupo de procesos (de SVR4).
• #! ejecución directa del guión.
• Multiplicación del puerto serie usando las juntas de comunicaciones VMEbus Z-80 de ISC.
• Partición de swap móvil.
• Core 'dump' instantáneas de procesos de ejecución. Soporte para el comando fuser.
• Función de renice del proceso. Programa de reasignación de tiempo asociado para implementar prioridades flotantes.
• Una manera de 'mug' un proceso, privándolo instantáneamente de Todos recursos de memoria. Muy útil para determinar cuál es el conjunto de trabajo actual, en lugar de lo que todavía está disponible, pero no necesariamente se utiliza. Esto se asoció con una utilidad GUI que muestra el estado de las 1024 páginas del mapa de memoria de un proceso. (Este es el número de páginas de memoria soportadas por el MMU del ISC). En el uso usted 'mug' el proceso de destino periódicamente a través de su vida y luego mirar para ver cuánto memoria fue cambiado de nuevo en. Esto fue útil ya que el entorno de producción de ISC utilizó sólo unos pocos procesos de larga vida, controlando su utilización de la memoria y el crecimiento fue clave para mantener el rendimiento.

Características que nunca se agregaron

Cuando el desarrollo de DNIX en ISC cesó efectivamente en 1997, una serie de características planificadas del sistema operativo quedaron sobre la mesa:

• Objetos compartidos – Había dos bibliotecas cargadas dinámicamente en existencia, un encriptador para DNET y la biblioteca de imágenes del GUI, pero la instalación nunca fue generalizada. Las máquinas del ISC se caracterizaron por una falta general de espacio de dirección virtual, por lo que el uso amplio de las entidades con memoria no habría sido posible.
• Procesos ligeros – El núcleo ya tenía varios hilos que compartían un solo contexto MMU, ampliando esto a los procesos de usuario debería haber sido sencillo. Las implicaciones de la API habrían sido la parte más difícil de esto.
• Listas de control de acceso (ACL) – Trivial para implementar usando un controlador ACL montado sobre el sistema de archivos de stock.
• Múltiples particiones de swap – DNIX ya usó espacio libre en el volumen seleccionado para el intercambio, habría sido fácil darle una lista de volúmenes para intentar a su vez, potencialmente con límites espaciales asociados para evitar que consumir todo el espacio libre en un volumen antes de pasar al siguiente.
• Depuración del núcleo remoto mediante gdb – Todas las piezas estaban allí para hacerlo ya sea a través del puerto serial consuetudinario o a través de Ethernet usando el software de enlace integrado del kernel X.25, pero nunca fueron montadas.
• Apoyo de 68030 – Los prototipos de ISC nunca fueron completados. Se construyeron dos tarjetas de plug-in de procesador, pero nunca se utilizaron más que 68020 más rápido. No eran confiables, ni eran tan rápidos como podían haber sido debido a tener que encajar en una toma de 68020. El rápido cambio de contexto ISC MMU sería desactivado (y dejado en conjunto en unidades de producción propuestas), y el incrustado de la 68030 se habría utilizado en su lugar, utilizando un derivado del código MMU DS90-20. Si bien el MMU ISC era muy eficiente y soportaba el cambio instantáneo entre 32 procesos residentes, era muy limitado en la capacidad de dirección. El MMU 68030 habría permitido por mucho más de 8 MB de espacio virtual en un proceso, que era el límite de la MMU ISC. Aunque este MMU sería más lento, la velocidad global más rápida de los 68030 debería tener más que conformarse para ello, de modo que se esperaba que una máquina 68030 fuera de todas maneras más rápida, y apoyar procesos mucho más grandes.