Modelos de Tradução no Projeto de Linguagens de Programação

Transcrição

1 Modelos de Tradução no Projeto de Linguagens de Programação FÁBIO FIGUEIREDO NASCIMENTO ALBERTO RÔMULO NUNES CAMPELO EsAEx Escola de Administração do Exército, Rua Território do Amapá, Nº 455, Pituba, Salvador BA, Brasil Resumo. Este artigo aborda as características e implicações referentes à escolha do modelo de tradução para o projeto e implementação de uma linguagem de programação. Aqui, são discutidos os conceitos mais relevantes sobre o assunto, enfocando a geração de código binário por compilação para diferentes máquinas alvo e suas diferentes formas de representação intermediária. Também é estudado o processo de tradução e execução de programas por interpretação. As duas propostas são amplamente discutidas e tipificadas, justificando as novas tendências das plataformas de desenvolvimento de software que têm como objetivo a disseminação de seus produtos entre as mais diversas plataformas de hardware existentes. Palavras-chaves: Compiladores, interpretadores, linguagens, RISC, CISC Abstract. This article approaches the referring characteristics and implications to the choice of the model of translation for the project and implementation of a programming language. Here, the concepts most excellent on the subject are argued, focusing the generation of binary code for compilation for different machines white and its different forms of intermediate representation. Also the process of translation and execution of programs for interpretation is studied. The two proposals widely are argued, justifying the new trends of the platforms of software development that have as objective the dissemination of its products between the most diverse existing platforms of the hardware. Key words: Compilers, interpreters, languages, RISC, CISC 1. Introdução O projeto e a implementação de tradutores para linguagens de programação sempre foi um tópico um tanto obscuro e misterioso no âmbito da Informática. O estudo do tema foi sempre atribuído a programadores extremamente experientes e a profissionais especializados em desenvolvimento de software básico. Nesses moldes, a sua discussão cabia apenas aos papas e a cientistas da computação! Sem dúvida, a construção de um tradutor real e funcional não é uma tarefa simples, principalmente no que se refere ao seu back end (módulo de geração de código utilizado em tradutores que utilizam a compilação). Este artigo focaliza de forma mais acurada essa fase do projeto, levantando essencialmente três aspectos polêmicos: portabilidade, performance e complexidade. De início, é feita uma rápida introdução aos conceitos essenciais de programa, processo e arquitetura de computadores onde o modelo de máquina multinível é brevemente discutido. Pavimentado o caminho inicial, é entabulada uma discussão sobre linguagens de programação de alto nível, modelos de tradução, linguagem de máquina, formas de representação do código gerado e um pouco sobre microcódigo, enfatizando as arquiteturas RISC/CISC e a diferença de comportamento que o módulo backend de um compilador deve ter ao mirar uma ou outra arquitetura de processador. A exigência, por parte dos programadores de aplicativos, em se ter plataformas de desenvolvimento cada vez mais amigáveis e integradas, tem sido o fator preponderante e fomentador para a criação de novos ambientes de desenvolvimento e de linguagens de programação baseadas em representação intermediária. As vantagens e desvantagens desta abordagem em relação à tradicional, que é a geração de código nativo para o processador de destino, são discutidas de forma neutra e estritamente técnica. Questões relacionadas à performance e portabilidade vêm à tona e um enfoque comparativo é dado aos dois modelos de projeto. 2. Programa Programa é um termo que designa tudo aquilo que pode ser seguido passo a passo. Um programa descreve, metodicamente, um conjunto de procedimentos e ações que visam atingir um objetivo específico. Programas dos mais variados tipos e propósitos estão a todo momento permeando as atividades diárias das pessoas e organizações. Desde os mais singelos programas de acompanhamento infantil,

