Esta parte se concentra na comparação da linguagem de máquina de mainframes com outros sistemas populares entre os anos 70 e 90. Eles são principalmente x86, 68k, VAX e ARM. Os sistemas 390 e, em particular, Z são considerados muito fragmentários - o foco principal está no sistema 370.
Os primeiros sistemas 360 começaram a ser enviados aos clientes em 1965, e os sistemas 370 mais avançados a partir de 1970. A IBM mantém a compatibilidade de software com esses sistemas até hoje! Surpreendentemente, antes de 390 sistemas, lançados, como você pode imaginar desde 1990, os mainframes funcionavam com endereços de 24 bits, ou seja, eles podiam endereçar no máximo 16 megabytes de memória, o mesmo que, por exemplo, 68000, lançado em 1979, ou 65816ou 32016, lançado em 1982. VAX com suporte nativo para endereçamento de 32 bits. Os populares processadores 68020 ou 80386, que surgiram em meados da década de 1980, também suportavam endereços de 32 bits. Na verdade, 16 MB de memória para os melhores sistemas da segunda metade dos anos 80 já não eram suficientes. No entanto, desde 1983, a IBM vem produzindo 370 computadores compatíveis que poderiam, como uma extensão, usar 31 dígitos de endereço, o que eliminou o problema de memória para computadores melhores. De maneira incomum e única, essas extensões e sistemas 390 usavam um endereço de 31 bits em vez de um endereço completo de 32 bits. Em 2000, a IBM anunciou o primeiro sistema Z a usar endereçamento e dados de 64 bits. Os sistemas Z têm usado chips de processador desde 2008. Eles vêm tentando combinar a arquitetura Z desde 2007 em um único chip com a arquitetura POWER, mas até agora sem sucesso. Até agora, apenas a Intel conseguiu combinar CISC e RISC em um chip - o Pentium Pro em 1995 tornou-se o primeiro chip de seu tipo.
IBM System / 370-145 com uma unidade de fita 2401 e uma impressora em vez de uma tela, 1971. Pode ser surpreendente que não haja nenhuma tela neste sistema muito caro, apesar do fato de que os televisores são produzidos em massa há mais de 20 anos.
A propósito, algumas autoridades acreditam que o primeiro computador pessoal serial foi IBM 5100 , em produção desde 1975, que podia executar instruções do sistema 360 por meio de um emulador de hardware. Versões aprimoradas do mesmo foram produzidas até meados da década de 1980. O Wang 2200 foi o primeiro, no entanto . A preços (cerca de US $ 10.000), esses primeiros computadores pessoais claramente não eram para uso doméstico.
IBM 5100, variante APL
Com o advento da arquitetura IBM PC, que acabou determinando a principal direção de desenvolvimento da tecnologia de computação por décadas, a IBM tentou em 1983 combinar quase todas as melhores tecnologias de computador em um produto PC XT / 370: seus 370 sistemas, IBM PC XT, Motorola 68000 e Intel 8087. Este XT / 370 pode ser usado como um terminal inteligente para trabalhar com um mainframe, como um IBM XT regular, ou para executar software de mainframe diretamente. Curiosamente, o XT / 370 adicionou suporte para o uso de memória virtual, que exigia dois 68000. Em 1984, com o advento do PC AT, foi lançada uma versão melhorada do AT / 370 "mainframe pessoal", que era cerca de duas vezes mais rápido que o XT no modo mainframe. / 370. A história desses sistemas não para por aí, desde a década de 90 são produzidos produtos semelhantes, correspondendo a 390 sistemas.Pelo que eu sei, isso não foi feito para Z systems.
A IBM usa um modelo de negócios bastante incomum para seus mainframes, no qual os computadores não são vendidos, mas alugados. Uma das vantagens de tal modelo é que garante uma atualização constante do equipamento, o equipamento desatualizado é automaticamente substituído por um atualizado da classe correspondente. Este modelo também tem desvantagens. Por exemplo, uma desvantagem particularmente perceptível para quem estuda a história da informática é o fato de que os computadores usados quase sempre são descartados e, portanto, é quase impossível encontrá-los em qualquer museu.
Surpreso ao encontrar um sistema IBM 4361 ativo no LCM! Mas há razões para acreditar que isso pode não ser ferro de verdade. Por algum motivo, os visitantes do museu não têm acesso a este computador. Também não está claro qual modelo é supostamente apresentado ali, apesar do fato de outros computadores no museu serem identificados com muita precisão. Entre os 4361 sistemas, três modelos 3, 4 e 5 são conhecidos, e o modelo 3 apareceu depois dos modelos 4 e 5. Mas o sistema no museu se autoidentifica como modelo 1. É possível que este seja um protótipo. No entanto, os funcionários do museu não responderam a uma pergunta direta sobre a assistência na identificação, apesar do fato de responderem a outras perguntas, muitas vezes bastante difíceis, com bastante rapidez. Algumas características do tempo de execução de códigos fornecem bases, embora não absolutamente sólidas, para assumir que o emulador está provavelmente conectado à rede. No verão no museu, em conexão com covid,obviamente mudou para um emulador ... Ainda há uma chance de chegar aos mainframes de ferro através da redeHNET , mas ainda não consegui.
Mas seja o que for, todos podem se conectar e tentar trabalhar da mesma maneira que especialistas bem pagos trabalharam desde meados dos anos 70. Os preços eram tantos que hoje nem dá para acreditar. Por exemplo, uma hora de uso do computador custava mais de US $ 20 em meados dos anos 80 e você ainda tinha que pagar a mais pelo espaço em disco! É verdade que estamos falando sobre o tempo de operação do mainframe, e não do terminal pelo qual o trabalho estava passando. Portanto, por exemplo, ao editar um texto de uma hora de trabalho real, raramente demorava 5 minutos para pagar. Os preços dos próprios mainframes também eram fantásticos. Por exemplo, os funcionários da Intel lembram que, no início dos anos 80, recebiam apenas um mainframe para trabalhar. Seu desempenho era de 10 MIPS e o preço era de aproximadamente $ 20 milhões na época, o que era três vezes mais pesado do que hoje! Interessante,que a Intel preferia esses computadores aos sistemas VAX mais baratos. Agora mesmoUm Raspberry Pi é do tamanho de uma pílula e custa alguns dólares, e pode facilmente fornecer mais de 1000 MIPS. A propósito, em um Raspberry Pi ou em quase qualquer computador moderno, você pode rodar um emulador IBM / 370, que rodará significativamente mais rápido do que qualquer sistema IBM dos anos 80 ou 90. No entanto, o emulador deve ser customizado e nem todos os programas úteis para IBM / 370 estão disponíveis gratuitamente, portanto, o acesso gratuito a um sistema bem ajustado costuma ser a melhor maneira de contornar o mainframe. Surpreendentemente, esses programas de acesso, emuladores de terminal 3270, estão disponíveis até mesmo em telefones celulares! A propósito, consegui configurar meu sistema VM / CMS no emulador Hercules e lidar com a transferência de arquivos, mas demorou pelo menos uma semana.
O emulador Hercules pode emular sistemas IBM / 390 e IBM / Z posteriores, mas devido a problemas de licença de software, isso é muito mais difícil de fazer. Como ilustração de tais problemas, citarei o famoso caso em que a IBM insistiu em remover a seção de Emulação de um livro já publicado! Nas versões eletrônicas modernas deste livro, esta seção não existe, ela só pode ser encontrada na edição impressa ou como um arquivo separado em sites dedicados ao software livre. O fato é que a emulação em PCs normais desde o início dos anos 2000 pode ser notavelmente mais rápida do que a execução em mainframes muito mais caros. A IBM, portanto, teve que alterar suas licenças de software para que só possa ser legalmente usado em hardware adquirido da IBM. Claro, não estamos falando que os emuladores são mais rápidos do que os melhores mainframes,eles apenas mostram uma relação desempenho-custo visivelmente melhor.
Uma maneira de trabalhar com sistemas Z ou 390 é instalar o Linux em um emulador desses sistemas. Para 390 e Z, pelo menos distribuições Ubuntu e Debian estão disponíveis. É importante notar aqui que o rápido desenvolvimento do Linux se deve em grande parte ao suporte significativo da IBM. Em particular, a IBM em 2001 investiu um bilhão de dólares no desenvolvimento do Linux.
Consideremos agora as características da linguagem de máquina de sistemas compatíveis com 360. O montador básico de tais sistemas é denominado BAL - Basic Assembly Language. Surpreendentemente, de acordo com rumores sobre a IBM, a linguagem assembly ainda é uma das principais linguagens de programação de trabalho lá.
O montador dos mainframes em consideração possui uma série de recursos arcaicos que já estavam ausentes em outras arquiteturas conhecidas que surgiram posteriormente. Por exemplo, é sobre o fato de que os mnemônicos BAL determinam o tipo de argumentos. Considere as instruções do assembler x86 como exemplo
MOV EAX,EBXe MOV EAX,address- ambos usam o mnemônico MOV. Para BAL, para tais casos, diferentes mnemônicos LR e L são usados nos comandos, respectivamente, LR 0,1eL 0,address... No entanto, diferentes mnemônicos semelhantes permitem o uso de números para nomear registradores, embora geralmente as macros R0, R1, ... em vez de números 0, 1, ... sejam a primeira coisa definida em pacotes de macro para conveniência de programação. Outro arcaísmo é o uso de saltos de rótulo em construções de compilação condicional, embora na minha humilde opinião isso às vezes seja mais conveniente do que estruturas de bloco. Mas o arcaísmo mais famoso é o uso da codificação EBCDIC para trabalhar com informações simbólicas. Nessa codificação, estranha até ontem, as letras do alfabeto inglês não são codificadas em sequência, por exemplo, a letra I tem código 201, e o próximo J é 209! Essa codificação vem de tecnologias para trabalhar com cartões perfurados que surgiram na era pré-computador. O System 360 também suporta ASCII no hardware, mas em sua versão antiga e há muito esquecida,onde o caractere para o dígito 0 tem o código 80, não 48 como é agora. Pelo que eu sei, ASCII com mainframes IBM era melhor nem mesmo tentar usar. O suporte ASCII já foi removido em 370 sistemas, mas introduzido em um novo nível em sistemas 390. Alguns mnemônicos BAL são impressionantes em sua supercurtura e até mesmo não-nemonicidade, por exemplo, N significa AND, O - OR, X - XOR, A - ADD, S - SUBTRACT, M - MULTIPLY, ...
O montador BAL permite que você trabalhe com três tipos de dados básicos: números binários, decimais e reais. Os sistemas 390 usam outro tipo especial para trabalhar com números reais. Alguns sistemas Z também podem usar dados completamente exclusivos, como números reais decimais. As instruções para trabalhar com cada tipo formam uma classe especial e bastante isolada de instruções. Geralmente, com muito poucas exceções, todos os sistemas compatíveis com 360 suportam instruções aritméticas decimais e reais. Como você sabe, para arquiteturas x86 ou 68k, o suporte para trabalhar com números reais não apareceu imediatamente e por muito tempo foi uma opção opcional, e trabalhar com números decimais não era algo completamente separado da aritmética binária - era antes uma extensão.
Para trabalhar com números reais e binários, diferentes conjuntos de registros são usados e, para trabalhar com números decimais, não são usados registros. O sistema 370 fornece 16 registros de 32 bits de uso geral para inteiros binários, com o contador do programa sendo parte da palavra de status do processador. Não há uma pilha separada, ela pode ser organizada usando qualquer registro - é assim que o trabalho com a pilha foi subsequentemente implementado no ARM. A chamada da sub-rotina também é feita como no ARM, através do registrador do link. Todos os registros são quase sempre intercambiáveis, as exceções são muito raras. Se você comparar o sistema de registro binário BAL com a arquitetura VAX da concorrência, notará que o VAX tem um registro a menos. Isso também é válido para ARM.
A estrutura dos operandos nas instruções parecerá bastante familiar para aqueles que conhecem o x86 assembler. Para números binários, os operandos têm uma estrutura de registro-registro ou registro-memória e, para o último caso, os valores expansíveis com sinal de 32 e 16 bits podem ser carregados da memória. Por exemplo, um análogo da instrução x86
ADD EAX,EBXseria 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). No entanto, os sistemas 360 e mesmo seus desenvolvimentos posteriores não sabem como trabalhar com escalonamento, por exemplo, você ADD EAX,address[8*EBX]não pode gravar no BAL com um comando. Por outro lado, x86 não sabe trabalhar com extensões assinadas de 16 bits, por exemplo, o comando BALAH 0,address, o que significa pegar um número assinado de 16 bits da memória e adicioná-lo ao registro 0, em x86, exigirá duas instruções para implementação.
Uma característica rara do BAL é que existem instruções separadas para adição e subtração para números com e sem sinal, e as operações sem sinal no BAL são chamadas de booleanos. Essa estranheza é causada pela ausência de sinalizadores na arquitetura 360, que são familiares à maioria das outras arquiteturas. Em vez disso, apenas dois bits são usados, que são configurados de forma diferente por instruções diferentes! A única diferença entre operações com e sem sinal é que elas definem os dois bits de atributo mencionados de maneira diferente. Para as operações assinadas, é possível saber se o resultado foi zero, se foi positivo ou negativo, se ocorreu um estouro e, para as operações não assinadas, se o resultado foi zero e se ocorreu uma transferência ou um empréstimo. As instruções de desvio condicional permitem todos os 16 subconjuntos de casos possíveis com 2 bits.Devido a este trabalho incomum com sinais de operação hoje, as instruções de desvio condicional são difíceis de entender rapidamente. Embora as extensões BAL geralmente adicionem macros muito fáceis de ler para saltos condicionais, onde você não precisa analisar cada um dos 4 bits. Aqui, para fins de justiça, você pode ver que existem comandos separados para adição e subtração assinada e não assinada, por exemplo, na arquitetura MIPS, onde não há sinalizadores em tudo!por exemplo, na arquitetura MIPS, onde não há nenhum sinalizador!por exemplo, na arquitetura MIPS, onde não há nenhum sinalizador!
Outro recurso raro está em comandos separados para comparações assinadas e não assinadas. Conheci pessoas semelhantes não apenas no MIPS, mas também na MicroBlaze. Neste último, por sinal, a transferência é o único sinalizador suportado dos sinalizadores de operação.
Em sistemas compatíveis com IBM 360, não há operações aritméticas com o sinalizador de transporte, portanto, se precisarmos trabalhar com números binários, por exemplo, em números de 128 bits, devemos verificar o sinal de transporte após realizar as primeiras operações de 32 bits para organizar sua adição ou subtração. e faça a transição, se necessário. É claro que isso é muito complicado em comparação com x86, ARM, 68k ou mesmo 6502, mas em MIPS muito posteriores é ainda mais complicado. O trabalho normal com a transferência foi feito apenas no sistema Z.
Não há mudanças cíclicas no BAL, mas as mudanças não cíclicas, como em x86, podem ser simples ou duplas. No entanto, o BAL tem instruções de deslocamento separadas para números não assinados e assinados, apenas o último define sinalizadores. Obviamente, os resultados dos deslocamentos para a esquerda para ambos os casos diferem apenas nos sinalizadores. Giros adicionados apenas a 390 sistemas.
Entre os comandos para carregar registradores no BAL, provavelmente existem alguns únicos. Você pode carregar o módulo de um inteiro, negação deste módulo, ou um número com um sinal alterado - algo remotamente semelhante que só encontrei na arquitetura ARM. Deve-se notar aqui que toda a arquitetura do 360 tende a significar aritmética, e a aritmética sem sinal nesta arquitetura é bastante secundária. Inicialmente, o BAL não tinha divisão e multiplicação sem sinal, eles foram adicionados apenas ao sistema 390. Quando o registro é carregado, os sinalizadores, assim como no x86, não mudam, mas há um comando de inicialização especial que define os sinalizadores - isso novamente lembra o ARM, onde definir os sinalizadores pode governar.
Todas as operações aritméticas assinadas, incluindo mudanças, podem lançar uma exceção de estouro. Se uma exceção é lançada ou não, é determinado por um sinalizador de máscara especial no registro de status. Curiosamente, a divisão binária e a multiplicação em BAL não afetam os sinalizadores de forma alguma - aqui você pode se lembrar do x86, onde a divisão apenas estraga os sinalizadores.
As operações lógicas bit a bit em BAL são representadas pelo conjunto usual de AND, OR, OR exclusivo, ou seja, não há operação de negação separada. As operações lógicas podem ter não apenas uma estrutura de registro-registro ou registro-memória, mas também “constante de memória” ou “memória-memória” - o último método de endereçamento é semelhante ao usado para números decimais. O endereçamento do tipo "constante de memória" só é possível para trabalhar com bytes. Obviamente, para operações lógicas, ao contrário da aritmética, o uso de números de 16 bits é impossível. Para endereçamento de memória para memória, você pode trabalhar com dados de até 256 bytes! Acontece que temos três tipos de dados para trabalhar com operações lógicas: bytes, palavras de 32 bits, sequências de bytes - e instruções especiais para cada um desse tipo, que é um tanto não universal.
As operações lógicas em BAL são adjacentes às operações de transferência de bytes. Além da transferência usual de até 256 bytes com um comando, há também uma instrução exclusiva para transferência de tétrades de bytes. Você pode enviar apenas as metades superior ou inferior dos bytes, enquanto as outras metades retêm seu valor durante a cópia! Essas operações estranhas são necessárias para oferecer suporte aos recursos BAL ao trabalhar com informações de caracteres e decimais. Existem também instruções de encaminhamento e comparação para 370 sistemas de até mais de 16 milhões de bytes por vez, que podem ser interrompidos. Surpreendentemente, também os comandos lentos para trabalhar com blocos de até 256 bytes não podem ser interrompidos, o que pode criar um atraso desagradável em resposta a uma solicitação de interrupção. Os comandos de transferência também podem ser usados para preencher a memória com um byte especificado.Além de transferir de memória para memória, você também pode definir bytes individuais para um determinado valor. Obviamente, as instruções para transferência de bytes, além das novas instruções para 390 e Z, são mais avançadas para x86.
No registro, você pode carregar não apenas o valor no endereço fornecido, mas também o próprio endereço, como nos comandos LEA para x86 ou 68k. Este recurso também permite que você carregue diretamente a constante necessária no registro, embora seu valor máximo não possa ser maior que 4095. Ele também permite que você aumente o registro em não mais que 4095. Mas o decréscimo do registro pode ser feito apenas em 1. Um incremento e um decremento - esses são comandos de endereço, portanto, não mudam os sinalizadores. Você pode carregar bytes individuais e até grupos de bytes de uma palavra na memória no registro, por exemplo, apenas o primeiro e o terceiro bytes - isso é possível para todas as outras arquiteturas de 32 bits conhecidas por mim apenas por meio de uma série de 4 comandos. Da mesma forma, o BAL permite que apenas partes de um registro sejam despejadas na memória.
A série de instruções BAL é muito especializada - em outras arquiteturas, elas são implementadas por uma série de instruções mais simples. Por exemplo, a instrução TR permite que você converta uma string de caracteres - um argumento especifica a string a ser convertida e o outro o endereço da tabela de conversão. Uma variante especial desta instrução, TRT, pode ser usada para escanear uma dada string e pular caracteres vazios - esta é a funcionalidade da chamada strpos padrão do C. As instruções ED e EDMK são completamente únicas - elas têm a funcionalidade do sprintf primitivo! No entanto, quase todas as operações de string têm uma limitação no comprimento máximo da string, não mais do que 255 bytes, o que reduz significativamente seu poder.
No BAL, é difícil trabalhar com valores não assinados de 16 bits devido à falta de rotação ou comandos do tipo SWAP. Com 390 sistemas, esse problema melhorou. Algumas instruções BAL estão obsoletas, por exemplo, a instrução MVO nibble shift foi suplantada pelo SRP mais conveniente. Para transferências e comparações em bloco, é melhor usar as novas instruções, embora, devido ao fato de elas usarem uma forma diferente de endereçamento, isso possa, em alguns casos raros, ser abaixo do ideal.
Já houve exemplos dos quatro modos básicos de endereçamento BAL. Também há um quinto para comandos de três endereços. Modos como VAX, 68k, PDP-11 ou mesmo os modos de incremento ou decremento automático 6809 não estão disponíveis no BAL. Também não há modos DIMM como VAX, 68020 ou PDP-11. E, é claro, o BAL, ao contrário dos montadores VAX ou PDP-11, é completamente não ortogonal. O BAL é o mais próximo dos assemblers x86 e ARM, as arquiteturas modernas de maior sucesso. A ordem dos operandos no BAL da direita para a esquerda é a mesma que no Intel assembler para x86 ou no ARM assembler e, portanto, não como VAX, PDP-11 ou 68k. Embora a ordem dos bytes nos dados em BAL seja de maior para menor (MSB), o que difere de x86, ARM ou VAX, ela corresponde ao aceito para 68k ou MIPS.
As operações com números decimais são implementadas no BAL apenas por meio do endereçamento de memória para memória. Números decimais podem ser especificados em blocos de memória de até 16 bytes, permitindo que números de até 31 casas decimais sejam usados. Isso corresponde à precisão de um número binário de 107 bits. Assim, apenas os sistemas de programação mais modernos usando inteiros binários podem lidar com valores maiores do que 360 sistemas há quase 60 anos! Claro, é possível implementar números arbitrariamente grandes por meio da aritmética binária, mas por algum motivo, até recentemente, não havia linguagens de programação populares que suportassem números maiores do que o antigo sistema 360. Mesmo agora, o suporte para inteiros de 128 bits para x86 é geralmente apenas extensões não oficiais, como para GCC.
Os números decimais no BAL são representados exclusivamente, eles devem armazenar um sinal - este não é o caso para VAX, x86, 68k, ... Além disso, o sinal é armazenado no último byte da representação do número! Para números decimais, BAL tem suporte direto para todas as operações básicas: adição, subtração, multiplicação e até divisão - isso também não é encontrado em nenhuma outra arquitetura que eu conheço. Além disso, o BAL também fornece instruções para copiar, comparar e deslocar números decimais. As instruções MVO e SRP acima mencionadas são projetadas exatamente para esses turnos. As operações podem ser realizadas apenas em números decimais compactados, mas para imprimi-los, eles devem ser descompactados, e para representar os dígitos descompactados no BAL, é necessário também um sinal, que neste caso não ocupa espaço, pois está colocado no tétrade superior, o que requer um trabalho especial com este caderno antes de imprimir.É estranho que as operações de boxing e unboxing só funcionem com, no máximo, 16 bytes do número decimal descompactado, o que permite que apenas números de 15 bits sejam usados com eles. Este problema desagradável pode ser resolvido usando ED ou EDMK para instruções de desempacotamento, mas empacotar um grande número desempacotado terá que ser feito por meio de uma seqüência não muito simples de instruções. Novas instruções foram adicionadas a 390 sistemas para resolver esse problema. Curiosamente, as instruções de empacotamento e desempacotamento funcionam com quaisquer dados binários, não apenas decimais.Este problema desagradável pode ser resolvido usando ED ou EDMK para instruções de desempacotamento, mas empacotar um grande número desempacotado terá que ser feito através de uma seqüência não muito simples de instruções. Novas instruções foram adicionadas a 390 sistemas para resolver esse problema. Curiosamente, as instruções de empacotamento e desempacotamento funcionam com quaisquer dados binários, não apenas com dados decimais.Este problema desagradável pode ser resolvido usando ED ou EDMK para instruções de desempacotamento, mas empacotar um grande número desempacotado terá que ser feito por meio de uma seqüência não muito simples de instruções. Novas instruções foram adicionadas a 390 sistemas para resolver esse problema. Curiosamente, as instruções de empacotamento e desempacotamento funcionam com quaisquer dados binários, não apenas com dados decimais.
O BAL tem instruções exclusivas especiais que permitem converter um número binário em decimal compactado e vice-versa de uma vez. Para um número decimal nestas instruções, 8 bytes são sempre alocados, ou seja, 15 dígitos e um sinal. No entanto, o registro de 32 bits é suficiente apenas para representar um número com sinal correspondente a um número decimal de 9 dígitos, portanto, nem todo número decimal no formato BAL correto pode ser convertido em binário em um comando. Para sistemas Z, existem instruções estendidas para tais conversões.
As instruções de salto em BAL diferem porque, como regra, estão emparelhadas - o endereço de salto pode ser definido explicitamente e pelo conteúdo do registro - em muitas outras arquiteturas, os saltos ao longo do conteúdo do registro são apenas para saltos incondicionais. A propósito, não há saltos incondicionais no BAL, eles são implementados definindo uma condição sempre verdadeira, que é semelhante à arquitetura ARM. A ramificação condicional em BAL, conforme observado, tem uma sintaxe exclusiva. Considere, por exemplo, a instrução
BT 9,address, o que significa dar um salto se as condições 0 e 3 forem atendidas, mas as condições após comandos diferentes têm significados diferentes. Por exemplo, após a adição com sinal, essas condições significam “o resultado é 0 ou ocorreu um estouro” e, após uma adição sem sinal, “o resultado é 0 e não houve transporte ou o resultado não é 0 e houve transporte”. Apesar do peso e de alguma redundância, não se pode deixar de admitir que tal sistema para trabalhar com condições de transições é provavelmente o mais flexível de todos conhecidos. O nove no comando do exemplo é usado na representação binária 1001, ou seja, ele define os números dos bits - o próprio sistema codifica todas as combinações de condições com 4 bits também é usado no ARM. Além dos saltos condicionais, o BAL também tem contadores de saltos com decréscimo, aproximadamente o mesmo que nos montadores Z80, x86, 68k, PDP-11, ... Mas o BAL também tem duas instruções completamente exclusivas para saltos,que, dependendo do número de um dos registradores-operandos, pode ser três ou quatro endereços! Nesses comandos exclusivos, dois registros são somados e a soma resultante é comparada com o conteúdo de outro registro, e o resultado dessa comparação é determinar se salta ou não. Acredita-se que essas instruções incomuns sejam úteis para trabalhar com tabelas de salto.
Como já observado, a chamada de sub-rotinas no BAL é implementada sem usar a pilha, simplesmente armazenando o endereço de retorno em um registrador. No entanto, as instruções BAL para tais chamadas, uma das quais também é chamada de BAL, salvam não apenas o endereço de retorno, mas também parte do registro de status, em particular, sinalizadores de condição, o comprimento da instrução atual e até mesmo uma máscara para exceções opcionais, por exemplo, para inteiro ou decimal overflows - isso já foi mencionado acima. Esse armazenamento estendido incomum de informações se deve ao fato de que o contador de instruções na arquitetura do mainframe é a parte superior da palavra de status da máquina e as instruções para chamar sub-rotinas preservam mecanicamente sua parte superior. Não há comandos especiais para retornar de sub-rotinas, você precisa usar o salto normal para o endereço no registro.Em 390 sistemas, em conexão com a transição para a arquitetura de 31 bits, novas instruções surgiram para chamar e até mesmo retornar de sub-rotinas. As novas instruções possibilitam o uso flexível de códigos executados em diferentes modos em um programa.
Para chamar rapidamente sub-rotinas de comando único, BAL tem uma instrução EX exclusiva que executa a instrução em um determinado endereço e segue para a próxima instrução. A instrução EX pode modificar a instrução chamada, o que permite a você usar qualquer registro desejado na instrução chamada ou definir parâmetros para transferência em massa de bytes. Uma instrução semelhante, mas mais simples, também está no sistema de comando TMS9900.
Inicialmente, o BAL não tinha transições relocáveis e relativas, como o Z80 ou o x86. Eles foram adicionados apenas a 390 sistemas.
Os comandos SPM, TM, TS, STCK e STPT também são um tanto incomuns. O primeiro deles permite que um comando defina todos os sinalizadores de operações e a máscara de exceções opcionais. O comando TM permite verificar um grupo de bits e identificar três casos: todos zeros, todos uns, uma mistura de zeros e uns. Esta verificação não pode ser feita por um comando em outras arquiteturas. No entanto, TM funciona apenas com bytes individuais na memória. TS é usado ao trabalhar com vários processadores - há um comando semelhante para 68k. A instrução STCK lê o valor do temporizador externo (!) E a instrução STPT lê o valor do temporizador interno embutido no circuito do processador. Estranho, mas STPT é privilegiado, mas STCK não.
Também vale a pena mencionar as instruções CS e CDS, que se destinam a apoiar o trabalho de multiprocessamento. Eles foram implantados para 370 sistemas, ou seja, estão disponíveis desde o início dos anos 70. Em x86, o análogo de CS, a instrução CMPXCHG, foi implementado não antes de 1987, e o análogo de CDS, a instrução CMPXCHG8B, foi implementado apenas em 1994!
A partir de 370 sistemas, o comando de auto-identificação do sistema STIDP é introduzido, é privilegiado e não muito informativo. Para x86, este comando se tornou muito mais poderoso. Você também pode notar aqui que o IBM 4361 no LCM permite que qualquer usuário execute STIDP. Obviamente, esta é uma emulação acionada por exceção.
Os quatro modos BAL endereçáveis especificam dois operandos para a instrução, o quinto modo especifica comandos de três endereços. No entanto, ignorar algumas das informações permite que você tenha comandos unicast, e o uso de informações implícitas permite que você tenha comandos de quatro endereços. Quando usado no endereçamento, o registrador 0 tem uma função especial: ele é simplesmente ignorado - isso permite que você ignore a base e o índice ao calcular o endereço. Todas as instruções BAL são estritamente de 2, 4 ou 6 bytes. Parece um 68000 ou PDP-11, mas não x86, VAX ou ARM.
Vários outros modos de endereçamento foram adicionados ao sistema 390, elevando seu número para 18. O número de instruções também aumentou significativamente, entre as novas instruções há até mesmo aquelas que suportam trabalhar com Unicode - isto ainda não está disponível para x86! Entre as novas instruções para 390 sistemas, existem outras exclusivas. Vários outros modos de endereçamento foram adicionados ao sistema Z, e o número total de comandos para o Z moderno é muito grande e provavelmente até mais do que o número de comandos para o x86-64 moderno!
Nos sistemas 360, 370 e 390, os deslocamentos ao acessar dados na memória, como no ARM, são de 12 bits, ou seja, não mais do que 4095, o que não é muito conveniente - em códigos grandes pode haver uma falta de registros para a base. No x86, esse deslocamento é de 16 bits, o que, obviamente, é muito mais conveniente. Mas o sistema Z adicionou suporte para endereçamento de deslocamento de 20 bits, o que é ainda melhor. Porém, é importante notar que em x86-64 ou mesmo 68020 o deslocamento pode ser de 32 bits. Conforme observado, os sistemas pré-390, como o ARM, não tinham a capacidade de usar constantes grandes ao trabalhar com registradores. A arquitetura x86 é muito mais flexível aqui. Portanto, ao usar assembler com um sistema 360 ou 370, muitas vezes era necessário usar literais, pseudo-constantes, que são um pouco mais lentas.
Em termos de desempenho, os sistemas compatíveis com IBM / 360 sempre tiveram bons indicadores. Meus experimentos com 4361-1, em particular no projetocálculos do número π pelo algoritmo do obturador mostraram tempos muito bons. As instruções 4361-1 são executadas virtualmente sem latência, como o ARM ou outros processadores modernos. No entanto, devido a um sistema de instrução um tanto estranho herdado dos anos 60, em particular, devido à falta de divisão por um divisor de 16 bits, o resultado em termos de eficiência da eletrônica do processador acabou ficando no nível de 80186. Isso é cerca de 80% pior que o resultado, mostrado pelo então melhor computador VAX, Modelo 785. No entanto, o mainframe em LCM claramente não é o melhor entre os mainframes IBM disponíveis então. Também é pertinente observar aqui que os mainframes usavam canais, processadores especializados que tornavam o I / O muito rápido, muito mais rápido do que a maioria dos computadores modernos.
Como estudante, por acaso trabalhei com um clone doméstico do IBM / 370, EC-1045, em 1987 em lote e em 1989 em diálogo. Para o modo batch, era necessário preparar cartões perfurados. Naquela época eu já usava um computador doméstico e por isso o uso de cartões perfurados arcaicos não me dava boa impressão. Mas o modo interativo não era ruim, só que frequentemente quebrava, com um grande número de usuários. Portanto, alguns alunos vieram trabalhar por volta das 4 da manhã! Desde então, não consegui mais lidar com mainframes, só recentemente decidi lidar com essa tecnologia marcante para a história dos computadores por meio da emulação.
A clonagem do IBM 360 era muito popular. Os clones foram feitos na Inglaterra, Alemanha, Japão e outras empresas nos EUA. Na URSS, essa clonagem adquiriu uma conotação muito dramática. Por causa dessa clonagem, quase todos os desenvolvimentos domésticos no campo de TI foram dobrados, alguns dos quais eram muito promissores. Em particular, foi encerrado o tópico dos computadores dos Urais , sobre o qual o famoso cientista da computação Charles Simonyi falou com entusiasmo . O projeto BESM-10 também foi encerrado, embora as máquinas da classe BESM-6 anterior fossem comparáveis ao IBM 360 em termos de velocidade. Além disso, por causa dessa clonagem, um contrato quase concluído com a ICL foi frustrado, talvez com esse contrato a indústria de TI britânica teria adquirido uma nova dinâmica e não teria declinado. Supercomputadores apenasElbrus , possivelmente devido aos seus laços com a indústria de defesa, sobreviveu à "Invasão Clone", que Dijkstra chamou de a maior vitória dos EUA na Guerra Fria.
Como lembram as pessoas que trabalharam com mainframes na URSS, os clones domésticos se distinguiam pela confiabilidade extremamente baixa e exigiam atenção constante do pessoal de serviço. Enquanto os mainframes IBM americanos originais foram alguns dos computadores mais confiáveis de seu tempo. Às vezes, mais de dez (normalmente mais de 5) quilos de metais preciosos, ouro, platina, paládio e prata eram colocados em clones soviéticos, mas isso não ajudava a corrigir a situação com confiabilidade. Devido a um grande número de valores altamente líquidos, é difícil imaginar que um clone doméstico funcional pudesse sobreviver em algum lugar.
Curiosamente, o principal desenvolvedor do IBM 360 deixou a IBM e fundou a Amdahl, que por mais de duas décadas se especializou na produção de sistemas compatíveis com mainframes IBM e ao mesmo tempo superiores em velocidade e confiabilidade a preços mais baixos. Como resultado, devido às grandes mudanças no mercado de mainframe, a Amdahl, como a ICL, tornou-se parte da corporação japonesa Fujitsu.
Além dos computadores da arquitetura IBM / 360, havia outros mainframes. Na década de 60, os fabricantes americanos de mainframe receberam extraoficialmente o nome sonoro de Branca de Neve e os Sete Anões. Provavelmente é fácil adivinhar que Branca de Neve era a IBM. Mainframes de arquiteturas originais também foram produzidos em outros países. A arquitetura britânica ICL 1900 merece menção especial.
Como já escrevi, consegui fazer uma configuração de trabalho para VM / CMS 6. Porém, descobri que o editor XEDIT não está disponível gratuitamente, e uma EDIT simples é muito peculiar e inconveniente, então você tem que editar os textos no host. Também foi descoberto que um programa padrão não estava disponível para transferência de arquivos do emulador de terminal para o mainframe e vice-versa, o que exigia o uso de cartões virtuais perfurados para tal transferência. Outra surpresa desagradável surgiu em conexão com a depuração. O comando DEBUG não suporta revisão! Embora tal possibilidade fosse até mesmo para o depurador DDT para o processador 8080. Também é surpreendente, embora menos crítico, que o DEBUG não saiba como fazer a desmontagem, que muitas vezes era construída até mesmo nos monitores mais simples dos processadores dos anos 70.Quebra de linha longa e caracteres de controle de fim de linha não são suportados no nível inferior no CMS! Portanto, ao imprimir a partir de programas em linguagem assembly, é necessário formatar as linhas manualmente para que não desapareçam além da borda direita da tela, e também cuidar de preencher a última linha com espaços de acabamento. Também incomum é a falta de rolagem vertical automática.
Aqueles que desejam trabalhar com mainframes pela primeira vez devem ter em mente que os mainframes são um grande ecossistema, onde muitos conceitos familiares podem ter uma interpretação diferente. Por exemplo, o conceito simples de arquivo não existe. Um dos principais atributos do arquivo é o tamanho do registro, não há nada assim para arquivos Linux ou Microsoft Windows. Os próprios arquivos diferem nos métodos de acessá-los e há livros escritos e possivelmente não finos sobre isso. Também é incomum que no CMS o nome do disco seja escrito no final do nome completo do arquivo, e o nome, a extensão e o disco sejam separados por espaços e o próprio nome do disco seja chamado de modo de arquivo por algum motivo. Eu também gostaria de resolver o MVS multitarefa , pelo que eu sei na URSS, eles nunca chegaram a isso.
Em geral, é um tanto inesperado que alguns sistemas operacionais conhecidos que eram usados em computadores muito caros não suportassem trabalhar com diretórios de arquivos, o que os igualava aos primeiros e primitivos sistemas operacionais para microcomputadores, por exemplo, CP / M ou Commodore DOS. Não é por acaso que o CMS às vezes era chamado de CP / M para mainframes. Surpreendentemente, até onde eu sei, o suporte para catálogos no CMS nunca foi introduzido, embora a última versão do sistema seja de 2018. Por algum motivo, o trabalho com catálogos para computadores caros costumava ter suporte insuficiente antes dos anos 80. Por exemplo, não havia tal suporte no DEC RT-11 e até mesmo um dos melhores sistemas operacionais para PDP-11, RSX-11, suporta apenas diretórios de dois níveis. O sistema operacional IBM mais popular até os anos 2000 era o MVS (1974) e mesmo aqui os catálogos eram feitos apenas parcialmente, como no Apple MFS (1984). Embora no Unix (1973), no MS-DOS (desde 1983) ou mesmo no Apple ProDOS de 8 bits (1983), isso funcionou bem desde o início. O tratamento de arquivo mais avançado foi oferecido em VAX / VMS (1977), onde, além dos diretórios, há suporte integrado para controle de versão de arquivo.
Curiosamente, a linguagem de script para CMS, MVS e alguns outros sistemas operacionais IBM, REXX , se tornou uma versão abreviada da linguagem de arquivo em lote para o Commodore Amiga.
O software de mainframe geralmente tem duas cores. Terminais de cores eram usados relativamente raramente e, portanto, existem poucos programas de cores. Existem também alguns programas com gráficos dinâmicos; as atualizações frequentes da tela levam a uma tremulação desagradável perceptível.
Demonstração dinâmica, lançada no emulador IBM 4381 em LCM, terminal 3270-3
Concluindo, não posso deixar de expressar minha admiração pelas tecnologias IBM. Sempre se destacaram por sua originalidade única e alto nível. Eu gostaria de observar especialmente a qualidade muito boa da documentação, que está disponível ao público até mesmo para sistemas modernos. A IBM está demonstrando um tremendo dinamismo no desenvolvimento de tecnologia, apesar de ser uma das maiores empresas do mundo. Em termos de número de funcionários, é quase igual a Microsoft, Google e Intel juntos!
O tema do mainframe é enorme. Claro, só consegui escrever uma pequena parte do que ele pode conter. Ficaria muito grato por esclarecimentos e informações adicionais.
Este material também está disponível em inglês .