Esta parte se centra en comparar el lenguaje de máquina de mainframe con otros sistemas que fueron populares entre los años 70 y 90. Estos son principalmente x86, 68k, VAX y ARM. Los sistemas 390 y, en particular, Z se consideran muy fragmentarios; el enfoque principal está en el sistema 370.
Los primeros sistemas 360 comenzaron a enviarse a los clientes en 1965 y los sistemas 370 más avanzados a partir de 1970. ¡IBM mantiene la compatibilidad de software con estos sistemas hasta el día de hoy! Sorprendentemente, antes de 390 sistemas, como se puede suponer desde 1990, los mainframes funcionaban con direcciones de 24 bits, es decir, no podían direccionar más de 16 megabytes de memoria, lo mismo que, por ejemplo, 68000, lanzado en 1979, o 65816o 32016, lanzado en 1982. VAX admitía de forma nativa el direccionamiento de 32 bits. Los populares procesadores 68020 u 80386, que aparecieron a mediados de la década de 1980, también admitían direcciones de 32 bits. De hecho, 16 MB de memoria para los mejores sistemas de la segunda mitad de los 80 ya no eran suficientes. Sin embargo, desde 1983, IBM ha estado produciendo 370 computadoras compatibles que podrían, como extensión, usar 31 dígitos de dirección, lo que eliminó el problema de la memoria para mejores computadoras. De manera inusual y única, estas extensiones y 390 sistemas utilizaron una dirección de 31 bits en lugar de una de 32 bits completa. En 2000, IBM anunció el primer sistema Z en utilizar direcciones y datos de 64 bits. Los sistemas Z han estado usando chips de procesador desde 2008. Han estado intentando combinar la arquitectura Z desde 2007 en un solo chip con la arquitectura POWER, pero hasta ahora sin éxito. Hasta ahora, solo Intel ha logrado combinar CISC y RISC en un solo chip: Pentium Pro en 1995 se convirtió en el primer chip de su tipo.
IBM System / 370-145 con una unidad de cinta 2401 y una impresora en lugar de una pantalla, 1971. Puede ser sorprendente que no haya pantalla en este sistema tan caro a pesar de que los televisores se han producido en masa durante más de 20 años.
Por cierto, algunas autoridades creen que la primera computadora personal en serie fue IBM 5100 , en producción desde 1975, que podía ejecutar instrucciones del sistema 360 a través de un emulador de hardware. Se produjeron versiones mejoradas del mismo hasta mediados de la década de 1980. Sin embargo, el Wang 2200 fue bastante el primero . A precios (aproximadamente $ 10,000), estas primeras computadoras personales claramente no eran para uso doméstico.
IBM 5100, variante APL
Con el advenimiento de la arquitectura IBM PC, que, como resultó, determinó la dirección principal del desarrollo de la tecnología informática durante décadas, IBM intentó en 1983 combinar casi todas las mejores tecnologías informáticas en un solo producto PC XT / 370: sus sistemas 370, IBM PC XT, Motorola 68000 e Intel 8087. Este XT / 370 podría usarse como un terminal inteligente para trabajar con un mainframe, como un IBM XT normal, o para ejecutar directamente el software del mainframe. Curiosamente, el XT / 370 agregó soporte para el uso de memoria virtual, que requirió dos 68000. En 1984, con la llegada del PC AT, se lanzó una versión mejorada del AT / 370 "mainframe personal", que era aproximadamente el doble de rápido que el XT en modo mainframe. / 370. La historia de este tipo de sistemas no acabó ahí, desde los años 90 se han producido productos similares, correspondientes a 390 sistemas.Hasta donde yo sé, esto no se ha hecho para los sistemas Z.
IBM utiliza un modelo de negocio bastante inusual para sus mainframes, en el que las computadoras no se venden sino que se alquilan. Una de las ventajas de dicho modelo es que garantiza una actualización constante del equipo, el equipo obsoleto se reemplaza automáticamente por uno actualizado de la clase correspondiente. Este modelo también tiene desventajas. Por ejemplo, una desventaja particularmente perceptible para quienes estudian la historia de la tecnología informática es el hecho de que las computadoras usadas casi siempre se desechan y, por lo tanto, es casi imposible encontrarlas en cualquier museo.
Sorprendido de encontrar un sistema IBM 4361 en vivo en LCM! Pero hay razones para creer que esto puede no ser hierro real. Por alguna razón, los visitantes del museo no tienen acceso a esta computadora. Tampoco está claro qué modelo se presenta supuestamente allí, y esto a pesar de que otras computadoras en el museo están identificadas con mucha precisión. Entre los sistemas 4361, se conocen tres modelos 3, 4 y 5, y el modelo 3 apareció más tarde que los modelos 4 y 5. Pero el sistema en el museo se autoidentifica como modelo 1. Es posible que se trate de un prototipo. Sin embargo, el personal del museo no respondió a una pregunta directa sobre la ayuda con la identificación, y esto a pesar de que responden a otras preguntas, a menudo bastante difíciles, con bastante rapidez. Algunas características de la sincronización de la ejecución de los códigos dan motivos, aunque no absolutamente sólidos, para suponer que lo más probable es que el emulador esté conectado a la red. En el verano en el museo, en relación con covid,obviamente cambió a un emulador ... Todavía existe la posibilidad de acceder a los mainframes de hierro a través de la redHNET , pero aún no lo he logrado.
Pero sea lo que sea, cualquiera puede conectarse e intentar trabajar de la misma manera que los especialistas bien pagados han trabajado desde mediados de los 70. Los precios eran tales que hoy es difícil de creer. Por ejemplo, una hora de tiempo de computadora costaba más de $ 20 a mediados de los 80, ¡y todavía tenía que pagar más por espacio en disco! Es cierto que estamos hablando del tiempo de funcionamiento del mainframe y no del terminal por el que pasaba el trabajo. Por lo tanto, por ejemplo, cuando se edita un texto de una hora de trabajo real, rara vez se necesitan ni siquiera 5 minutos para pagar. Los precios de los mainframes también eran fantásticos. Por ejemplo, los empleados de Intel recuerdan que a principios de la década de 1980 solo se les dio un mainframe para trabajar. Su rendimiento era de 10 MIPS y el precio era de unos 20 millones de dólares en ese momento, ¡que era tres veces más alto que hoy! Interesante,que Intel prefería tales computadoras a los sistemas VAX más baratos. Ahora inclusoUna Raspberry Pi es del tamaño de una pastilla, tiene un precio de unos pocos dólares y puede ofrecer fácilmente más de 1000 MIPS. Por cierto, en una Raspberry Pi o en casi cualquier computadora moderna, puede ejecutar un emulador IBM / 370, que se ejecutará significativamente más rápido que cualquier sistema IBM de los 80 o incluso los 90. Sin embargo, el emulador debe configurarse y no todos los programas útiles para IBM / 370 están disponibles gratuitamente, por lo que el acceso gratuito a un sistema bien ajustado es a menudo la mejor manera de moverse por el mainframe. Sorprendentemente, estos programas de acceso, emuladores de terminal 3270, están disponibles incluso en teléfonos móviles. Por cierto, logré configurar mi sistema VM / CMS en el emulador de Hercules y lidiar con la transferencia de archivos, pero me tomó al menos una semana.
El emulador de Hercules puede emular sistemas IBM / 390 e IBM / Z posteriores, pero debido a problemas de licencia de software, esto es mucho más difícil de hacer. Como ilustración de tales problemas, citaré el famoso caso en el que IBM insistió en eliminar la sección Emulación de un libro ya publicado. En las versiones electrónicas modernas de este libro, esta sección no existe; solo se puede encontrar en la edición impresa o como un archivo separado en sitios dedicados al software libre. El hecho es que la emulación en PC normales desde principios de la década de 2000 podría ser notablemente más rápida que la ejecución en mainframes mucho más costosos. Por lo tanto, IBM tuvo que cambiar sus licencias de software para que solo se pueda usar legalmente en hardware comprado a IBM. Por supuesto, no estamos hablando de que los emuladores sean más rápidos que los mejores mainframes,solo muestran una relación rendimiento / costo notablemente mejor.
Una forma de trabajar con los sistemas Z o 390 es instalar Linux en un emulador de esos sistemas. Para 390 y Z, al menos las distribuciones Ubuntu y Debian están disponibles. Vale la pena señalar aquí que el rápido desarrollo de Linux se debe en gran parte al importante apoyo de IBM. En particular, IBM invirtió en 2001 mil millones de dólares en el desarrollo de Linux.
Consideremos ahora las características del lenguaje máquina de los sistemas compatibles con 360. El ensamblador básico de tales sistemas se llama BAL - Basic Assembly Language. Sorprendentemente, si hay que creer en los rumores sobre IBM, entonces el ensamblador sigue siendo uno de los principales lenguajes de programación de trabajo allí.
El ensamblador de los mainframes en cuestión tiene una serie de características arcaicas que ya estaban ausentes en otras arquitecturas conocidas que aparecieron más tarde. Por ejemplo, se trata del hecho de que los mnemónicos BAL determinan el tipo de argumentos. Considere las instrucciones del ensamblador x86 como ejemplo
MOV EAX,EBXy MOV EAX,addressambos usan el mnemónico MOV. Para BAL, para tales casos, se utilizan diferentes nemotécnicos LR y L en los comandos, respectivamente, LR 0,1yL 0,address... Sin embargo, nemotécnicos diferentes similares permiten usar números para nombrar registros, aunque generalmente las macros R0, R1, ... en lugar de los números 0, 1, ... son lo primero que se define en los paquetes de macros por conveniencia de programación. Otro arcaísmo es el uso de saltos de etiquetas en construcciones de compilación condicional, aunque en mi humilde opinión, esto a veces es más conveniente que las estructuras de bloques. Pero el arcaísmo más famoso es el uso de la codificación EBCDIC para trabajar con información simbólica. En esta codificación, extraña incluso para ayer, las letras del alfabeto inglés no están codificadas en una fila, por ejemplo, la letra I tiene un código 201, ¡y la siguiente J es 209! Esta codificación proviene de tecnologías para trabajar con tarjetas perforadas que surgieron en la era anterior a las computadoras. System 360 también admite ASCII en hardware, pero en su versión antigua y olvidada,donde el carácter del dígito 0 tiene el código 80, no 48 como es ahora. Hasta donde yo sé, ASCII con mainframes de IBM era mejor ni siquiera intentar usarlo. El soporte ASCII ya se eliminó en 370 sistemas, pero se introdujo a un nuevo nivel en 390 sistemas. Algunos mnemónicos BAL son sorprendentes en su supercorteza e incluso no nemonicidad, por ejemplo, N significa Y, O - O, X - XOR, A - ADD, S - RESTA, M - MULTIPLICAR, ...
El ensamblador BAL le permite trabajar con tres tipos de datos básicos: números binarios, decimales y reales. Los sistemas 390 utilizan otro tipo especial para trabajar con números reales. Algunos sistemas Z también pueden utilizar datos completamente únicos, como números reales decimales. Las instrucciones para trabajar con cada tipo forman una clase de instrucciones especial y bastante aislada. Normalmente, con muy pocas excepciones, todos los sistemas compatibles con 360 admiten instrucciones aritméticas decimales y reales. Como sabe, para arquitecturas x86 o 68k, el soporte para trabajar con números reales no apareció de inmediato y durante mucho tiempo fue una opción opcional, y trabajar con números decimales no era algo completamente separado de la aritmética binaria, era más bien una extensión.
Para trabajar con números reales y binarios, se utilizan diferentes conjuntos de registros, y para trabajar con números decimales, no se utilizan registros en absoluto. El sistema 370 proporciona 16 registros de 32 bits de propósito general para enteros binarios, siendo el contador de programa parte de la palabra de estado del procesador. No hay una pila separada, se puede organizar usando cualquier registro; así es como se implementó posteriormente el trabajo con la pila en ARM. La llamada de subrutina también se realiza como en ARM, a través del registro de enlace. Todos los registros son casi siempre intercambiables, las excepciones son muy raras. Si compara el sistema de registro binario BAL con la arquitectura VAX competitiva, notará que el VAX tiene un registro menos. Esto también es cierto para ARM.
La estructura de los operandos en las instrucciones parecerá bastante familiar para aquellos que conocen el ensamblador x86. Para los números binarios, los operandos tienen una estructura de registro-registro o registro-memoria, y para el último caso, los valores expandibles con signo de 32 y 16 bits se pueden cargar desde la memoria. Por ejemplo, un análogo de la instrucción x86
ADD EAX,EBXsería AR 0,1, ADD EAX,address- A 0,address, ADD EAX,address[EBX]- A 0,address(1), ADD EAX,address[EBX][EDX]- A 0,address(1,3). Sin embargo, los sistemas 360 e incluso su desarrollo posterior no saben cómo trabajar con escalado, por ejemplo, no se ADD EAX,address[8*EBX]puede escribir en BAL con un solo comando. Por otro lado, x86 no sabe cómo trabajar con extensiones firmadas de 16 bits, por ejemplo, el comando BALAH 0,address, lo que significa tomar un número firmado de 16 bits de la memoria y agregarlo al contenido del registro 0, en x86 requiere dos instrucciones para implementar.
Una característica poco común de BAL es que hay instrucciones separadas para sumar y restar números con y sin signo, y las operaciones sin signo en BAL se denominan booleanos. Esta rareza se debe a la ausencia de indicadores en la arquitectura 360 que son familiares para la mayoría de las otras arquitecturas. En su lugar, solo se utilizan dos bits, que se establecen de manera diferente mediante instrucciones diferentes. La única diferencia entre las operaciones firmadas y no firmadas es que establecen los dos bits de atributo mencionados de manera diferente. Para las operaciones firmadas en ellos, puede averiguar si el resultado fue cero, si fue positivo o negativo, si ocurrió un desbordamiento, y para las operaciones sin firmar, si el resultado fue cero y si ocurrió una transferencia o un préstamo. Las instrucciones de bifurcación condicional permiten los 16 subconjuntos de casos que son posibles con 2 bits.Debido a este trabajo inusual con los signos de operación en la actualidad, las instrucciones de salto condicional son difíciles de comprender rápidamente. Aunque las extensiones BAL generalmente agregan macros bastante fáciles de leer para saltos condicionales, donde no es necesario analizar cada uno de los 4 bits. Aquí, para ser justos, puede ver que hay comandos separados para sumas y restas firmadas y sin firmar, por ejemplo, en la arquitectura MIPS, ¡donde no hay banderas en absoluto!por ejemplo, en la arquitectura MIPS, donde no hay ningún indicador.por ejemplo, en la arquitectura MIPS, donde no hay ningún indicador.
Otra característica poco común son los comandos separados para comparaciones firmadas y no firmadas. Conocí a otros similares no solo en MIPS, sino también en MicroBlaze. En este último, por cierto, la transferencia es el único indicador admitido de los indicadores de operación.
En sistemas compatibles con IBM 360, no existen operaciones aritméticas con la bandera de acarreo, por lo que si necesitamos trabajar con números binarios, por ejemplo, en números de 128 bits, entonces debemos verificar el signo de acarreo luego de realizar las primeras operaciones de 32 bits para organizar su suma o resta. y haga la transición si es necesario. Esto es, por supuesto, muy engorroso en comparación con x86, ARM, 68k o incluso 6502, pero en MIPS mucho más tarde es incluso más engorroso. El trabajo normal con la transferencia se realizó solo en el sistema Z.
No hay cambios cíclicos en BAL, pero los cambios no cíclicos, como en x86, pueden ser simples o dobles. Sin embargo, BAL tiene instrucciones de turno separadas para números firmados y sin firmar, solo los últimos establecen banderas de bandera. Obviamente, los resultados de los desplazamientos a la izquierda para ambos casos difieren solo en las banderas. Giros agregados solo a 390 sistemas.
Entre los comandos para cargar registros en BAL, es muy probable que haya algunos únicos. Puede cargar el módulo de un número entero, la negación de este módulo o un número con un signo cambiado, algo remotamente similar que solo he encontrado en la arquitectura ARM. Cabe señalar aquí que toda la arquitectura de 360 tiende a firmar aritmética, y la aritmética sin firmar en esta arquitectura es bastante secundaria. Inicialmente, BAL no tenía división y multiplicación sin firmar, se agregaron solo al sistema 390. Cuando se carga el registro, las banderas, al igual que en x86, no cambian, pero hay un comando de arranque especial que establece las banderas; esto nuevamente le recuerda a ARM, donde se pueden configurar las banderas. gobernar.
Todas las operaciones aritméticas con signo, incluidos los turnos, pueden generar una excepción de desbordamiento. Si se lanza una excepción o no, se determina mediante un indicador de máscara especial en el registro de estado. Curiosamente, la división binaria y la multiplicación en BAL no afectan en absoluto a las banderas; aquí puede recordar x86, donde la división solo estropea las banderas.
Las operaciones lógicas bit a bit en BAL están representadas por el conjunto habitual de Y, O, O exclusivo, es decir, no hay una operación de negación separada. Las operaciones lógicas pueden tener no solo una estructura de registro-registro o registro-memoria, sino también “memoria-constante” o “memoria-memoria”; el último método de direccionamiento es similar al utilizado para números decimales. El direccionamiento del tipo "constante de memoria" solo es posible para trabajar con bytes. Obviamente, para operaciones lógicas, a diferencia de la aritmética, el uso de números de 16 bits es imposible. Para el direccionamiento de memoria a memoria, puede trabajar con datos de hasta 256 bytes. Resulta que tenemos tres tipos de datos para trabajar con operaciones lógicas: bytes, palabras de 32 bits, secuencias de bytes e instrucciones especiales para cada uno de este tipo, que de alguna manera no es universal.
Las operaciones lógicas en BAL son adyacentes a las operaciones para transferir bytes. Además de la transferencia habitual de hasta 256 bytes con un comando, también hay una instrucción única para transferir tétradas de bytes. Puede enviar solo las mitades superior o inferior de los bytes, mientras que las otras mitades conservan su valor durante la copia. Estas operaciones extrañas son necesarias para admitir las funciones BAL cuando se trabaja con información decimal y de caracteres. También hay instrucciones de reenvío y comparación para 370 sistemas de hasta 16 millones de bytes a la vez, que pueden interrumpirse. Sorprendentemente, los comandos lentos para trabajar con bloques de hasta 256 bytes no se pueden interrumpir, lo que puede crear un retraso desagradable en respuesta a una solicitud de interrupción. Los comandos de transferencia también se pueden usar para llenar la memoria con un byte específico.Además de transferir de memoria en memoria, también puede establecer bytes individuales en un valor dado. Obviamente, las instrucciones para transferir bytes, además de las nuevas instrucciones para 390 y Z, son más avanzadas para x86.
En el registro, puede cargar no solo el valor en la dirección dada, sino también la dirección en sí, como en los comandos LEA para x86 o 68k. Esta función también le permite cargar directamente la constante requerida en el registro, aunque su valor máximo no puede ser mayor que 4095. También le permite incrementar el registro en no más de 4095. Pero la disminución del registro se puede hacer solo en 1. Tanto un incremento como un decremento - estos son comandos de dirección, por lo que no cambian los indicadores. Puede cargar bytes individuales e incluso grupos de bytes de una palabra en la memoria en el registro, por ejemplo, solo el primer y tercer bytes; esto es posible para todas las demás arquitecturas de 32 bits que conozco solo a través de una serie de 4 comandos. Asimismo, BAL permite que solo se vuelquen a la memoria partes de un registro.
La serie de instrucciones BAL son muy especializadas; en otras arquitecturas, se implementan mediante una serie de instrucciones más simples. Por ejemplo, la instrucción TR le permite convertir una cadena de caracteres: un argumento especifica la cadena a convertir y el otro la dirección de la tabla de conversión. Se puede usar una variante especial de esta instrucción, TRT, para escanear una cadena dada y omitir caracteres vacíos - esta es la funcionalidad de la llamada estándar de C strpos. Las instrucciones ED y EDMK son completamente únicas - ¡tienen la funcionalidad del primitivo sprintf! Sin embargo, casi todas las operaciones de cadena tienen una limitación en la longitud máxima de cadena, no más de 255 bytes, lo que reduce significativamente su potencia.
En BAL, es difícil trabajar con valores sin firmar de 16 bits debido a la falta de rotación o comandos de tipo SWAP. Con 390 sistemas, este problema ha mejorado. Algunas instrucciones BAL están en desuso, por ejemplo, la instrucción de cambio de nibble MVO ha sido reemplazada por la más conveniente SRP. Para transferencias en bloque y comparaciones, es mejor usar las nuevas instrucciones, aunque debido al hecho de que usan una forma diferente de direccionamiento, esto puede, en algunos casos raros, no ser óptimo.
Ya ha habido ejemplos de los cuatro modos básicos de direccionamiento BAL. También hay un quinto para comandos de tres direcciones. Los modos como VAX, 68k, PDP-11 o incluso los modos de incremento o decremento automático 6809 no están disponibles en BAL. Tampoco hay modos DIMM como VAX, 68020 o PDP-11. Y, por supuesto, BAL, a diferencia de los ensambladores VAX o PDP-11, es completamente no ortogonal. BAL es el más cercano a los ensambladores x86 y ARM, las arquitecturas modernas más exitosas. El orden de los operandos en BAL de derecha a izquierda es el mismo que en ensamblador Intel para x86 o en ensamblador ARM y, en consecuencia, no como VAX, PDP-11 o 68k. Aunque el orden de bytes en los datos en BAL es de mayor a menor (MSB), que difiere de x86, ARM o VAX, corresponde al aceptado para 68k o MIPS.
Las operaciones con números decimales se implementan en BAL solo a través del direccionamiento de memoria a memoria. Los números decimales se pueden especificar en trozos de hasta 16 bytes, lo que permite utilizar números de hasta 31 lugares decimales. Esto corresponde a la precisión de un número binario de 107 bits. Por lo tanto, ¡solo los sistemas de programación más modernos que usan enteros binarios pueden manejar valores mayores que los sistemas 360 hace casi 60 años! Por supuesto, es posible implementar números arbitrariamente grandes mediante aritmética binaria, pero por alguna razón, hasta hace poco, no existían lenguajes de programación populares que admitieran números mayores que el antiguo sistema 360. Incluso ahora, el soporte para enteros de 128 bits para x86 suele ser solo extensiones no oficiales, como para GCC.
Los números decimales en BAL se representan de forma única, deben almacenar el signo; no existe tal cosa para VAX, x86, 68k, ... Además, el signo se almacena en el último byte de la representación del número. Para los números decimales, BAL tiene soporte directo para todas las operaciones básicas: suma, resta, multiplicación e incluso división; esto tampoco se encuentra en ninguna otra arquitectura que conozca. Además, BAL tiene instrucciones para copiar, comparar y cambiar números decimales. Las instrucciones MVO y SRP mencionadas anteriormente están diseñadas para esos cambios. Las operaciones se pueden realizar solo en números decimales empaquetados, pero para imprimirlos hay que desempaquetarlos, y para representar dígitos desempaquetados en BAL también se necesita un signo, que en este caso no ocupa espacio, ya que se coloca en la tétrada superior, lo que requiere un trabajo especial con este cuaderno antes de imprimir.Es extraño que las operaciones de boxing y unboxing solo puedan funcionar en no más de 16 bytes del número decimal descomprimido, lo que permite usar solo números de 15 bits con ellos. Este desagradable problema se puede resolver utilizando ED o EDMK para las instrucciones de desembalaje, pero el empaquetado de una gran cantidad desempaquetada tendrá que hacerse mediante una secuencia de instrucciones no muy simple. Se han agregado nuevas instrucciones a 390 sistemas para abordar este problema. Curiosamente, las instrucciones de empaque y desempaque funcionan con cualquier dato binario, no solo con decimal.Este desagradable problema se puede resolver utilizando ED o EDMK para las instrucciones de desembalaje, pero el empaquetado de una gran cantidad desembalada tendrá que hacerse mediante una secuencia de instrucciones no muy simple. Se han agregado nuevas instrucciones a 390 sistemas para abordar este problema. Curiosamente, las instrucciones de empaque y desempaque funcionan con cualquier dato binario, no solo con decimal.Este desagradable problema se puede resolver utilizando ED o EDMK para las instrucciones de desembalaje, pero el empaquetado de una gran cantidad desembalada tendrá que hacerse mediante una secuencia de instrucciones no muy simple. Se han agregado nuevas instrucciones a 390 sistemas para abordar este problema. Curiosamente, las instrucciones de empaque y desempaque funcionan con cualquier dato binario, no solo con decimales.
BAL tiene instrucciones únicas especiales que le permiten convertir un número binario a decimal empaquetado y viceversa de una sola vez. Para un número decimal en estas instrucciones, siempre se asignan 8 bytes, es decir, 15 dígitos y un signo. Sin embargo, el registro de 32 bits solo es suficiente para representar un número con signo correspondiente a un número decimal de 9 dígitos, por lo que no todos los números decimales en el formato BAL correcto pueden convertirse a binarios en un solo comando. Para los sistemas Z, existen instrucciones ampliadas para tales conversiones.
Las instrucciones de salto en BAL difieren en que, por regla general, están emparejadas (la dirección de salto se puede establecer tanto explícitamente como por el contenido del registro); en muchas otras arquitecturas, los saltos a lo largo del contenido del registro son solo para saltos incondicionales. Por cierto, no hay saltos incondicionales en BAL, se implementan estableciendo una condición siempre verdadera, que es similar a la arquitectura ARM. La ramificación condicional en BAL, como se señaló, tiene una sintaxis única. Considere, por ejemplo, la instrucción
BT 9,address, lo que significa dar un salto si se cumplen las condiciones 0 y 3, pero las condiciones después de diferentes comandos significan cosas diferentes. Por ejemplo, después de una adición firmada, estas condiciones significan "el resultado es 0 o se produjo un desbordamiento", y después de una adición sin firmar, "el resultado es 0 y no hubo acarreo, o el resultado no es 0 y hubo un acarreo". A pesar de lo engorroso y algo redundante, debe admitirse que tal sistema para trabajar con condiciones para transiciones es probablemente el más flexible de todos los conocidos. El nueve en el comando del ejemplo se usa en la representación binaria 1001, es decir, establece los números de bit; el sistema mismo codifica todas las combinaciones de condiciones con 4 bits también se usa en ARM. Además de los saltos condicionales, BAL también tiene contrasaltos con decremento, aproximadamente lo mismo que en los ensambladores Z80, x86, 68k, PDP-11, ... Pero BAL también tiene dos instrucciones para saltos completamente únicas,que, dependiendo del número de uno de los registros-operandos, puede ser de tres o cuatro direcciones. En estos comandos únicos, se suman dos registros y la suma resultante se compara con el contenido de otro registro, y el resultado de esta comparación es determinar si saltar o no. Se cree que estas instrucciones inusuales son útiles para trabajar con tablas de salto.
Como ya se señaló, la llamada de subrutinas en BAL se implementa sin usar la pila, simplemente almacenando la dirección de retorno en un registro. Sin embargo, las instrucciones BAL para tales llamadas, una de las cuales también se llama BAL, preservan no solo la dirección de retorno, sino también parte del registro de estado, en particular, las banderas de condición, la longitud de la instrucción actual e incluso una máscara para excepciones opcionales, por ejemplo, para números enteros o decimales. desbordamientos: esto ya se mencionó anteriormente. Un almacenamiento extendido de información tan inusual se debe al hecho de que el contador de instrucciones en la arquitectura del mainframe es la parte superior de la palabra de estado de la máquina y las instrucciones para llamar a subrutinas conservan mecánicamente su parte superior. No hay comandos especiales para regresar de las subrutinas, debe usar el salto habitual a la dirección en el registro.En 390 sistemas, en relación con la transición a la arquitectura de 31 bits, han aparecido nuevas instrucciones para llamar e incluso regresar de subrutinas. Las nuevas instrucciones permiten el uso flexible de códigos que se ejecutan en diferentes modos en un programa.
Para llamar rápidamente a subrutinas de un solo comando, BAL tiene una instrucción EX única que ejecuta la instrucción en una dirección determinada y pasa a la siguiente instrucción. La instrucción EX puede modificar la instrucción llamada, lo que le permite usar cualquier registro deseado en la instrucción llamada, o establecer parámetros para la transferencia masiva de bytes. Una instrucción similar, pero más simple, también se encuentra en el sistema de comando TMS9900.
Inicialmente, BAL no tenía transiciones reubicables relativas como el Z80 o el x86. Solo se agregaron a 390 sistemas.
Los comandos SPM, TM, TS, STCK y STPT también son algo inusuales. El primero de ellos permite que un comando establezca todos los indicadores de operación y la máscara de excepción opcional. El comando TM le permite verificar un grupo de bits e identificar tres casos: todos ceros, todos unos, una mezcla de ceros y unos. Esta verificación no se puede realizar con un comando en otras arquitecturas. Sin embargo, TM solo funciona con bytes individuales en la memoria. TS se utiliza cuando se trabaja con varios procesadores; existe un comando similar para 68k. La instrucción STCK lee el valor del temporizador externo (!) Y la instrucción STPT lee el valor del temporizador interno integrado en el circuito del procesador. Extraño, pero STPT tiene privilegios, pero STCK no.
También vale la pena mencionar las instrucciones CS y CDS, que están destinadas a apoyar el trabajo de multiprocesamiento. Se han implementado para 370 sistemas, es decir, están disponibles desde principios de los 70. En x86, el análogo de CS, la instrucción CMPXCHG, se implementó no antes de 1987, y el análogo de CDS, la instrucción CMPXCHG8B, ¡solo se implementó en 1994!
A partir de 370 sistemas, se introduce el comando de autoidentificación del sistema STIDP, es privilegiado y poco informativo. Para x86, este comando se ha hecho mucho más poderoso. También puede observar aquí que el IBM 4361 en LCM permite que cualquier usuario ejecute STIDP. Obviamente, esta es una emulación activada por excepción.
Los cuatro modos BAL direccionables especifican dos operandos para la instrucción, el quinto modo especifica comandos de tres direcciones. Sin embargo, ignorar parte de la información le permite tener comandos de unidifusión, y el uso de información implícita le permite tener comandos de cuatro direcciones. Cuando se utiliza en el direccionamiento, el registro 0 tiene un papel especial: simplemente se ignora allí; esto le permite ignorar la base y el índice al calcular la dirección. Todas las instrucciones BAL son estrictamente de 2, 4 o 6 bytes. Parece un 68000 o PDP-11, pero no x86, VAX o ARM.
Se agregaron varios modos de direccionamiento más al sistema 390, lo que elevó su número a 18. El número de instrucciones también ha aumentado de manera significativa, entre las nuevas instrucciones hay incluso algunas que admiten Unicode: ¡todavía no existe tal cosa para x86! Entre las nuevas instrucciones para 390 sistemas, hay otras únicas. Se agregaron varios modos de direccionamiento más al sistema Z, y el número total de comandos para el Z moderno es muy grande y probablemente incluso más que el número de comandos para el x86-64 moderno.
En los sistemas 360, 370 y 390, las compensaciones al acceder a los datos en la memoria, como en ARM, son de 12 bits, es decir, no más de 4095, lo cual no es muy conveniente, en códigos grandes puede haber escasez de registros para la base. En x86, este desplazamiento es de 16 bits, lo que, por supuesto, es mucho más conveniente. Pero el sistema Z agregó soporte para el direccionamiento de compensación de 20 bits, que por supuesto es aún mejor. Sin embargo, vale la pena señalar que en x86-64 o incluso 68020 el desplazamiento puede ser de 32 bits. Como se señaló, los sistemas anteriores a 390, como ARM, no tenían la capacidad de usar grandes constantes al trabajar con registros. La arquitectura x86 es mucho más flexible aquí. Por lo tanto, cuando se usa ensamblador con un sistema 360 o 370, a menudo es necesario usar literales, pseudoconstantes, que es algo más lento.
En términos de rendimiento, los sistemas compatibles con IBM / 360 siempre han tenido buenos indicadores. Mis experimentos con 4361-1, en particular en el proyectolos cálculos del número π por el algoritmo del obturador mostraron tiempos muy buenos. Las instrucciones 4361-1 se ejecutan prácticamente sin demoras como ARM u otros procesadores modernos. Sin embargo, debido a un sistema de instrucción algo incómodo heredado de los años 60, en particular, debido a la falta de división por un divisor de 16 bits, el resultado en términos de eficiencia de la electrónica del procesador resultó ser del nivel 80186. Esto es aproximadamente un 80% peor que el resultado, mostrado por el entonces mejor ordenador VAX, el Modelo 785. Sin embargo, el mainframe en LCM claramente no es el mejor entre los mainframes de IBM disponibles entonces. También es pertinente señalar aquí que los mainframes usaban canales, procesadores especializados que hacían E / S muy rápido, mucho más rápido que la mayoría de las computadoras modernas.
Como estudiante, trabajé con un clon doméstico de IBM / 370, EC-1045, en 1987 a través del modo por lotes y en 1989 a través del diálogo. Para el modo por lotes, fue necesario preparar tarjetas perforadas. En ese momento ya usaba una computadora en casa y, por lo tanto, el uso de tarjetas perforadas arcaicas no dejó la mejor impresión. Pero el modo interactivo no estaba mal, solo que a menudo se rompía, con una gran cantidad de usuarios. ¡Por lo tanto, algunos estudiantes llegaron a trabajar a las 4 de la mañana! Desde entonces, ya no he podido lidiar con mainframes, solo recientemente decidí lidiar con esta tecnología histórica para la historia de las computadoras a través de la emulación.
La clonación de IBM 360 fue muy popular. Los clones se fabricaron en Inglaterra, Alemania, Japón y otras empresas de Estados Unidos. En la URSS, esta clonación adquirió una connotación muy dramática. En aras de esta clonación, se retiraron casi todos los desarrollos domésticos en el campo de la TI, algunos de los cuales fueron muy prometedores. En particular, se cerró el tema de las computadoras de los Urales , sobre el que el famoso informático Charles Simonyi luego habló con calidez . El proyecto BESM-10 también se cerró, aunque las máquinas de la clase BESM-6 anterior eran comparables a la IBM 360 en términos de velocidad. Además, por el bien de esta clonación, se frustró un contrato casi concluido con ICL, quizás con este contrato la industria británica de TI habría adquirido una nueva dinámica y no habría declinado. Solo supercomputadorasElbrus , posiblemente debido a sus vínculos con la industria de la defensa, sobrevivió a la "Invasión Clon", que Dijkstra llamó la mayor victoria de Estados Unidos en la Guerra Fría.
Como recuerdan las personas que trabajaron con mainframes en la URSS, los clones domésticos se distinguían por una confiabilidad extremadamente baja y requerían atención constante por parte del personal de servicio. Mientras que los mainframes estadounidenses originales de IBM eran algunas de las computadoras más confiables de su tiempo. En los clones soviéticos, a veces se colocaron más de una docena (típicamente más de 5) kilogramos de metales preciosos, oro, platino, paladio y plata, pero esto no ayudó a corregir la situación con confiabilidad. Debido a la gran cantidad de valores altamente líquidos, es difícil imaginar que un clon doméstico en funcionamiento pueda sobrevivir en algún lugar.
Curiosamente, el principal desarrollador del IBM 360 dejó IBM y fundó Amdahl, que durante más de dos décadas se ha especializado en la producción de sistemas que son compatibles con los mainframes de IBM y al mismo tiempo son algo superiores en velocidad y confiabilidad a precios más bajos. Como resultado, debido a los grandes cambios en el mercado de mainframe, Amdahl, como ICL, pasó a formar parte de la corporación japonesa Fujitsu.
Además de las computadoras de la arquitectura IBM / 360, había otros mainframes. En los años 60, los fabricantes estadounidenses de mainframe recibieron extraoficialmente el nombre sonoro de Blancanieves y los siete enanitos. Probablemente sea fácil adivinar que Blancanieves era IBM. También se produjeron mainframes de arquitecturas originales en otros países. La arquitectura británica ICL 1900 merece una mención especial.
Como ya escribí, logré establecer una configuración de trabajo para VM / CMS 6. Sin embargo, resultó que el editor XEDIT no está disponible gratuitamente, y una EDIT simple es demasiado peculiar e inconveniente, por lo que debe editar los textos en el host. También se descubrió que no estaba disponible un programa estándar para transferir archivos desde el emulador de terminal al mainframe y viceversa, lo que requería el uso de tarjetas perforadas virtuales para dicha transferencia. Otra sorpresa desagradable surgió en relación con la depuración. ¡El comando DEBUG no admite pasos! Si bien esa posibilidad era incluso para el depurador DDT para el procesador 8080. También es sorprendente, aunque menos crítico, que DEBUG no sepa cómo realizar el desmontaje, que a menudo estaba integrado incluso en los monitores más simples de los procesadores de los 70.Los caracteres de control de fin de línea y de ajuste de línea larga no son compatibles en el nivel bajo en CMS. Por tanto, al imprimir desde programas en lenguaje ensamblador, es necesario formatear las líneas manualmente para que no desaparezcan más allá del borde derecho de la pantalla, y también cuidar de llenar la última línea con espacios de acabado. También es inusual la falta de desplazamiento vertical automático.
Aquellos que quieran trabajar con mainframes por primera vez deben tener en cuenta que los mainframes son un ecosistema enorme, donde muchos conceptos familiares pueden tener una interpretación diferente. Por ejemplo, el concepto simple de archivo no existe. Uno de los atributos clave del archivo es el tamaño del registro, no hay nada como esto para los archivos de Linux o Microsoft Windows. Los archivos en sí difieren en los métodos de acceso a ellos y se han escrito y posiblemente libros no delgados sobre esto. También es inusual que en CMS el nombre del disco se escriba al final del nombre completo del archivo, y el nombre, la extensión y el disco estén separados por espacios, y el nombre del disco en sí se denomine modo de archivo por alguna razón. También me gustaría resolver el MVS multitarea , que yo sepa en la URSS, nunca llegaron a hacerlo.
En general, es algo inesperado que algunos sistemas operativos conocidos que se usaban en computadoras muy costosas no admitieran trabajar con directorios de archivos, lo que los igualaba con los primeros y primitivos sistemas operativos para microcomputadoras, por ejemplo, CP / M o Commodore DOS. No es una coincidencia que CMS a veces se llamara CP / M para mainframes. Sorprendentemente, hasta donde yo sé, el soporte para directorios en el CMS nunca se introdujo, aunque la última versión del sistema se remonta a 2018. Por alguna razón, antes de los años 80, trabajar con directorios para computadoras costosas solía tener un soporte deficiente. Por ejemplo, no existía tal soporte en DEC RT-11 e incluso uno de los mejores sistemas operativos para PDP-11, RSX-11, solo admite directorios de dos niveles. El sistema operativo de IBM más popular hasta la década de 2000 fue MVS (1974) e incluso aquí los catálogos se hicieron solo parcialmente, como en Apple MFS (1984). Aunque en Unix (1973), MS-DOS (desde 1983) o incluso Apple ProDOS de 8 bits (1983), esto estuvo bien desde el principio. El manejo de archivos más avanzado se ofreció en VAX / VMS (1977), donde además de los directorios hay incluso soporte integrado para el control de versiones de archivos.
Curiosamente, el lenguaje de secuencias de comandos para CMS, MVS y algunos otros sistemas operativos de IBM, REXX , se ha convertido en una versión abreviada del lenguaje de archivos por lotes para Commodore Amiga.
El software de mainframe suele ser de dos colores. Los terminales de color se utilizaron con relativa poca frecuencia y, por lo tanto, hay pocos programas de color. También hay pocos programas con gráficos dinámicos; las actualizaciones frecuentes de la pantalla provocan un parpadeo notable y desagradable.
Demostración dinámica, ejecutada en el emulador IBM 4381 en LCM, terminal 3270-3
En conclusión, no puedo evitar expresar mi admiración por las tecnologías de IBM. Siempre se han distinguido por su originalidad única y alto nivel. Me gustaría destacar especialmente la muy buena calidad de la documentación que, incluso para los sistemas modernos, es de dominio público. IBM está demostrando un tremendo dinamismo en el desarrollo de tecnología a pesar de que es una de las empresas más grandes del mundo. En términos de número de empleados, es casi igual al de Microsoft, Google e Intel juntos.
El tema del mainframe es enorme. Por supuesto, pude escribir solo una pequeña parte de lo que puede contener. Estaría muy agradecido por las aclaraciones y la información adicional.
Este material también está disponible en inglés .