2 passando por programas de combate à fome e à pobreza, chegando até os complexos programas computacionais, todos são uma espécie de receita que deverá ser seguida e executada por um indivíduo, uma organização ou uma máquina a fim de se obter um determinado resultado. Programa computacional é o tema central da discussão que se segue nas seções abaixo. 2.1 Programa Executável Aqueles acostumados aos jargões técnicos da informática costumam confundir o significado de programa e processo. Programa executável e processo não são a mesma coisa. Apesar de ser muito tênue a diferença entre eles, podemos facilmente conceituá-los. Pode-se dizer que programa executável é uma espécie de código binário (em se tratando de computadores binários) que pode ser executado pelo hardware alvo. Tal código deve estar, necessariamente, em repouso e localizado num meio de armazenamento de massa. Ele é o resultado final do processo de compilação sobre o conjunto de comandos e instruções de uma determinada linguagem de programação que faz uso da tradução para a geração de seu produto final. O processo de tradução deve, obrigatoriamente, gerar código de máquina para uma arquitetura de computador específica. Programa executável é também chamado de programa absoluto ou código absoluto. Linguagens que são interpretadas, ou linguagens cujos compiladores geram como produto final uma espécie de código intermediário, tais como o bytecode e o pcode, não produzem programas executáveis ou código absoluto e, sim, uma seqüência de códigos significantes que servirão de entrada para um outro programa que faz o papel de uma máquina de nível mais alto, uma máquina virtual. O conceito de máquina virtual será melhor esclarecido quando do estudo de máquinas multinível, num capítulo mais adiante. 2.2 Processo Quando o sistema operacional retira um programa do seu repouso, isto é, quando o sistema cria na memória uma imagem do programa que está em disco e esta imagem está pronta para ser submetida ao processador, ele acabou de criar um processo. 2.3 Visão Clássica Na visão clássica da literatura computacional processo é um programa em execução juntamente com seu contexto de hardware e estruturas de gerenciamento. É a atividade do processador em executar um determinado conjunto de instruções descritas através de um programa (Tanembaum e Woodhull, 2000). 2.4 Visão do Sistema Operacional Um processo, na visão do sistema operacional, é um trecho de código limitado quanto ao seu objetivo e função, que possui informações de controle associadas tais como identificador, usuário, tempo de execução e outras informações a despeito do seu ciclo de vida. 2.5 Visão do Processador Um processo, na perspectiva do processador, é uma seqüência de códigos executáveis que se encontram no nível convencional de máquina. A título de ilustração, pode-se imaginar um código escrito em uma linguagem L2. Essa linguagem pode ser interpretada pela camada de microcódigo (firmware) escrita em linguagem L1 (supondo ser uma máquina CISC cuja característica de projeto é a existência de microcódigo) e esta, finalmente, pode ter suas instruções executadas diretamente pelos circuitos eletrônicos da CPU. O estudo da arquitetura e o funcionamento detalhado das CPUs dos computadores modernos fogem ao escopo deste trabalho, mas, de forma bastante simplificada, todas elas podem ser vistas como máquinas multinível. Logo a seguir, ainda neste capítulo, falar-se-á mais a respeito de máquina multinível. 3. Máquina Multinível Um computador pode ser visto como um conjunto de computadores virtuais (a partir de agora serão chamados de máquina ou camada) organizados através de níveis hierárquicos onde cada camada guarda estreita intimidade e apenas se relaciona com a camada subjacente. Cada uma dessas máquinas possui seu próprio conjunto de instruções ou linguagem, e apenas a máquina no nível 1 (um), que possui código em linguagem L1, pode ter suas instruções executadas diretamente pelos circuitos eletrônicos, estes situados no nível 0 (zero), o nível da lógica digital. Nos níveis superiores, a comunicação entre uma máquina e outra é feita através da tradução ou interpretação do programa que está numa camada mais alta (linguagem de mais alto nível e mais complexa) para um programa em linguagem de nível mais baixo e, portanto, mais simples e que a camada subjacente pode executar. É comum hoje em dia que os computadores modernos sejam projetados e vistos como máquinas de 6 (seis) níveis, estando estes no intervalo de 0 (zero) a 5 (cinco), onde cada nível n possui a sua linguagem Ln. O método como cada nível é implementado pode diferir entre as diversas arquiteturas, mas um modelo bastante usual é o de se projetar a máquina de nível 1 (um - nível de microprogramação ou firmware) com uma linguagem L1, para ter suas instruções diretamente executadas pela circuitaria eletrônica que é o nível 0 (zero). Os níveis 2 (dois nível de máquina convencional) e 3 (três) com L2 e L3, respectivamente, são

