Como é o código da máquina durante a execução?


21

Quando o código da máquina está realmente sendo executado pelo hardware e pela CPU, como ele é?

Seria binário, como nas instruções representadas por uns e zeros, ou seria algo composto por dígitos hexadecimais em que opcodes são bytes apresentados como números hexadecimais que podem ser divididos em números binários, como bytecode?


24
O que você veria são fios, portões e registros piscando no silício. Por exemplo, visual6502.org/JSSim
Nayuki 23/06

4
@Nayuki Eu acho que essa visualização é incrível e merece ser transformada em resposta!
Nalzok 23/06

2
Não me parece nada
Gaius

3
Realmente nem existe quando é realmente "executado". É "JIT compilado" por um dispositivo (hardware!) Na CPU para microcódigo, que realmente instrui a CPU!
xuq01 23/06

2
Uma maneira rápida de entender como um computador traduz é a construção de um de portas lógicas, eu realmente gosta de assistir a um feito por Ben Eater youtube.com/playlist?list=PLowKtXNTBypGqImE405J2565dvjafglHU
Ferrybig

Respostas:


38

A melhor resposta que posso dar é que ela realmente não "se parece" com nada. A instrução atualmente sendo executada pela CPU é representada por uma série de fios, alguns dos quais com alta voltagem, outros com baixa voltagem.

Você pode interpretar as tensões alta e baixa como zeros e uns, mas também pode interpretar grupos de tensões alta e baixa como dígitos hexadecimais ou como uma instrução de montagem ADD $0 $1(a mais próxima de como a CPU a interpreta). Esses números e mnemônicos são conveniências para os humanos lerem; internamente, não passa de tensões nos fios.

Destas opções, o binário é "o mais próximo do metal", na medida em que os zeros e os são mapeados diretamente para as tensões alta e baixa nos fios. Mas nenhum dos outros está incorreto e é frequentemente mais útil: há uma razão pela qual as pessoas olham para hex-dumps de executáveis, mas quase nunca para binários.


Então, você poderia abrir um programa em um editor hexadecimal e os bytes representados em hexadecimal converter-se em código-máquina binário que pode ser executado por uma tensão atribuída a zero e uma tensão atribuída a um?
Tim Quase

4
@TimHardly Yep! Hex é apenas mais fácil de ler. Da mesma forma, a montagem é ainda mais fácil de ler, mas pode ser traduzida mecanicamente para zeros e uns. É por isso que os montadores são mais fáceis de escrever do que os compiladores.
Draconis 23/06

obrigado, toda essa questão expandiu meu conhecimento e esclareceu minha confusão.
Tim Quase

1
@TimHardly Um montador apenas mapeia uma sequência de caracteres como "NOP" para uma série de bits como "10010000", repetidamente, para transformar um arquivo de montagem em código de máquina. Os códigos de operação são determinados pela CPU, já que é a parte que realmente os usará. Todos os computadores que podem executar os mesmos executáveis realmente têm o mesmo conjunto de códigos de operação; o conjunto x86 é o mais comum e é usado em praticamente todos os PCs atualmente. Outro comum é o MIPS, usado em vários consoles de jogos.
Draconis

1
@ TimHardly Se sua pergunta for, o montador pode perguntar à CPU qual é o seu código operacional para a instrução NOP, a resposta é não. O montador já precisa saber qual byte deve ser emitido para a instrução antes de poder funcionar. De fato, um montador pode emitir um programa para um processador, enquanto ele roda em um tipo de processador diferente.
Sr. Lister

11

"Parecer" implica uma metáfora. Se considerarmos "como será" literalmente, parecerá um pedaço de silicone gravado na sua placa-mãe. Claramente a metáfora era o objetivo. Para construir a metáfora, precisamos examinar o que realmente é o primeiro. Então podemos construir uma metáfora aceitável. Isso é um pouco longo, mas, felizmente, termina com uma metáfora de vídeo para você.

O código da máquina é realmente armazenado na memória como bits. Os chips de memória são tipicamente DRAM , que armazena esses bits como voltagens em um capacitor e elétrons. Os dois estão conectados - é difícil falar sobre as tensões sem os elétrons. Às vezes, é conveniente falar sobre um ou outro, mas entenda que onde um vai, o outro segue.

