Qual a diferença entre um compilador, um interpretador e uma máquina virtual? Estou no caminho certo?

O que eu ACHO que sei:

Compilador é um software que decodifica um arquivo texto e gera um novo arquivo contendo instruções do processador.

Interpretador é um software que decodifica um arquivo texto de comandos escritos uma linguagem X ao mesmo tempo em que executa instruções do processador com base no que foi decodificado.

Máquina Virtual é um software que decodifica um arquivo texto de instruções de um processador ficíticio ao mesmo mesmo tempo em que executa instruções do processador real com base no que foi decodificado.

Sei que estou sendo muito simplista tentando descrever esses conceitos com um parágrago e que também ocorre compilação de partes do código dentro de máquinas virtuais e interpretadores mas gostaria de saber se estou no caminho certo para entender essas três coisas, por favor me corrijam e também adicionem o que acharem que preciso saber, obrigado.

maniero há 2 anos

Dá uma lida: https://www.tabnews.com.br/maniero/67b181b2-065d-4553-8505-babac914f06f

A máquina virtual decodifica alguma coisa, não precisa ser texto, geralmente não é.

A grosso modo você está certo. Claro que isso é uma simplificação, como já sabe.

Farei algo que muitos pedem para aprender a programar corretamente, gratuitamente. Para saber quando, me segue nas suas plataformas preferidas. Quase não as uso, não terá infindas notificações (links aqui).

julianolorenzato há 2 anos

Hum, li esse post e alguns links que estavam nele, e surgiram outras dúvidas. Interpretadores obrigatoriamente precisam usar máquinas virtuais na sua sua arquitetura? Máquinas virtuais obrigatoriamente recebem código de máquina como input? Pergunto isso pois no processo de entender mais sobre o assunto achei um blog post que ensinava a criar [este](https://github.com/julianolorenzato/simple-virtual-machine) exemplo simples de uma máquina virtual, e ela recebe código de máquina, fiquei pensando no que isso que eu construí difere de um interpretador, penso que os processos de compilação dentro do interpretador dao origem à um código de máquina X e este é usado como input de uma VM, é isso?

maniero há 2 anos

Interpretador puro não tem máquina virtual, porque se tiver ele é um compilador. Algumas pessoas chamam de interpretador quando você roda direto do fonte, mas estritamente falando ele não é. Nunca vi algo que especifique claramente que a VM precisa um *bytecode* (o nome correto do que você chama de código de máquina), mas eu entendo que deveria ser. Pode ter um mecanismo que tem um compilador e VM ligados e que rodam em conjunto, ou seja, pega o fonte, compila para o *bytecode* e então o roda. Esse é um assunto que tem muita confusão pela internet, então tem que tomar cuidado. Esse é um dos casos que eu pretendo falar mais e tentar mostrar algo mais correto (na verdade o que eu já respondi aqui é uma boa introdução e servirá de base para algo mais completo). O interpretador de verdade praticamente não existe mais. Não vi o que você fez, mas ele fica lendo e executando cada instrução? Por exemplo, se estiver em um laço, ele vai interpretar todas as vezes que passa por ele? Isso é a interpretação real. Se não faz isso, está fazendo uma compilação, porque está transformando o código fonte em algo (pode ser muita coisa) que aí é executado, isso não deixa de ser uma compilação, sob demanda, mas é. É o caso de JS, que em vez de gerar um *bytecode* para uma VM costuma gerar para o processador real da máquina. Se tem compilação não é interpretador, ainda que algumas pessoas o chamem assim.

kht há 2 anos

Compilador é um software que decodifica um arquivo texto e gera um novo arquivo contendo instruções do processador

O arquivo original não é necessariamente texto, assim como o resultado pode não ser específico do processador. Só para dar um exemplo rápido, escrevi aqui sobre como funciona em Java:

Inicialmente temos o código fonte (o arquivo .java). Ao compilá-lo, é gerado um arquivo .class, contendo o bytecode, que não deixa de ser "binário". Lembrando que aqui o termo "binário" geralmente quer dizer que "não é texto" - porque se formos levar ao pé da letra, tudo no computador vira binário no fim das contas (até texto), mas para o caso em questão, vamos considerar que binário é "um monte de bytes que não correspondem a um texto".

Ou seja, o .class já é um tipo de "binário". Ele contém o bytecode, que são as instruções que serão interpretadas pela máquina virtual (a JVM - Java Virtual Machine). Só que a JVM possui outro compilador (mais precisamente, um JIT - Just In Time compiler), que pode pegar trechos do bytecode e compilar novamente, gerando código de máquina específico da plataforma/sistema operacional no qual ela está rodando. Na verdade é mais complexo que isso, veja mais detalhes aqui.

Ou seja, a partir do código fonte, é gerado o bytecode (um tipo de arquivo "binário"), que por sua vez pode ser transformado em código de máquina nativo (dependente da plataforma/arquitetura/processador/sistema operacional/etc), e portanto é "outro binário".

Ou seja, o compilador Java trabalha com texto (o código fonte) e transforma em bytecode (instruções da JVM - a máquina virtual Java - que não são específicas de nenhum processador). E dentro da JVM tem outro compilador que não trabalha com texto, e sim com bytecode: é ele que converte o bytecode (que não é texto) para código específico do processador.

Pra complicar um pouco mais, existe ainda o transpilador, que também é chamado de "source to source compiler", ou seja, traduz código de uma linguagem para outra (converte texto para outro texto). Não deixa de ser um tipo específico de compilador. O exemplo mais famoso hoje é o TypeScript, cujo código é transpilado para JavaScript.

E como já dito por outros, hoje em dia as coisas estão mais complicadas e misturadas, em muitos casos é difícil traçar uma linha onde começa um e termina o outro. Como muita coisa na nossa área, os termos não possuem definições "oficiais", cada um usa de um jeito, e muitas fontes acabam chamando as coisas por nomes diferentes ou fazendo distinções que nem sempre se aplicam.