3 interpretados pelas suas camadas subjacentes e, finalmente, os níveis 4 (quatro) e 5 (cinco) com L4 e L5, respectivamente, são geralmente traduzidos. Figura 1:Camadas de uma máquina multinível (adaptado Tanenbaum) 4. Linguagens de Programação de Alto Nível Linguagens de alto nível são assim chamadas aquelas linguagens de programação (LPs) cuja construção de sua gramática é muito próxima a da gramática de uma linguagem humana. O entendimento de sua estrutura léxica e sintática é favorecido devido à proximidade de sua unidade morfológica com aquela utilizada nos diversos idiomas existentes (Português, Inglês e outros mais). No outro extremo, temos as linguagens de baixo nível, mais comumente conhecidas como linguagens de montagem (Assembly language), cuja sintaxe é menos amistosa para os programadores e, entretanto, muito próxima da linguagem de máquina que o hardware realmente entende. Estudar-se-á mais sobre linguagem de máquina numa seção subsequente e totalmente dedicada a ela. Não se deve confundir o entendimento do código fonte do programa com o entendimento da sintaxe da linguagem com a qual ele foi escrito. Esta última guarda estreita relação com a língua cujo idioma inspirou a gramática da linguagem em questão, enquanto o primeiro refere-se à lógica de programação utilizada pelo programador durante a confecção do programa. Pode-se observar na figura 1 que as linguagens de programação de alto nível ocupam o nível 5 (cinco) na pirâmide de software. São, portanto, linguagens L5. Tal fato quer dizer que elas estão mais distantes do hardware do que uma linguagem L4 ou L3 por exemplo. Os termos alto nível e baixo nível, em informática, de forma alguma fazem alusão a classes sociais, a padrões financeiros ou a níveis de inteligência e perspicácia que um programador deve ter ao programar em uma determinada linguagem. A maioria das pessoas manifesta esse tipo entendimento ao ouvir esses termos pela primeira vez. Estão enganadas. Diferentemente de como o leigo em informática percebe tais conceitos, alto e baixo nível estão apenas apontando o andar em que uma determinada linguagem de programação se encontra na pirâmide de software (observe a figura 1). Quanto mais baixo for esse andar, mais próximo estarão suas instruções daquilo que a máquina física realmente entende. Quanto mais alto for o andar, mais próximo da compreensão humana estará a estrutura da linguagem. LPs deste tipo são também conhecidas como linguagens de programação orientadas a problemas e sua origem está diretamente ligada à explosão da informática como ferramenta de automação e solução de problemas no âmbito das organizações. Devido à disseminação dos sistemas eletrônicos (principalmente dos microcomputadores) nas mais diversas organizações, gerou-se a necessidade de se obter soluções particulares que atendessem a problemas específicos e inerentes ao objeto de negócio e à razão social de cada uma dessas entidades. Diversas linguagens, então, foram desenhadas com o intuito de atender a tais necessidades, direcionando seu projeto de forma a contemplar os anseios de analistas de sistemas e de programadores envolvidos na solução do problema. É comum, nos dias de hoje, encontrar-se plataformas de desenvolvimento especialmente projetadas para assistir a uma gama de atividades diferentes que são estão se desenrolando no cotidiano das organizações: linguagens comerciais voltadas à automação comercial, linguagens científicas para o tratamento de rotinas matemáticas e automação industrial, linguagens direcionadas para os paradígmas da IA e linguagens de script, muito utilizadas na internet, são alguns exemplos de famílias de LPs especialmente desenvolvidas a fim de promover uma melhor interação, adaptação e aceitação dos profissionais imbuídos na solução de um determinado problema contando com o auxílio da ferramenta mais apropriada. Não é objetivo deste artigo discorrer sobre uma linguagem de programação específica e, sim, sobre os conceitos básicos de arquitetura e desenho de LPs focalizando, principalmente, os modelos utilizadas para se construir o código gerado pelo processo de tradução dessas linguagens. Visto isso, faz-se mister acrescentar que as LPs de alto nível gozam de características similares no que diz respeito a sua interface com o usuário e características de processamento. Tais linguagens possuem grande interoperabilidade, fornecendo ao usuário um ambiente de desenvolvimento bastante amigável. A sintaxe é geralmente clara permitindo um alto grau de legibilidade do código fonte. Seus comandos são concisos, poderosos e, através de poucas linhas de codificação, gera-se grande processamento computacional.

