Dados gerais do MV / 8000 virtudes de “No mode bit”

Estou lendo "A Alma de uma Nova Máquina", de Tracy Kidder, onde uma equipe da Data General cria uma nova máquina (codinome "Eagle", mais tarde denominada MV / 8000). É uma extensão de 32 bits de uma arquitetura anterior (o Eclipse de 16 bits). Um dos temas rotativos parece ser que eles não querem criar uma máquina com um bit de modo e que conseguiram isso.

No entanto, deixa de fora como isso é tecnicamente alcançado, e também não explica por que era tão atraente criar uma máquina sem um pouco de modo. O livro não é um livro técnico, portanto os detalhes podem estar distorcidos. No entanto, você tem a sensação de ler esse livro que uma solução "mode bit" era comum (e, portanto, viável) na época, mas era considerada pouco atraente pelos engenheiros, talvez por razões estéticas. O livro também faz parecer uma tarefa imensamente difícil criar um design sem um pouco de modo, que de alguma forma foi superado por essa equipe em particular.

Encontrei esta descrição de como isso foi alcançado:

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

Parece ser basicamente sobre o uso de uma parte não utilizada anteriormente do espaço do código de operação para as novas instruções. Devo admitir que fiquei um pouco decepcionado por ter sido "apenas isso". Também acho que isso ainda deixa algumas perguntas sem resposta:

Primeiramente, como os processos de 16 bits residiam no espaço de endereço de 32 bits? Porque eu acho que esse é o principal desafio em criar uma extensão de 32 bits "sem um bit de modo". Estender o conjunto de instruções, por outro lado, é uma tarefa relativamente comum. Como não há descrição de como isso aconteceu, pode-se supor que o código de 16 bits simplesmente acesse a memória como sempre, talvez ele veja algum tipo de visualização virtualizada / banida da memória (com novos registros de CPU controlando onde está o primeiro endereço) ou algo parecido. Mas não sei se há mais do que isso. Nesse caso, alguém poderia argumentar que era uma solução "mode bit". Os processos no modo de 16 bits podem ser executados juntamente com os outros processos em virtude de recursos especiais adicionados à CPU.

Em segundo lugar, por que era tão atraente criar uma máquina sem um pouco de modo? Muitos dos benefícios apresentados no livro são que os clientes queriam executar software antigo. Mas isso não parece falar contra um bit de modo, pois todo o objetivo de usar um bit de modo é ter compatibilidade com versões anteriores. Quando a AMD estendeu o x86 para 64 bits, pelo menos de acordo com o meu entendimento da palavra "bit de modo", o que eles fizeram foi exatamente adicionar um bit de modo. Um bit especial que faria a CPU no modo de 64 bits. E outro bit que faria um processo ser executado em um "submodo" do modo de 64 bits (para habilitar a compatibilidade com aplicativos de 32 bits). A essência do submodo é que a CPU interpreta o fluxo de instruções como as instruções antigas de 32 bits, mas que os acessos à memória de 32 bits realizados são resolvidos usando o novo formato de tabelas de páginas (configurado pelo sistema operacional com reconhecimento de 64 bits) e, eventualmente, mapeado para o espaço de endereço físico completo. Além disso, o código de 32 bits pode ser impedido pelo código de 64 bits. Como a solução Data General, isso também permitia que um programa de 32 bits fosse executado em programas de 64 bits (16 bits vs 32 bits no caso do DG). Portanto, do ponto de vista do cliente, parece não haver nenhuma diferença. Portanto, o único benefício poderia ter sido a implementação, simplificando o design, mas o livro não parece que essa é a preocupação, uma vez que o bit de modo parece ser comum mesmo naquela época (e parece que as arquiteturas posteriores também empregado como mostra o caso x64).

Tenho certeza que há algo que eu perdi, então seria ótimo se alguém pudesse discutir mais sobre os detalhes técnicos e as virtudes desse design "sem modo de bits".

A resposta é que Ed deCastro, presidente da Data General Management, estabeleceu uma equipe de engenheiros na Carolina do Norte especificamente para projetar a próxima geração de CPU. Ele designou a tarefa de suporte e aprimoramentos incrementais para nós, a equipe de Massachusetts. Três vezes propusemos uma nova arquitetura importante, cada vez com um bit de modo muito sensível, e a descrevemos como uma melhoria incremental modesta. Cada vez, Ed via nosso disfarce e rejeitava a proposta, esperando que a equipe da Carolina do Norte fosse bem-sucedida. Ed acreditava que, independentemente de como tentássemos disfarçar nossas propostas, ele saberia que era uma arquitetura de nova geração se tivesse um pouco de modo. Então tivemos que propor uma arquitetura de nova geração sem bit de modo, mesmo que isso a tornasse menos eficiente. Foi assim que passamos por Ed deCastro. Veja a alma de uma nova máquina,

Em teoria, "no mode bit" permitiria usar o sistema operacional antigo de 16 bits sem absolutamente nenhuma modificação e que o sistema operacional seria capaz de iniciar aplicativos de 32 bits, embora os novos aplicativos de 32 bits fiquem presos ao 16 bits de endereço virtual, seria possível usar os registradores de 32 bits e novas instruções, mas se comportariam mal se acessassem endereços virtuais maiores que .$2^{16}$

Com um bit de modo, o antigo sistema operacional de 16 bits teria que ser modificado para descobrir se o programa era de 16 ou 32 bits e, em seguida, defina o bit de modo adequadamente antes de iniciar o programa.

Na prática, parece que o MV / 8000 realmente tinha um pouco de modo. Em outra parte da página de Mark Smotherman em Clemson, ele publicou o Data General, ECLIPSE MV / 8000 Principles of Operation , 1980 . Se você procurar no Apêndice E (a partir da página 369), verá que o MV / 8000 tinha dois mecanismos de tabela de páginas completamente diferentes. A máquina específica com a qual o MV / 8000 era compatível com o anterior era o C / 350, e o C / 350 possuía uma Unidade de Proteção e Alocação de Memória específica de 16 bits, com maneiras específicas de controlar essa unidade. Para operação lógica-física de 32 bits, você ativaria a Unidade de Conversão de Endereço (descrita no Capítulo 3, iniciando na página 31).

Na prática, o que isso significa é que, quando você executa uma instrução de 16 bits no modo de 32 bits, é especificado que os 16 bits mais altos do endereço lógico são definidos como 0. Também deve haver alguma especificação sobre o que acontece com os valores mais altos. Um endereço de 16 bits quando você executa uma instrução de 32 bits no modo de 16 bits, mas não consegui encontrá-lo durante minha breve leitura do manual.

Portanto, é menos uma questão de saber se um bit de modo é bom ou ruim. É mais que não havia um motivo particularmente bom para usar um bit de modo para diferenciar entre instruções de 16 e 32 bits. As instruções de 16 bits usam 16 bits de endereço lógico (com 16 bits altos definidos como 0) e registradores de 16 bits, e as instruções de 32 bits usam 32 bits de endereço lógico e registradores de 32 bits. O sistema operacional antigo "simplesmente funciona" na nova máquina, mas você também pode experimentar as novas instruções executando um novo programa no sistema operacional antigo.