A jornada do código de máquina começa com uma "busca". Um padrão específico de voltagem é aplicado aos fios do chip de RAM, indicando que esse conjunto específico de bits deve ser enviado à CPU. Por quê? Não sei, não me importo. Normalmente, esse sinal é enviado porque a CPU terminou a última instrução e está solicitando uma nova como resposta instintiva, como um cachorro pedindo um segundo tratamento depois que você deu o primeiro. Esse processo começa com um chute primordial nas calças, causado por uma instabilidade natural na CPU. Quando uma fonte de alimentação aplica uma tensão constante ao chip, os aumentos de voltagem acabam levando a CPU a colocar as voltagens corretas nos chips de RAM para obter as primeiras instruções (estou acenando um pouco com a camada do BIOS, porque não é importante para a história.

A memória moderna transmite dados em paralelo. Isso significa que os bits que compõem o código da máquina são divididos em "faixas" (32 ou 64 são comuns), que é a maneira lógica de dizer os 32/64 fios da RAM para a CPU. A tensão nessas linhas é aumentada e diminuída conforme necessário para transmiti-la à CPU.

Uma vez na CPU, ele pode fazer seu trabalho. Esse é o domínio da microarquitetura e pode se complicar, porque é literalmente uma indústria de bilhões de dólares. Essas tensões afetam os transistores, que afetam outras tensões, de maneiras que podemos descrever como "adição de bits" ou "multiplicação". Na verdade, são apenas voltagens que representam esses bits, da mesma forma que podemos rabiscar a sequência de 5 caracteres "2 + 2 = 4" em um pedaço de papel e dizer que fizemos matemática. O grafite a lápis não é o número dois. É apenas a representação física que estamos usando para esse número.

Então é isso que o sistema real faz, em um nível tremendamente alto. Eu pulei bem ... praticamente tudo ... mas é decente o suficiente para poder voltar à sua pergunta real. Como seria [metaforicamente]?

Por acaso, acho que Martin Molin pode ter construído a melhor metáfora, com sua máquina de mármore . O código da máquina é codificado (manualmente) em algumas tiras da Lego Technics no meio como pinos, em vez de tensões em um capacitor. É mais como EPROM do que DRAM, mas ambos mantêm dados. Os mármores são como os elétrons, sendo movidos por tensões (ou gravidade, no caso dos mármores). E à medida que os elétrons se movem, eles aplicam força aos portões que fazem as coisas.

Sua máquina é simples, comparada a uma CPU moderna, mas não é tão ruim assim, tanto quanto as metáforas. E é cativante!


1
A máquina de mármore é muito simples para isso no vídeo. Uma CPU precisa de estado.
Thorbjørn Ravn Andersen

@ ThorbjørnRavnAndersen True. Suponho que, se a máquina de mármore tivesse alguns portões que permitissem abrir as alavancas automaticamente, em vez de Marin ter que girá-las, estaria mais perto.
Cort Ammon - Restabelece Monica

Obrigado! Semelhante à pergunta que eu fiz na resposta acima desta, o código de montagem montado seria considerado código de máquina que é traduzido em tensões e outras coisas?
Tim Quase

@ TimHardly Usando os únicos significados para "montado", "Montagem" e "Código da máquina", o produto da montagem da montagem é definido como código da máquina (então sim, pode ser considerado que =)). Algo que pode ajudar é que tanto a montagem quanto o código da máquina são considerados conceitos "lógicos", mais próximos do conceito matemático de "2 + 2 = 4" e mais distantes da grafite no papel no qual essa equação é escrita. Montagem / código de máquina é montagem / código de máquina, esteja ela sendo armazenada em um disco magnético, gravada em um pedaço de papel ou armazenada em capacitores na DRAM.
Cort Ammon - Restabelece Monica

1
Se eu puder ser filosófico, código de máquina é código de máquina, porque nós o tratamos como código de máquina. Nós pensamos nisso como código de máquina. Eu posso apontar uma CPU para os bytes que descrevem um som no formato .wav, e ele realmente os executará como código de máquina. A execução resultante provavelmente não fará nada de útil (porque o som não foi construído para ser um código de máquina) e pode parar, mas pode ser executado.
Cort Ammon - Restabelece Monica