4 Tais caraterísticas, extremamente desejáveis para os usuários, geram certo desconforto para o compilador da linguagem e perda de performance do programa final devido a redundâncias no código gerado. Tais redundâncias, geralmente, são provenientes de uma tradução/interpretação não otimizada. Quanto maior for o desnível entre a linguagem fonte e a linguagem alvo (Ln -> Ln-m onde m é o número de níveis que uma linguagem dista da outra) mais penoso será o processo de geração de código e passível de falhas na otimização. Numa seção mais à frente, dar-se-á início ao estudo dos dois modelos utilizados pelos projetistas de linguagens na implementação dos módulos de geração de código dos seus tradutores. O processamento do texto fonte de um programa computacional (a tradução) pode ser por compilação ou por interpretação. Ambas as abordagens são essencialmente diferentes e as características de cada uma delas bem como suas implicações serão abordadas em subseções específicas. 4.1 Performance das LPs de Alto Nível Ao se tratar de um tema tão polêmico, costuma-se associá-lo à velocidade de um determinado programa quando de sua execução. Sem dúvida tal questão é de suma importância e a ela freqüentemente é dado um enfoque mais abrilhantado quando ocorrem discussões a respeito do tema. Apesar disso, vale ressaltar que o tamanho do código gerado também é um fator impactante na performance e que, tanto ele quanto a velocidade de execução do programa, são resultados do trabalho do otimizador de código que é um componente intrínseco do módulo de geração de código do tradutor. Um outro aspecto, também de grande importância e que impacta diretamente no parâmetro velocidade de execução, é o processo pelo qual se dá a tradução do programa, se por compilação ou interpretação. Face à tamanha importância do assunto e devido as especificidades individuais inerentes aos supracitados processos de tradução, cada um deles será estudado numa subseção dedicada e específica. 4.2 LPs Compiladas Uma linguagem de alto nível por ter seus comandos muito distantes daquilo que o computador realmente entende como instruções de máquina, exige um grande esforço do compilador durante o processo de tradução. Todo o fluxo sintático da linguagem, com suas ricas construções de alto nível, estruturas de controle de fluxo avançadas e condicionais aninhadas que permitem uma lógica poderosa, devem ser traduzidas e transformadas em instruções ordinárias no nível convencional de máquina. Tais instruções, muito mais simples, são inteligíveis para o hardware. Durante o processo de tradução por compilação, um único comando de uma determinada linguagem de alto nível é comumente traduzido em algumas dezenas de instruções de máquina. Em se tratando de algumas arquiteturas de máquinas específicas, cujo projeto dispensa a camada de microcódigo (arquitetura RISC, por exemplo), o esforço de tradução é ainda maior. O gerador de código é o módulo do compilador responsável por essa tradução. No transcorrer do seu trabalho, nem sempre o resultado é o melhor possível. É bastante comum que, nesta fase, o gerador de código gere como subproduto um código não otimizado e calamitosamente redundante. É nesse ponto que entra em cena a importante figura do otimizador de código. A missão primordial do módulo otimizador é eliminar instruções redundantes e utilizar de uma forma mais eficiente os registradores e recursos da CPU. Tendo em vista a grande complexidade semântica de um programa escrito numa LP de alto nível, até mesmo o módulo otimizador, por vezes, sucumbe perante a tentativa de refinamento do código semi-acabado. Fica claro então, deste modo, que nada nem mesmo o módulo otimizador de código pode garantir um produto final ótimo, mas apenas um pouco melhorado. Em realidade, o que ocorre mais comumente é que um determinado trecho de código, originalmente escrito em uma LP de alto nível, ao ser traduzido e transformado em produto final, este último, provavelmente, não vai refletir a melhor opção em termos de código eficiente. 4.3 LPs Interpretadas São chamadas de interpretadas aquelas linguagens de programação cujo texto fonte do programa é traduzido através da interpretação. Neste modelo, o interpretador da linguagem analisa cada comando encontrado no texto fonte em tempo de execução. O interpretador segue o fluxo (stream) ordinário do programa, conforme ditado pela lógica do programador. É importante perceber que, na interpretação, existe uma tradução significativa e não física, ou seja, cada comando do código fonte do programa é analisado, interpretado e é gerada uma saída para ele como resultado final. Tal saída é destinada ao usuário do sistema e não ao hardware, e é aí que encontramos o grande divisor de águas entre a interpretação e a compilação. Na compilação, podese dizer que a tradução é física e na interpretação a tradução é significativa. No processo de interpretação, fica em evidência a considerável lentidão do processo. O fato de que cada comando é interpretado passo a passo em tempo de execução imprime um declínio de performance em relação à compilação, onde os comandos do texto fonte já estão, por assim dizer, traduzidos fisicamente e armazenados num arquivo executável. Na interpretação, a tradução é intrínseca ao processo e só é utilizada durante a execução do programa que é feita diretamente do seu texto fonte. Após isso, todo o trabalho realizado bem como as estruturas utilizadas durante a análise são descartadas e nenhum arquivo executável é gerado. A cada

