Cette partie se concentre sur la comparaison du langage machine des mainframes avec d'autres systèmes qui étaient populaires entre les années 70 et 90. Ce sont principalement x86, 68k, VAX et ARM. Les systèmes 390 et, en particulier, Z sont considérés comme très fragmentaires - l'accent principal est mis sur le système 370.
Les premiers 360 systèmes ont commencé à être expédiés aux clients en 1965, et les 370 systèmes plus avancés à partir de 1970. IBM maintient la compatibilité logicielle avec ces systèmes à ce jour! Étonnamment, avant 390 systèmes, expédiés, comme vous pouvez le deviner depuis 1990, les mainframes fonctionnaient avec des adresses 24 bits, c'est-à-dire qu'ils ne pouvaient pas adresser plus de 16 mégaoctets de mémoire, le même que, par exemple, 68000, publié en 1979, ou 65816ou 32016, sorti en 1982. VAX supporte nativement l'adressage 32 bits. Les processeurs 68020 ou 80386 populaires, apparus au milieu des années 1980, prenaient également en charge les adresses 32 bits. En fait, 16 Mo de mémoire pour les meilleurs systèmes de la seconde moitié des années 80 ne suffisaient déjà pas. Cependant, depuis 1983, IBM produit des ordinateurs compatibles 370 qui pourraient, en tant qu'extension, utiliser 31 chiffres d'adresse, ce qui élimine le problème de mémoire pour de meilleurs ordinateurs. De manière inhabituelle et unique, ces extensions et 390 systèmes utilisaient une adresse 31 bits plutôt qu'une adresse 32 bits complète. En 2000, IBM a annoncé le premier système Z à utiliser l'adressage et les données 64 bits. Les systèmes Z utilisent des puces de processeur depuis 2008. Depuis 2007, ils tentent de combiner l'architecture Z en une seule puce avec l'architecture POWER, mais jusqu'ici sans succès. Jusqu'à présent, seul Intel a réussi à combiner CISC et RISC en une seule puce - Pentium Pro en 1995 est devenu la première puce du genre.
IBM System / 370-145 avec un lecteur de bande 2401 et une imprimante au lieu d'un écran, 1971. Il peut être surprenant qu'il n'y ait pas d'affichage dans ce système très coûteux malgré le fait que les téléviseurs sont produits en masse depuis plus de 20 ans.
En passant, certaines autorités pensent que le premier ordinateur personnel en série était IBM 5100 , en production depuis 1975, qui pouvait exécuter des instructions système 360 via un émulateur matériel. Des versions améliorées de celui-ci ont été produites jusqu'au milieu des années 1980. Mais le Wang 2200 était plutôt le premier . À des prix (environ 10 000 $), ces premiers ordinateurs personnels n'étaient clairement pas destinés à un usage domestique.
IBM 5100, variante APL
Avec l'avènement de l'architecture IBM PC, qui, il s'est avéré, a déterminé la direction principale du développement de la technologie informatique pendant des décennies, IBM a essayé en 1983 de combiner presque toutes les meilleures technologies informatiques de l'époque dans un seul produit PC XT / 370: ses 370 systèmes, IBM PC XT, Motorola 68000 et Intel 8087. Ce XT / 370 pourrait être utilisé comme terminal intelligent pour travailler avec un mainframe, comme un IBM XT normal, ou pour exécuter directement un logiciel mainframe. Fait intéressant, le XT / 370 a ajouté la prise en charge de l'utilisation de la mémoire virtuelle, qui nécessitait deux 68000. En 1984, avec l'avènement du PC AT, une version améliorée de l'AT / 370 «mainframe personnelle» a été publiée, qui était environ deux fois plus rapide que le XT en mode mainframe. / 370. L'histoire de ces systèmes ne s'est pas arrêtée là, puisque des produits similaires ont été produits dans les années 90, correspondant à 390 systèmes.Autant que je sache, cela n'a pas été fait pour les systèmes Z.
IBM utilise un modèle commercial assez inhabituel pour ses mainframes, dans lesquels les ordinateurs ne sont pas vendus mais loués. L'un des avantages d'un tel modèle est qu'il garantit une mise à niveau constante de l'équipement, l'équipement obsolète est automatiquement remplacé par un équipement mis à jour de la classe correspondante. Ce modèle présente également des inconvénients. Par exemple, un inconvénient particulièrement perceptible pour ceux qui étudient l'histoire de la technologie informatique est le fait que les ordinateurs usagés sont presque toujours éliminés et qu'il est donc presque impossible de les trouver dans un musée.
Surpris de trouver un système IBM 4361 en direct dans LCM! Mais il y a des raisons de croire que ce n'est peut-être pas du vrai fer. Pour une raison quelconque, les visiteurs du musée n'ont pas accès à cet ordinateur. On ne sait pas non plus quel modèle est censé y être présenté, et ce malgré le fait que les autres ordinateurs du musée sont identifiés de manière très précise. Parmi les 4361 systèmes, trois modèles 3, 4 et 5 sont connus et le modèle 3 est apparu plus tard que les modèles 4 et 5. Mais le système du musée s'identifie lui-même comme modèle 1. Il est possible qu'il s'agisse d'un prototype. Cependant, le personnel du musée n'a pas répondu à une question directe sur l'aide à l'identification, et ce malgré le fait qu'ils répondent assez rapidement à d'autres questions souvent assez difficiles. Certaines caractéristiques du moment de l'exécution des codes donnent des raisons, bien que pas absolument solides, de supposer que l'émulateur est très probablement connecté au réseau. En été au musée, en lien avec covid,évidemment basculé vers un émulateur ... Il y a encore une chance d'accéder aux mainframes de fer via le réseauHNET , mais je n'ai pas encore réussi.
Mais quoi qu'il en soit, tout le monde peut se connecter et essayer de travailler de la même manière que les spécialistes bien payés travaillent depuis le milieu des années 70. Les prix étaient tels qu'aujourd'hui c'est difficile à croire. Par exemple, une heure de temps informatique coûtait plus de 20 $ au milieu des années 80, et vous deviez encore payer un supplément pour l'espace disque! Certes, nous parlons de la durée de fonctionnement du mainframe, et non du terminal par lequel le travail se déroulait. Ainsi, par exemple, lors de l'édition d'un texte d'une heure de travail réel, il fallait rarement 5 minutes pour payer. Les prix des mainframes eux-mêmes étaient également fantastiques. Par exemple, les employés d'Intel se souviennent qu'au début des années 80, ils n'avaient qu'un seul mainframe pour travailler. Sa performance était de 10 MIPS, et le prix était d'environ 20 millions de dollars à l'époque, ce qui était trois fois plus lourd qu'aujourd'hui! Intéressant,qu'Intel préférait ces ordinateurs aux systèmes VAX moins chers. Maintenant mêmeUn Raspberry Pi a la taille d'une pilule et son prix est de quelques dollars et peut facilement fournir plus de 1000 MIPS. À propos, sur un Raspberry Pi ou presque n'importe quel ordinateur moderne, vous pouvez exécuter un émulateur IBM / 370, qui fonctionnera beaucoup plus rapidement que n'importe quel système IBM des années 80 ou même 90. Cependant, l'émulateur doit être configuré et tous les programmes utiles pour IBM / 370 ne sont pas disponibles gratuitement, donc l'accès gratuit à un système bien réglé est souvent le meilleur moyen de contourner le mainframe. Étonnamment, de tels programmes d'accès, les émulateurs de terminaux 3270, sont disponibles même sur les téléphones portables! Au fait, j'ai réussi à configurer mon système VM / CMS sur l'émulateur Hercules et à gérer le transfert de fichiers, mais cela a pris au moins une semaine.
L'émulateur Hercules peut émuler les systèmes IBM / 390 et IBM / Z ultérieurs, mais en raison de problèmes de licence logicielle, c'est beaucoup plus difficile à faire. Pour illustrer ces problèmes, je citerai un cas célèbre où IBM a insisté pour supprimer la section Emulation d'un livre déjà publié! Dans les versions électroniques modernes de ce livre, cette section n'existe pas, elle ne peut être trouvée que dans l'édition imprimée ou sous forme de fichier séparé sur les sites dédiés aux logiciels libres. Le fait est que l'émulation sur les PC ordinaires depuis le début des années 2000 pourrait être sensiblement plus rapide que l'exécution sur des mainframes beaucoup plus chers. IBM a donc dû modifier ses licences logicielles afin qu'elles ne puissent être utilisées légalement que sur du matériel acheté auprès d'IBM. Bien sûr, nous ne disons pas que les émulateurs sont plus rapides que les meilleurs mainframes,ils affichent seulement un rapport performances / coût nettement meilleur.
Une façon de travailler avec les systèmes Z ou 390 consiste à installer Linux sur un émulateur de ces systèmes. Pour 390 et Z, au moins les distributions Ubuntu et Debian sont disponibles. Il convient de noter ici que le développement rapide de Linux est en grande partie dû à un support important d'IBM. En particulier, IBM a investi en 2001 un milliard de dollars dans le développement de Linux.
Examinons maintenant les caractéristiques du langage machine des systèmes compatibles avec 360. L'assembleur de base de ces systèmes est appelé BAL - Basic Assembly Language. Étonnamment, selon les rumeurs sur IBM, le langage d'assemblage est toujours l'un des principaux langages de programmation de travail là-bas.
L'assembleur des mainframes en question présente un certain nombre de caractéristiques archaïques qui étaient déjà absentes d'autres architectures bien connues apparues plus tard. Par exemple, il s'agit du fait que les mnémoniques BAL déterminent le type d'arguments. Considérez les instructions assembleur x86 comme exemple
MOV EAX,EBXet MOV EAX,address- les deux utilisent le mnémonique MOV. Pour BAL, dans de tels cas, différents mnémoniques LR et L sont utilisés dans les commandes, respectivement, LR 0,1etL 0,address... Cependant, des mnémoniques différentes similaires permettent d'utiliser des nombres pour nommer les registres, bien que généralement les macros R0, R1, ... au lieu des nombres 0, 1, ... soient la première chose qui est définie dans les packages de macros pour faciliter la programmation. Un autre archaïsme est l'utilisation de sauts d'étiquettes dans les constructions de compilation conditionnelle, bien qu'à mon humble avis, cela soit parfois plus pratique que les structures de bloc. Mais l'archaïsme le plus connu est l'utilisation de l'encodage EBCDIC pour travailler avec des informations symboliques. Dans ce codage, étrange même pour hier, les lettres de l'alphabet anglais ne sont pas encodées dans une rangée, par exemple, la lettre I a un code 201, et le prochain J est 209! Cet encodage provient de technologies permettant de travailler avec des cartes perforées apparues à l'époque pré-informatique. System 360 prend également en charge ASCII dans le matériel, mais dans sa version ancienne et oubliée depuis longtemps,où le caractère du chiffre 0 a le code 80, pas 48 comme c'est le cas actuellement. Autant que je sache, ASCII avec les mainframes IBM était préférable de ne même pas essayer de l'utiliser. Le support ASCII a déjà été supprimé dans 370 systèmes, mais introduit à un nouveau niveau dans 390 systèmes. Certains mnémoniques BAL sont frappants par leur super-brièveté et même leur non-némonicité, par exemple, N signifie AND, O - OR, X - XOR, A - ADD, S - SUBTRACT, M - MULTIPLIER, ...
L'assembleur BAL vous permet de travailler avec trois types de données de base: les nombres binaires, décimaux et réels. Les systèmes 390 utilisent un autre type spécial pour travailler avec des nombres réels. Certains systèmes Z peuvent également utiliser des données totalement uniques telles que des nombres réels décimaux. Les instructions pour travailler avec chaque type forment une classe d'instructions spéciale et plutôt isolée. En règle générale, à quelques exceptions près, tous les systèmes compatibles 360 prennent en charge les instructions arithmétiques décimales et réelles. Comme vous le savez, pour les architectures x86 ou 68k, la prise en charge du travail avec des nombres réels n'apparaissait pas immédiatement et pendant longtemps était une option facultative, et travailler avec des nombres décimaux n'était pas quelque chose de complètement séparé de l'arithmétique binaire - c'était plutôt une extension.
Pour travailler avec des nombres réels et binaires, différents ensembles de registres sont utilisés, et pour travailler avec des nombres décimaux, les registres ne sont pas du tout utilisés. Le système 370 fournit 16 registres 32 bits à usage général pour les entiers binaires, le compteur de programme faisant partie du mot d'état du processeur. Il n'y a pas de pile séparée, elle peut être organisée à l'aide de n'importe quel registre - c'est ainsi que le travail avec la pile a ensuite été implémenté dans ARM. L'appel du sous-programme se fait également comme dans ARM, via le registre de lien. Tous les registres sont presque toujours interchangeables, les exceptions sont très rares. Si vous comparez le système de registres binaires BAL avec l'architecture VAX concurrente, vous remarquerez que le VAX a un registre de moins. Ceci est également vrai pour ARM.
La structure des opérandes dans les instructions semblera assez familière à ceux qui connaissent l'assembleur x86. Pour les nombres binaires, les opérandes ont une structure registre-registre ou registre-mémoire, et pour ce dernier cas, les valeurs à extension signée 32 bits et 16 bits peuvent être chargées à partir de la mémoire. Par exemple, un analogue de l'instruction x86
ADD EAX,EBXserait 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). Cependant, les systèmes 360 et même leur développement ultérieur ne savent pas comment travailler avec la mise à l'échelle, par exemple, vous ADD EAX,address[8*EBX]ne pouvez pas écrire dans BAL avec une seule commande. En revanche, x86 ne sait pas comment travailler avec des extensions signées 16 bits, par exemple la commande BALAH 0,address, ce qui signifie prendre un nombre signé 16 bits de la mémoire et l'ajouter au registre 0, sur x86, il faudra deux instructions pour l'implémenter.
Une caractéristique rare de BAL est qu'il existe des instructions séparées pour l'addition et la soustraction pour les nombres signés et non signés, et les opérations non signées dans BAL sont appelées booléens. Cette bizarrerie est causée par l'absence de drapeaux dans l'architecture 360 qui sont familiers à la plupart des autres architectures. Au lieu de cela, seuls deux bits sont utilisés, qui sont définis différemment par des instructions différentes! La seule différence entre les opérations signées et non signées est qu'elles définissent différemment les deux bits d'attribut mentionnés. Pour les opérations signées sur celles-ci, vous pouvez savoir si le résultat était nul, s'il était positif ou négatif, si un dépassement s'est produit et pour les opérations non signées, si le résultat était nul et si un transfert ou un prêt a eu lieu. Les instructions de branchement conditionnelles autorisent les 16 sous-ensembles de cas possibles avec 2 bits.En raison de ce travail inhabituel avec les panneaux d'exploitation aujourd'hui, les instructions de branchement conditionnelles sont difficiles à comprendre rapidement. Bien que les extensions BAL ajoutent généralement des macros assez faciles à lire pour les sauts conditionnels, où vous n'avez pas besoin d'analyser chacun des 4 bits. Ici, par souci d'équité, vous pouvez voir qu'il existe des commandes séparées pour l'addition et la soustraction signées et non signées, par exemple, dans l'architecture MIPS, où il n'y a pas de drapeaux du tout!par exemple, dans l'architecture MIPS, où il n'y a aucun drapeau!par exemple, dans l'architecture MIPS, où il n'y a aucun drapeau!
Une autre caractéristique rare réside dans les commandes séparées pour les comparaisons signées et non signées. J'en ai rencontré des similaires non seulement chez MIPS, mais aussi chez MicroBlaze. Dans ce dernier, en passant, le transfert est le seul drapeau pris en charge des drapeaux d'opération.
Dans les systèmes compatibles avec IBM 360, il n'y a pas d'opérations arithmétiques avec l'indicateur de retenue, donc si nous devons travailler avec des nombres binaires, par exemple, en nombres de 128 bits, nous devons alors vérifier le signe de retenue après avoir effectué les premières opérations de 32 bits pour organiser leur addition ou soustraction. et effectuez la transition si nécessaire. C'est bien sûr très encombrant par rapport à x86, ARM, 68k ou même 6502, mais sur MIPS beaucoup plus tard, c'est encore plus encombrant. Le travail normal avec le transfert a été effectué uniquement dans le système Z.
Il n'y a pas de décalages cycliques dans BAL, mais les décalages non cycliques, comme dans x86, peuvent être simples ou doubles. Cependant, BAL a des instructions de décalage séparées pour les nombres non signés et signés, seuls ces derniers définissent des indicateurs de drapeau. De toute évidence, les résultats des décalages à gauche pour les deux cas ne diffèrent que par les indicateurs. Spins ajoutés uniquement à 390 systèmes.
Parmi les commandes de chargement de registres dans BAL, il y en a probablement des uniques. Vous pouvez charger le module d'un entier, d'une négation de ce module ou d'un nombre avec un signe modifié - quelque chose de similaire à distance que je n'ai rencontré que dans l'architecture ARM. Il convient de noter ici que toute l'architecture de 360 a tendance à signer l'arithmétique, et l'arithmétique non signée dans cette architecture est plutôt secondaire. Initialement, BAL n'avait pas de division et de multiplication non signées, ils ont été ajoutés uniquement au système 390. Lorsque le registre est chargé, les indicateurs, ainsi que dans x86, ne changent pas, mais il existe une commande de démarrage spéciale qui définit les indicateurs - cela rappelle à nouveau ARM, où la définition des indicateurs peut Gouverner.
Toutes les opérations arithmétiques signées, y compris les décalages, peuvent lever une exception de dépassement de capacité. Le fait qu'une exception soit levée ou non est déterminé par un indicateur de masque spécial dans le registre d'état. Fait intéressant, la division binaire et la multiplication dans BAL n'affectent pas du tout les indicateurs - ici, vous pouvez rappeler x86, où la division ne gâte que les indicateurs.
Les opérations logiques au niveau du bit dans BAL sont représentées par l'ensemble habituel de ET, OU, OU exclusif, c'est-à-dire qu'il n'y a pas d'opération de négation distincte. Les opérations logiques peuvent avoir non seulement une structure registre-registre ou registre-mémoire, mais aussi «mémoire-constante» ou «mémoire-mémoire» - cette dernière méthode d'adressage est similaire à celle utilisée pour les nombres décimaux. L'adressage de type "constante de mémoire" n'est possible que pour le travail avec des octets. Evidemment, pour les opérations logiques, contrairement à l'arithmétique, l'utilisation de nombres 16 bits est impossible. Pour l'adressage mémoire à mémoire, vous pouvez travailler avec des données jusqu'à 256 octets! Il s'avère que nous avons trois types de données pour travailler avec des opérations logiques: octets, mots de 32 bits, séquences d'octets - et instructions spéciales pour chacun de ce type, ce qui est plutôt non universel.
Les opérations logiques dans BAL sont adjacentes aux opérations de transfert d'octets. En plus du transfert habituel jusqu'à 256 octets avec une seule commande, il existe également une instruction unique pour le transfert de tétrades d'octets. Vous ne pouvez envoyer que les moitiés supérieure ou inférieure des octets, tandis que les autres moitiés conservent leur valeur lors de la copie! Ces opérations étranges sont nécessaires pour prendre en charge les fonctionnalités BAL lorsque vous travaillez avec des informations de caractères et décimales. Il existe également des instructions de transfert et de comparaison pour 370 systèmes jusqu'à plus de 16 millions d'octets à la fois, qui peuvent être interrompus. De manière surprenante, les commandes lentes pour travailler avec des blocs jusqu'à 256 octets ne peuvent pas être interrompues, ce qui peut créer un retard désagréable en réponse à une demande d'interruption. Les commandes de transfert peuvent également être utilisées pour remplir la mémoire avec un octet spécifié.En plus du transfert de la mémoire vers la mémoire, vous pouvez également définir des octets individuels sur une valeur donnée. De toute évidence, les instructions de transfert d'octets, à part les nouvelles instructions pour 390 et Z, sont plus avancées pour x86.
Dans le registre, vous pouvez charger non seulement la valeur à l'adresse donnée, mais également l'adresse elle-même, comme dans les commandes LEA pour x86 ou 68k. Cette fonction vous permet également de charger directement la constante requise dans le registre, bien que sa valeur maximale ne puisse pas être supérieure à 4095. Elle vous permet également d'incrémenter le registre de pas plus de 4095. Mais la décrémentation du registre ne peut être effectuée que de 1. Un incrément et un décrément - ce sont des commandes d'adresse, donc elles ne changent pas les drapeaux. Vous pouvez charger des octets individuels et même des groupes d'octets d'un mot en mémoire dans le registre, par exemple, uniquement les premier et troisième octets - cela est possible pour toutes les autres architectures 32 bits connues de moi uniquement via une série de 4 commandes. De même, BAL autorise uniquement les parties d'un registre à être vidées en mémoire.
La série d'instructions BAL est très spécialisée - dans d'autres architectures, celles-ci sont implémentées par une série d'instructions plus simples. Par exemple, l'instruction TR vous permet de convertir une chaîne de caractères - un argument spécifie la chaîne à convertir et l'autre l'adresse de la table de conversion. Une variante spéciale de cette instruction, TRT, peut être utilisée pour balayer une chaîne donnée et sauter les caractères vides - c'est la fonctionnalité de l'appel strpos standard C. Les instructions ED et EDMK sont complètement uniques - elles ont la fonctionnalité du sprintf primitif! Cependant, presque toutes les opérations de chaîne ont une limitation de la longueur de chaîne maximale, pas plus de 255 octets, ce qui réduit considérablement leur puissance.
En BAL, il est difficile de travailler avec des valeurs non signées 16 bits en raison du manque de rotation ou de commandes de type SWAP. Avec 390 systèmes, ce problème s'est amélioré. Certaines instructions BAL sont obsolètes, par exemple l'instruction de décalage de quartet MVO a été remplacée par le SRP plus pratique. Pour les transferts de blocs et les comparaisons, il est préférable d'utiliser les nouvelles instructions, bien que du fait qu'elles utilisent un mode d'adressage différent, cela peut dans certains cas rares ne pas être optimal.
Il existe déjà des exemples des quatre modes d'adressage BAL de base. Il existe également un cinquième pour les commandes à trois adresses. Les modes tels que les modes VAX, 68k, PDP-11 ou même 6809 auto-incrémentation ou décrémentation ne sont pas disponibles en BAL. Il n'y a pas non plus de modes DIMM comme le VAX, le 68020 ou le PDP-11. Et, bien sûr, BAL, contrairement aux assembleurs VAX ou PDP-11, est complètement non orthogonal. BAL est le plus proche des assembleurs x86 et ARM, les architectures modernes les plus réussies. L'ordre des opérandes dans BAL de droite à gauche est le même que dans l'assembleur Intel pour x86 ou dans l'assembleur ARM et, par conséquent, pas comme VAX, PDP-11 ou 68k. Bien que l'ordre des octets dans les données dans BAL soit du majeur au mineur (MSB), ce qui diffère de x86, ARM ou VAX, il correspond à l'accepté pour 68k ou MIPS.
Les opérations avec des nombres décimaux sont implémentées dans BAL uniquement via l'adressage mémoire-mémoire. Les nombres décimaux peuvent être spécifiés par blocs de 16 octets maximum, ce qui permet d'utiliser des nombres jusqu'à 31 décimales. Cela correspond à la précision d'un nombre binaire de 107 bits. Ainsi, seuls les systèmes de programmation les plus modernes utilisant des entiers binaires peuvent gérer des valeurs plus importantes que 360 systèmes il y a près de 60 ans! Bien sûr, il est possible d'implémenter des nombres arbitrairement grands grâce à l'arithmétique binaire, mais pour une raison quelconque, jusqu'à récemment, il n'y avait pas de langages de programmation populaires prenant en charge des nombres plus grands que l'ancien système 360. Même maintenant, le support des entiers 128 bits pour x86 n'est généralement que des extensions non officielles, comme pour GCC.
Les nombres décimaux sur BAL sont représentés de manière unique, ils doivent stocker le signe - il n'y en a pas pour VAX, x86, 68k, ... De plus, le signe est stocké dans le dernier octet de la représentation numérique! Pour les nombres décimaux, BAL prend directement en charge toutes les opérations de base: addition, soustraction, multiplication et même division - cela ne se trouve pas non plus dans aucune autre architecture que je connaisse. De plus, BAL a des instructions pour copier, comparer et déplacer les nombres décimaux. Les instructions MVO et SRP susmentionnées sont conçues pour de tels changements. Les opérations ne peuvent être effectuées que sur des nombres décimaux emballés, mais pour les imprimer, ils doivent être décompressés, et pour représenter les chiffres non compressés en BAL, un signe est également nécessaire, qui dans ce cas ne prend pas de place, car il est placé dans la tétrade supérieure, ce qui nécessite un travail particulier avec ce cahier avant l'impression.Il est étrange que les opérations de mise en boîte et de déballage ne puissent fonctionner qu'avec 16 octets du nombre décimal décompressé, ce qui ne permet d'utiliser que des nombres de 15 bits. Ce problème désagréable peut être résolu en utilisant ED ou EDMK pour les instructions de déballage, mais l'emballage d'un grand nombre non emballé devra être fait par une séquence d'instructions pas très simple. De nouvelles instructions ont été ajoutées à 390 systèmes pour résoudre ce problème. Curieusement, les instructions d'emballage et de déballage fonctionnent avec toutes les données binaires, pas seulement les données décimales.Ce problème désagréable peut être résolu en utilisant ED ou EDMK pour les instructions de déballage, mais l'emballage d'un grand nombre non emballé devra être fait par une séquence d'instructions pas très simple. De nouvelles instructions ont été ajoutées à 390 systèmes pour résoudre ce problème. Curieusement, les instructions d'emballage et de déballage fonctionnent avec toutes les données binaires, pas seulement décimales.Ce problème désagréable peut être résolu en utilisant ED ou EDMK pour les instructions de déballage, mais l'emballage d'un grand nombre non emballé devra être fait par une séquence d'instructions pas très simple. De nouvelles instructions ont été ajoutées à 390 systèmes pour résoudre ce problème. Curieusement, les instructions d'emballage et de déballage fonctionnent avec toutes les données binaires, pas seulement décimales.
BAL a des instructions uniques spéciales qui vous permettent de convertir un nombre binaire en décimal compressé et vice versa en une seule fois. Pour un nombre décimal dans ces instructions, 8 octets sont toujours alloués, soit 15 chiffres et un signe. Cependant, le registre 32 bits suffit à représenter un nombre signé correspondant à un nombre décimal à 9 chiffres, de sorte que tous les nombres décimaux au format BAL correct ne peuvent pas être convertis en binaire en une seule commande. Pour les systèmes Z, il existe des instructions étendues pour de telles conversions.
Les instructions de saut dans BAL diffèrent en ce qu'elles sont, en règle générale, appariées - l'adresse de saut peut être définie à la fois explicitement et par le contenu du registre - dans de nombreuses autres architectures, les sauts le long du contenu du registre ne sont que des sauts inconditionnels. À propos, il n'y a pas de sauts inconditionnels dans BAL, ils sont implémentés en définissant une condition toujours vraie, qui est similaire à l'architecture ARM. Le branchement conditionnel dans BAL, comme indiqué, a une syntaxe unique. Considérez, par exemple, l'instruction
BT 9,address, ce qui signifie faire un saut si les conditions 0 et 3 sont remplies, mais les conditions après différentes commandes signifient des choses différentes. Par exemple, après une addition signée, ces conditions signifient «le résultat est 0 ou un dépassement est survenu», et après une addition non signée, «le résultat est 0 et il n'y a pas eu de report, ou le résultat n'est pas 0 et il y a eu report». Malgré la lourdeur et une certaine redondance, il faut admettre qu'un tel système de travail avec des conditions de transition est probablement le plus flexible de tous connu. Le neuf dans la commande de l'exemple est utilisé dans la représentation binaire 1001, c'est-à-dire qu'il définit les nombres de bits - le système lui-même codera toutes les combinaisons de conditions avec 4 bits est également utilisé dans ARM. En plus des sauts conditionnels dans BAL, il y a des contre-sauts avec un décrément, approximativement le même que dans les assembleurs Z80, x86, 68k, PDP-11, ... Mais BAL a aussi deux instructions complètement uniques pour les sauts,qui, selon le nombre de l'un des registres-opérandes, peut être à trois ou quatre adresses! Dans ces commandes uniques, deux registres sont additionnés et la somme résultante est comparée au contenu d'un autre registre, et le résultat de cette comparaison est de déterminer s'il faut sauter ou non. On pense que ces instructions inhabituelles sont utiles pour travailler avec des tables de saut.
Comme déjà noté, l'appel de sous-programmes dans BAL est implémenté sans utiliser la pile, en stockant simplement l'adresse de retour dans un registre. Cependant, les instructions BAL pour de tels appels, dont l'un est également appelé BAL, préserve non seulement l'adresse de retour, mais aussi une partie du registre d'état, en particulier, les indicateurs de condition, la longueur de l'instruction en cours, et même un masque pour les exceptions facultatives, par exemple, pour entier ou décimal débordements - cela a déjà été mentionné ci-dessus. Un tel stockage prolongé inhabituel d'informations est dû au fait que le compteur d'instructions dans l'architecture mainframe est la partie supérieure du mot d'état de la machine et les instructions pour appeler les sous-programmes conservent mécaniquement sa partie supérieure. Il n'y a pas de commandes spéciales pour le retour des sous-programmes, vous devez utiliser le saut habituel vers l'adresse dans le registre.Dans 390 systèmes, en lien avec le passage à l'architecture 31 bits, de nouvelles instructions pour appeler et même revenir des sous-programmes sont apparues. De nouvelles instructions permettent d'utiliser de manière flexible des codes exécutés dans différents modes dans un même programme.
Pour appeler rapidement des sous-programmes à commande unique, BAL a une instruction EX unique qui exécute l'instruction à une adresse donnée et passe à l'instruction suivante. L'instruction EX peut modifier l'instruction appelée, ce qui vous permet d'utiliser n'importe quel registre souhaité dans l'instruction appelée, ou de définir des paramètres pour le transfert en bloc d'octets. Une instruction similaire, mais plus simple, se trouve également dans le système de commande TMS9900.
Au départ, BAL n'avait pas de transitions relatives et déplaçables comme le Z80 ou le x86. Ils n'ont été ajoutés qu'à 390 systèmes.
Les commandes SPM, TM, TS, STCK et STPT sont également quelque peu inhabituelles. Le premier d'entre eux permet à une commande de définir tous les indicateurs d'opération et le masque d'exception facultatif. La commande TM vous permet de vérifier un groupe de bits et d'identifier trois cas: tous les zéros, tous les uns, un mélange de zéros et de uns. Cette vérification ne peut pas être effectuée par une seule commande dans d'autres architectures. Cependant, TM ne fonctionne qu'avec des octets individuels en mémoire. TS est utilisé lorsque vous travaillez avec plusieurs processeurs - il existe une commande similaire pour 68k. L'instruction STCK lit la valeur du temporisateur externe (!) Et l'instruction STPT lit la valeur du temporisateur interne intégré dans le circuit processeur. Étrange, mais STPT est privilégié, mais STCK ne l'est pas.
Il convient également de mentionner les instructions CS et CDS, qui sont conçues pour prendre en charge le travail multiprocesseur. Ils ont été mis en œuvre pour 370 systèmes, c'est-à-dire qu'ils sont disponibles depuis le début des années 70. Dans x86, l'analogue de CS, l'instruction CMPXCHG, a été implémenté au plus tôt en 1987, et l'analogue de CDS, l'instruction CMPXCHG8B, n'a été implémenté qu'en 1994!
A partir de 370 systèmes, la commande d'auto-identification du système STIDP est introduite, elle est privilégiée et peu informative. Pour x86, cette commande a été rendue beaucoup plus puissante. Vous pouvez également remarquer ici que l'IBM 4361 dans LCM permet à n'importe quel utilisateur d'exécuter STIDP. Il s'agit évidemment d'une émulation déclenchée par une exception.
Les quatre modes BAL adressables spécifient deux opérandes pour l'instruction, le cinquième mode spécifie des commandes à trois adresses. Cependant, ignorer certaines informations vous permet d'avoir des commandes de monodiffusion, et l'utilisation d'informations implicites vous permet d'avoir des commandes à quatre adresses. Lorsqu'il est utilisé pour l'adressage, le registre 0 a un rôle spécial: il y est simplement ignoré - cela vous permet d'ignorer la base et l'index lors du calcul de l'adresse. Toutes les instructions BAL sont strictement de 2, 4 ou 6 octets. Il ressemble à un 68000 ou PDP-11, mais pas à x86, VAX ou ARM.
Plusieurs modes d'adressage supplémentaires ont été ajoutés au système 390, portant leur nombre à 18. Le nombre d'instructions a également augmenté de manière assez significative, parmi les nouvelles instructions, il y en a même qui prennent en charge le travail avec Unicode - ce n'est toujours pas disponible pour x86! Parmi les nouvelles instructions pour 390 systèmes, il y en a d'autres uniques. Plusieurs modes d'adressage supplémentaires ont été ajoutés au système Z, et le nombre total de commandes pour le Z moderne est très grand et probablement même plus que le nombre de commandes pour le x86-64 moderne!
Dans les systèmes 360, 370 et 390, les décalages lors de l'accès aux données en mémoire, comme dans ARM, sont de 12 bits, c'est-à-dire pas plus de 4095, ce qui n'est pas très pratique - dans les gros codes, il peut y avoir une pénurie de registres pour la base. En x86, ce décalage est de 16 bits, ce qui, bien sûr, est beaucoup plus pratique. Mais le système Z a ajouté la prise en charge de l'adressage offset 20 bits, ce qui est bien sûr encore meilleur. Cependant, il convient de noter que dans x86-64 ou même 68020, le décalage peut être de 32 bits. Comme indiqué, les systèmes antérieurs à 390, comme ARM, n'avaient pas la capacité d'utiliser de grandes constantes lorsqu'ils travaillaient avec des registres. L'architecture x86 est ici beaucoup plus flexible. Par conséquent, lors de l'utilisation d'assembleur avec un système 360 ou 370, il était souvent nécessaire d'utiliser des littéraux, des pseudo-constantes, ce qui est un peu plus lent.
En termes de performances, les systèmes compatibles avec IBM / 360 ont toujours eu de bons indicateurs. Mes expériences avec 4361-1, notamment dans le projetles calculs du nombre π par l'algorithme de l'obturateur ont montré de très bons timings. Les instructions 4361-1 fonctionnent pratiquement sans décalage comme ARM ou d'autres processeurs modernes. Cependant, en raison d'un système d'instruction quelque peu maladroit hérité des années 60, notamment en raison de l'absence de division par un diviseur 16 bits, le résultat en termes d'efficacité de l'électronique du processeur était au niveau de 80186. C'est environ 80% pire que le résultat, montré par le meilleur ordinateur VAX de l'époque, le modèle 785. Cependant, le mainframe dans LCM n'est clairement pas le meilleur parmi les mainframes IBM disponibles alors. Il est également pertinent de noter ici que les mainframes utilisaient des canaux, des processeurs spécialisés qui rendaient les E / S très rapides, beaucoup plus rapides que la plupart des ordinateurs modernes.
En tant qu'étudiant, j'ai travaillé avec un clone domestique d'IBM / 370, EC-1045, en 1987 en mode batch, et en 1989 en dialogue. Pour le mode batch, il était nécessaire de préparer des cartes perforées. A cette époque, j'utilisais déjà un ordinateur personnel et donc l'utilisation de cartes perforées archaïques ne laissait pas la meilleure impression. Mais le mode interactif n'était pas mauvais, seulement il tombait souvent en panne, avec un grand nombre d'utilisateurs. Par conséquent, certains étudiants sont venus travailler à 4 heures du matin! Depuis, je n'ai plus été en mesure de m'occuper des mainframes, ce n'est que récemment que j'ai décidé de m'occuper de cette technologie marquante de l'histoire des ordinateurs par émulation.
Le clonage de l'IBM 360 était très populaire. Les clones ont été fabriqués en Angleterre, en Allemagne, au Japon et dans d'autres entreprises aux États-Unis. En URSS, ce clonage a pris une connotation très dramatique. Dans l'intérêt de ce clonage, presque tous les développements nationaux dans le domaine de l'informatique ont été abandonnés, dont certains étaient très prometteurs. En particulier, le sujet des ordinateurs de l' Oural a été clos , dont le célèbre informaticien Charles Simonyi a parlé plus tard avec chaleur . Le projet BESM-10 a également été clôturé, même si les machines de la classe BESM-6 précédente étaient comparables à l'IBM 360 en termes de vitesse. Aussi, dans l'intérêt de ce clonage, un contrat presque conclu avec ICL a été contrecarré, peut-être qu'avec ce contrat l'industrie informatique britannique aurait acquis une nouvelle dynamique et n'aurait pas décliné. Supercalculateurs uniquementElbrus , probablement en raison de ses liens avec l'industrie de la défense, a survécu à "l'invasion des clones", que Dijkstra a qualifié de plus grande victoire américaine de la guerre froide.
Comme le rappellent les personnes qui travaillaient avec des mainframes en URSS, les clones domestiques étaient extrêmement peu fiables et nécessitaient une attention constante de la part du personnel de service. Alors que les mainframes IBM américains d'origine étaient parmi les ordinateurs les plus fiables de leur temps. Dans les clones soviétiques, parfois plus d'une douzaine (généralement plus de 5) kilogrammes de métaux précieux, d'or, de platine, de palladium et d'argent ont été posés, mais cela n'a pas aidé à corriger la situation avec fiabilité. En raison d'un si grand nombre de valeurs hautement liquides, il est difficile d'imaginer qu'un clone domestique fonctionnel puisse survivre quelque part.
Fait intéressant, le principal développeur de l'IBM 360 a quitté IBM et a fondé Amdahl, qui s'est spécialisé pendant plus de deux décennies dans la production de systèmes compatibles avec les mainframes IBM et en même temps, ils sont quelque peu supérieurs en vitesse et en fiabilité à des prix inférieurs. En conséquence, en raison des grands changements sur le marché des mainframe, Amdahl, comme ICL, est devenu une partie de la société japonaise Fujitsu.
En plus des ordinateurs de l'architecture IBM / 360, il y avait d'autres mainframes. Dans les années 60, les fabricants de mainframe américains ont reçu officieusement le nom sonore de Blanche-Neige et les Sept Nains. Il est probablement facile de deviner que Snow White était IBM. Des mainframes d'architectures originales ont également été produites dans d'autres pays. L'architecture britannique ICL 1900 mérite une mention spéciale.
Comme je l'ai déjà écrit, j'ai réussi à mettre en place une configuration de travail pour VM / CMS 6. Cependant, il s'est avéré que l'éditeur XEDIT n'est pas disponible gratuitement, et un simple EDIT est trop étrange et peu pratique, vous devez donc éditer les textes sur l'hôte. Il a également été découvert qu'un programme standard pour transférer des fichiers de l'émulateur de terminal vers le mainframe et vice versa n'était pas disponible, ce qui nécessitait l'utilisation de cartes perforées virtuelles pour un tel transfert. Une autre surprise désagréable est survenue lors du débogage. La commande DEBUG ne prend pas en charge la progression! Alors qu'une telle possibilité était même pour le débogueur DDT pour le processeur 8080. Il est également surprenant, bien que moins critique, que DEBUG ne sache pas comment faire le démontage, qui était souvent intégré même dans les moniteurs les plus simples des processeurs des années 70.L'habillage de ligne longue et les caractères de contrôle de fin de ligne ne sont pas pris en charge au bas niveau sous CMS! Par conséquent, lors de l'impression à partir de programmes en langage assembleur, vous devez formater les lignes manuellement afin qu'elles ne disparaissent pas au-delà du bord droit de l'écran, et prendre également soin de remplir la dernière ligne avec des espaces de fin. L'absence de défilement vertical automatique est également inhabituelle.
Ceux qui souhaitent travailler avec des mainframes pour la première fois doivent garder à l'esprit que les mainframes sont un immense écosystème, où de nombreux concepts familiers peuvent avoir une interprétation différente. Par exemple, le simple concept de fichier n'existe pas. L'un des attributs clés du fichier est la taille de l'enregistrement, il n'y a rien de tel pour les fichiers Linux ou Microsoft Windows. Les fichiers eux-mêmes diffèrent dans les méthodes d'accès et il y a eu des livres écrits et peut-être non minces à ce sujet. Il est également inhabituel que dans CMS, le nom du disque soit écrit à la fin du nom complet du fichier, et que le nom, l'extension et le disque soient séparés par des espaces, et le nom du disque lui-même est appelé mode fichier pour une raison quelconque. Je voudrais également régler le MVS multitâche , pour autant que je sache en URSS, ils n'y sont jamais arrivés.
En général, il est quelque peu inattendu que certains systèmes d'exploitation bien connus utilisés sur des ordinateurs très coûteux ne prennent pas en charge le travail avec des répertoires de fichiers, ce qui les égalait avec les tout premiers systèmes d'exploitation primitifs pour micro-ordinateurs, par exemple, CP / M ou Commodore DOS. Ce n'est pas un hasard si CMS était parfois appelé CP / M pour les mainframes. Étonnamment, pour autant que je sache, la prise en charge des catalogues dans le CMS n'a jamais été introduite, bien que la dernière version du système remonte à 2018. Pour une raison quelconque, le travail avec des catalogues pour des ordinateurs coûteux était souvent mal pris en charge avant les années 80. Par exemple, il n'y avait pas un tel support dans DEC RT-11 et même l'un des meilleurs OS pour PDP-11, RSX-11, uniquement pris en charge les répertoires à deux niveaux. Le système d'exploitation IBM le plus populaire jusqu'aux années 2000 était MVS (1974) et même ici, les catalogues n'étaient que partiellement réalisés, comme dans Apple MFS (1984). Bien que sous Unix (1973), MS-DOS (depuis 1983) ou même Apple ProDOS 8 bits (1983), c'était bien depuis le début. La gestion de fichiers la plus avancée a été proposée dans VAX / VMS (1977), où, en plus des répertoires, il existe même un support intégré pour la gestion des versions de fichiers.
Fait intéressant, le langage de script pour CMS, MVS et certains autres systèmes d'exploitation IBM, REXX , est devenu une version abrégée du langage de fichier de commandes pour le Commodore Amiga.
Le logiciel mainframe est généralement bicolore. Les terminaux couleur ont été utilisés relativement rarement et il existe donc peu de programmes couleur. Il existe également peu de programmes avec des graphiques dynamiques; des rafraîchissements fréquents de l'écran entraînent un scintillement désagréable perceptible.
Démo dynamique, exécutée sur l'émulateur IBM 4381 dans LCM, terminal 3270-3
En conclusion, je ne peux m'empêcher d'exprimer mon admiration pour les technologies IBM. Ils se sont toujours distingués par leur originalité unique et leur haut niveau. Je voudrais particulièrement souligner la très bonne qualité de la documentation, qui est accessible au public même pour les systèmes modernes. IBM fait preuve d'un formidable dynamisme en matière de développement technologique, malgré le fait qu'elle soit l'une des plus grandes entreprises au monde. En termes de nombre d'employés, il est presque égal à Microsoft, Google et Intel réunis!
Le thème du mainframe est énorme. Bien sûr, je n'ai pu écrire qu'une petite partie de ce qu'il peut contenir. Je serais très reconnaissant pour des clarifications et des informations supplémentaires.
Ce matériel est également disponible en anglais .