10

Confira este vídeo , em particular das 1:00 às 1:17. É exatamente assim que parece quando um programa está sendo executado em um computador. As duas linhas de luzes mostram o conteúdo atual do registro de endereço e do registro de dados. O PDP-11 não possui um registro de instruções, mas se houvesse um e houvesse luzes na frente para mostrar seu conteúdo, seria praticamente o mesmo. 16 luzes - algumas acesas, outras apagadas.

Se você realmente gostasse de luzes piscantes, poderia ter mais luzes para mostrar o conteúdo atual dos seis registros, o ponteiro da pilha, o contador de programa ... para 32768 luzes adicionais, você poderia ter uma luz para cada bit do cache. Você pode até ter uma luz para cada pedaço de memória ... mas isso realmente seria muitas luzes.

Este é um PDP11-70 que roda a 15,2 MHz e cada instrução leva cerca de 1,5 microssegundos para executar. O olho humano pode detectar alterações até 1/10 de segundo e, nesse período, o PDP-11 pode executar 60.000 instruções. Basicamente, tudo é um borrão.


Uau, esse é um bom exemplo, eu já vi outras pessoas assim, algo nesse sentido em que você pode ver luzes e outras coisas. youtube.com/watch?v=yOyaJXpAYZQ
Tim Hardly


6

Os projetistas de hardware que implementam e testam (e testam e testam) o processador realmente usam modelos visuais para ver o que seus projetos estão fazendo. A maioria (se não todas) as ferramentas de simulação HDL produzem vistas de onda de todos os registros e fios para permitir a depuração fácil. A captura de tela abaixo (tirada daqui ) mostra essas ondas do simulador VCS para um processador RISC-V executando algumas instruções.

Ondas DVE para RISC-V

Este é um exemplo bastante simples que mostra um pequeno subconjunto da lógica envolvida em um design de processador completo. Você pode abrir essas visualizações para todo o processador e assistir a propagação dos dados pela lógica. Se você deseja ver o código da máquina em execução, como mencionado, você pode observar as ondas do registro de instruções ou do barramento que o processador usa para ler as instruções na memória. A maioria dos visualizadores de ondas possui opções de visualização flexíveis para barramentos e registradores que permitem exibir seus valores como rótulos binários, hexadecimais, octais e até como enum. Em alguns, você pode até definir suas próprias funções para mapear padrões de bits para os valores exibidos.

Vale a pena notar que isso é apenas uma representação de uma simulação do processador. Não há como obter esses tipos de visualizações para um chip de processador já fabricado.


2

Imagine um cego tropeçando em um beco em construção. Em todos os lugares há buracos e fendas, então naturalmente ele deve cair. Não esse cego, pois ele tem um rolo de papel com instruções, quando esperar, quando se mover, para onde se mover e como manipular seu ambiente para chegar ao fim da estrada. É isso que é uma assembléia, uma lista de instruções seguidas cegamente - elas só fazem sentido para esse beco e para esse cego. Em teoria, você pode até reconstruir um modelo 3D apenas com as instruções (Descompilar).

Toda mudança na plataforma torna necessário recompilar as instruções para o cego. Você precisa conhecer o hardware (o layout do canteiro de obras), as instruções de intenção digitadas por humanos (código de alto nível) como "Quero que você pule todas as cercas que encontrar em uma fileira até ter 12 cercas atrás de você" e as habilidades dos cegos (CPU). Ele tem memória de curto prazo, a capacidade de fazer várias coisas ao mesmo tempo?

Tomar todas essas informações e forjar um rolo de instruções coerente é o trabalho do compilador.

Então, posso descrever a aparência de um programa? Não. Mas podemos descrever como seria executá-lo? Sim, seria como um salto e correr, como um espelho sem ver algo, seguindo uma lista precisa de instruções, onde quer que isso o leve.

Ao utilizar nosso site, você reconhece que leu e compreendeu nossa Política de Cookies e nossa Política de Privacidade.
Licensed under cc by-sa 3.0 with attribution required.