5 solicitação de execução de um programa confeccionado em uma linguagem de programação interpretada, todo o processo de interpretação é disparado. Linguagens de programação interpretadas são pouco utilizadas para a confecção de programas, principalmente quando o objetivo final é se ter um aplicativo rápido e adaptado a uma plataforma específica. O principal destino dos interpretadores ficou a cabo dos programas de script, que podem ser rodados para setar algumas configurações numa máquina local ou até mesmo num ambiente corporativo onde servidores webs podem prover grande capacidade de processamento aos seus usuários através de módulos que interpretam scrips. 5. Linguagens de Montagem Linguagens de montagem guardam uma relação um para um com a linguagem de máquina. Seus mnemônicos aparecem no texto fonte uma linha por vez e cada instrução simbólica é traduzida diretamente numa seqüência de bits (em computadores binários) que representam uma instrução de máquina. Sua utilização foi extremamente difundida nos primórdios da computação onde, logo, os cientistas perceberam que era mais produtivo representar as instruções numéricas do hardware através de curtas abreviaturas literais. Tais abreviaturas ficaram conhecidas como mnemônicos e vieram substituir com vantagem a desgastante utilização dos primeiros computadores cuja programação era realizada através de chaves seletoras, constantes em grandes painéis, com a função de ligar ou desligar um circuito. Linguagens de montagem ficaram conhecidas como linguagem Assembly (do inglês, assembly = montar) e seus tradutores são universalmente conhecidos como assemblers (assembler = montador). Hoje em dia, a linguagem Assembly é de uso exclusivo dos programadores de software básico, mais especificamente dos desenvolvedores de sistemas operacionais, que a utilizam para confeccionar os módulos do projeto onde a velocidade de execução é questão essencial. Fica claro, através das próprias características da linguagem e pela sua aplicação direcionada a performance, que o Assembly não deve ser jamais interpretado e, sim, compilado. No mundo dos programadores Assembly costuma-se usar como jargão o termo montador em vez de compilador para se denotar o tradutor da linguagem. PCode e o ByteCode são dois exemplares, bastante difundidos entre as plataformas de desenvolvimento, que foram concebidos através desta abordagem. As softwarehouses tiram grande proveito deste modelo de representação de código, visto que ele permite o desenvolvimento e a disseminação de softwares pelas mais diversas arquiteturas de computadores existentes no mercado. O PCode e o Bytecode consistem em uma espécie de representação intermediária de código em relação ao hardware real, ou seja, tal representação é de mais baixo nível que o código fonte do programa, porém de mais alto nível do que a linguagem da máquina física. Também, pode-se dizer que o PCode e o ByteCode representam o código final para uma máquina virtual de nível mais elevado que a máquina física. Este paradigma baseia-se no conceito de máquina multinível esplanada na subseção 2.4. (ver figura 1). No modelo de máquinas em camadas, a representação intermediária de código é, então, direcionado a uma máquina de nível m onde m é um nível qualquer, porém mais alto que o nível do hardware. Pode-se dizer que m é uma máquina virtual de linguagem Lm. A linguagem Lm recebe, de acordo com o seu desenvolvedor, um nome de batismo e este, geralmente, se torna bastante difundido comercialmente. Como foi citado anteriormente, alguns exemplos reais são o ByteCode e o PCode que são o produto final de alguns compiladores de linguagens de programação bastante difundidas no mercado. Ambos, o PCode e o ByteCode, são exemplos de código de máquina de nível m que deverão ser executados por uma máquina virtual também de nível m que entenda a linguagem Lm Representação de Código É muito comum, hoje em dia, que os compiladores de linguagem de programação gerem, como produto final, um código que não é inteligível pelo hardware alvo, aliás, tal proposta objetiva justamente a independência e a portabilidade do software. O

6 Figura 2: Relacionamento entre os diversos níveis 7. Microcódigo CISC x RISC É muito comum, em algumas arquiteturas de computadores, ter-se nos níveis mais altos da pirâmide de software (ver figura 1) o código gerado pelo processo de compilação e na base da pirâmide por interpretação. É usual que projetistas de hardware coloquem, como substrato do patamar mais baixo da pirâmide, uma camada de código conhecida como microcódigo. Tais arquiteturas são comumente conhecidas como arquiteturas CISC (Complex Instruction Set Computers Computadores com Conjunto de Instruções Complexas). Esta é uma forma de facilitar e abreviar a confecção dos compiladores de linguagens de programação. Através deste modelo, o código gerado para o nível de Máquina Convencional (L2 ver figura 1) é, ainda, mais complexo do que aquele código que a circuitaria eletrônica do hardware realmente entende e pode executar. As instruções contidas em L2, via de regra, são maiores e possuem uma semântica mais evoluída. É comum, em L2, encontrar-se instruções de indexação, loops e deslocamentos dentro de tabelas contidas em memória (offset). SCASB, MOVSD e XLAT são exemplos de mnemônicos dessas instruções em Assembly Intel. Essa foi a abordagem que os projetistas utilizaram para incentivar a criação de novas linguagens de alto nível que atendessem ao gosto popular, ou seja, que ajudassem a disseminar as novas máquinas produzidas entre novos usuários. Abaixar o nível da linguagem estava fora de questão já que a dificuldade em programação associada à tais linguagens impedia a aquisição de novos usuários. A solução estava em elevar o nível da linguagem de máquina criando-se, então, o microcódigo. Surgia aí a arquitetura CISC, resultado proveniente da perfeita compreensão sobre o processo de modularização que o modelo de máquina multinível pode trazer juntamente com uma apurada visão comercial que, como o presente nos mostra, teve absoluto sucesso através da propagação de máquinas CISC entre os mais diversos ambientes, inclusive atingindo quase a totalidade dos usuários domésticos na América do Sul e América do Norte. Desenvolvendo-se compiladores para máquinas CISC, os projetistas de linguagens precisam apenas mirar uma máquina mais adaptável e dócil. O código gerado por tais linguagens é perfeitamente compatível com o nível L2. São justamente os valores em binário (para máquinas binárias) e as diretrizes, que devem ser utilizadas para a confecção deste código, que são fornecidos pelo projetista de hardware ao projetista de software em vez da linguagem de sua máquina física (L1) propriamente dita. Em máquinas onde não existe a camada de microcódigo a camada L2 passa a ser L1 e esta se torna a linguagem de máquina propriamente dita que será executada pelos circuitos digitais. A arquitetura de hardware baseada neste modelo é conhecida como arquitetura RISC (Reduced Instruction Set Computer Computador com Conjunto de Instruções Reduzidas) O código gerado pelos compiladores de linguagens de programação, projetado para máquinas RISC, goza de simplicidade e de grande desempenho de execução. Faz-se mister ressaltar que tal simplicidade, alcançada como uma característica do produto final, exige grande complexidade e esforço de processamento durante sua confecção. A idéia de ter-se que produzir instruções extremamente simples, provenientes de um texto fonte de alto nível com sintaxe e semântica geralmente muito complexas, não é nada trivial. O esforço de programação para produzir tais compiladores sem dúvida é muito maior na arquitetura RISC do que aqueles direcionados para a arquitetura CISC. O analisador léxico e o parser podem ser praticamente iguais entre as duas arquiteturas (frontend). A diferença crucial consiste na confecção do gerador de código (backend). Este, na arquitetura RISC, deve ser muito mais robusto, pois, constantemente, executa um trabalho de processamento muito maior. Tais características exigem um grande esforço por parte daqueles que que possuem a missão de projetar e implementar geradores de código para máquinas RISC. Por outro lado, a grande vantagem dos computadores RISC reside no desempenho superior do código final gerado. É fácil perceber que, sem a camada intermediária de microcódigo, o programa é realmente executado pelos circuitos eletrônicos do hardware. 8. Conclusão A exigência, por parte das softwarehouses especializadas em desenvolvimento de plataformas de programação, de terem seus produtos difundidos da maneira mais ampla possível tem levado muitos empreendedores da informática a abraçarem o modelo de Máquina Multinível.

7 Tal fato reside na percepção, por parte do desenvolvedor, de que é apenas necessário reprojetar um módulo de seus produtos para que estes se tornem perfeitamente adaptáveis a uma gama de plataformas de máquinas diferentes. O modelo de representação intermediária de código veio trazer a solução para aqueles que desejam implementar soluções baseadas no paradigma de Máquina Multinível. Através dele é possível perceber, hoje em dia, resultados já consolidados e difundidos por grandes organizações que se utilizam da representação intermediária de código e de máquinas virtuais para executar seus aplicativos (Visual Basic, Java e tantas outras baseadas no PCode E ByteCode). Um outro paradigma que hoje vem se ajustando naturalmente às necessidades dos projetistas de linguagem de programação, é quanto ao modelo de tradução, se por compilação ou interpretação. No início, quando a utilização do computador de forma isolada ditava a norma, difundiu-se muito a utilização de linguagens compiladas onde o ganho de desempenho era maior e não se exigia muita portabilidade do software, visto que cada usuário executava um processamento estanque e local a sua máquina de trabalho. Com a evolução dos conceitos de cooperativismo em informática e conectividade, tais exigências caíram por terra em detrimento de outras, agora, emergentes. O processamento distribuído tomou grande vulto e o fortalecimento das telecomunicações permitiu grande evolução da tecnologia web. Tal tecnologia ajudou a fomentar o surgimento em massa de linguagens interpretadas, sejam elas em forma de poderosas ferramentas para construção e interpretação de páginas (Ex: Php) bem como analisadores de scripts SQL para o acesso a banco de dados, ambos mantidos em robustos servidores webs ou como simples geradores de telas e interpretadores HTML. A pirâmide de software, baseada no modelo de Máquina Multinível, não é tão moderna, datando da década de 40 quando os computadores digitais tinham apenas dois níveis: o de máquina convencional, onde toda programação era realizada (e, de certa forma, serviam como expiação aos programadores devido a sua tamanha complexidade), e o de lógica digital, que era constituída de complicados circuitos eletrônicos responsáveis por executar as instruções. Mesmo nos dias atuais, ficam evidentes que os conceitos associados ao modelo de Máquina Multinível permeiam, de forma cada vez mais intensa, as novas tendências e tecnologias emergentes. O modelo de Máquina Multinível permite que máquinas sejam projetadas com um número cada vez maior de camadas (níveis), o que permite uma maior flexibilidade de execução, especialização de suas funções e, por que não dizer, um maior direcionamento de recursos humanos em informática, mais apropriados a desenvolver suas atividades em um determinado nível. 9. Fontes Bibliográficas MAK, Ronald. Writing Compilers and Interpreters. 2th ed. United States of America: John Wiley & Sons, Inc. TANENBAUM, Andrew S. Organização Estruturada de Computadores. Tradução de Hélio Marques Sobrinho e Luiz Fernando Costa; revisão técnica Flávia de Castro M. Marques. 3.ed. Rio de janeiro: LTC Livros Técnicos e Científicos Editora, p.