Porting - Porting

Em engenharia de software , portar é o processo de adaptação de software com o objetivo de alcançar alguma forma de execução em um ambiente de computação diferente daquele para o qual um determinado programa (destinado a tal execução) foi originalmente projetado (por exemplo, CPU diferente , sistema operacional ou biblioteca de terceiros ). O termo também é usado quando o software / hardware é alterado para torná-los utilizáveis ​​em ambientes diferentes.

O software é portátil quando o custo de portá-lo para uma nova plataforma é significativamente menor do que o custo de gravá-lo do zero. Quanto menor o custo de portar software em relação ao custo de implementação, mais portátil é considerado.

Etimologia

O termo "porto" é derivado do latim portāre , que significa "transportar". Quando o código não é compatível com um determinado sistema operacional ou arquitetura , o código deve ser "transportado" para o novo sistema.

O termo geralmente não é aplicado ao processo de adaptação de software para rodar com menos memória na mesma CPU e sistema operacional, nem é aplicado à reescrita do código-fonte em um idioma diferente (isto é, conversão ou tradução de idioma).

Os desenvolvedores de software freqüentemente afirmam que o software que escrevem é portátil , o que significa que pouco esforço é necessário para adaptá-lo a um novo ambiente. A quantidade de esforço realmente necessária depende de vários fatores, incluindo até que ponto o ambiente original (a plataforma de origem ) difere do novo ambiente (a plataforma de destino ), a experiência dos autores originais em saber quais linguagens de programação constroem e terceiros as chamadas da biblioteca dificilmente serão portáteis e a quantidade de esforço investida pelos autores originais em apenas usar construções portáteis (construções específicas de plataforma frequentemente fornecem uma solução mais barata).

História

O número de CPUs e sistemas operacionais significativamente diferentes usados ​​no desktop hoje é muito menor do que no passado. O domínio da arquitetura x86 significa que a maioria dos softwares de desktop nunca é portada para uma CPU diferente. Nesse mesmo mercado, a escolha de sistemas operacionais foi efetivamente reduzida para três: Microsoft Windows , macOS e Linux . No entanto, nos sistemas embarcados e nos mercados móveis , a portabilidade continua sendo um problema significativo, com o ARM sendo uma alternativa amplamente utilizada.

Os padrões internacionais, como os promulgados pela ISO , facilitam muito a portabilidade, especificando detalhes do ambiente de computação de uma forma que ajuda a reduzir as diferenças entre as diferentes plataformas em conformidade com os padrões . Escrever software que permaneça dentro dos limites especificados por esses padrões representa um esforço prático, embora não trivial. Portar tal programa entre duas plataformas em conformidade com os padrões (como POSIX.1 ) pode ser apenas uma questão de carregar o código-fonte e recompilá- lo na nova plataforma. No entanto, os profissionais geralmente descobrem que várias correções menores são necessárias, devido a sutis diferenças de plataforma. A maioria dos padrões sofre de "áreas cinzentas", onde diferenças na interpretação dos padrões levam a pequenas variações de plataforma para plataforma.

Também existe um número cada vez maior de ferramentas para facilitar a portabilidade, como o GNU Compiler Collection , que fornece linguagens de programação consistentes em diferentes plataformas, e Autotools , que automatiza a detecção de pequenas variações no ambiente e adapta o software de acordo antes da compilação .

Os compiladores para algumas linguagens de programação de alto nível (por exemplo , Eiffel , Esterel ) ganham portabilidade gerando código-fonte em outra linguagem intermediária de alto nível (como  C ) para a qual compiladores para muitas plataformas estão geralmente disponíveis.

Duas atividades relacionadas a (mas distintas de) portabilidade são emulação e compilação cruzada .

Portando compiladores

Em vez de traduzir diretamente para o código de máquina , os compiladores modernos traduzem para um código intermediário independente da máquina para aumentar a portabilidade do compilador e minimizar os esforços de design. A linguagem intermediária define uma máquina virtual que pode executar todos os programas escritos na linguagem intermediária (uma máquina é definida por sua linguagem e vice-versa). As instruções de código intermediário são traduzidas em sequências de código de máquina equivalentes por um gerador de código para criar código executável . Também é possível pular a geração de código de máquina implementando de fato um interpretador ou JIT para a máquina virtual.

O uso de código intermediário aumenta a portabilidade do compilador, porque apenas o código dependente da máquina (o interpretador ou o gerador de código) do próprio compilador precisa ser portado para a máquina de destino. O restante do compilador pode ser importado como código intermediário e depois processado pelo gerador de código portado ou interpretador, produzindo assim o software do compilador ou executando diretamente o código intermediário no interpretador. A parte independente da máquina pode ser desenvolvida e testada em outra máquina (a máquina host ). Isso reduz muito os esforços de projeto, porque a parte independente da máquina precisa ser desenvolvida apenas uma vez para criar o código intermediário portátil.

Um interpretador é menos complexo e, portanto, mais fácil de portar do que um gerador de código, porque ele não é capaz de fazer otimizações de código devido à sua visão limitada do código do programa (ele vê apenas uma instrução por vez, e você precisa de uma sequência para fazer otimização). Alguns intérpretes são extremamente fáceis de portar, porque eles fazem apenas suposições mínimas sobre o conjunto de instruções do hardware subjacente. Como resultado, a máquina virtual é ainda mais simples do que a CPU de destino.

Escrever as fontes do compilador inteiramente na linguagem de programação que o compilador deve traduzir, torna a seguinte abordagem, mais conhecida como bootstrapping do compilador , viável na máquina de destino:

  1. Transfira o intérprete. Isso precisa ser codificado em código assembly , usando um assembler já presente no destino.
  2. Adapte a fonte do gerador de código à nova máquina.
  3. Execute a fonte adaptada usando o interpretador com a fonte do gerador de código como entrada. Isso irá gerar o código de máquina para o gerador de código.

A parte difícil de codificar as rotinas de otimização é feita usando a linguagem de alto nível em vez da linguagem assembly do destino.

Segundo os projetistas da linguagem BCPL , o código interpretado (no caso da BCPL) é mais compacto do que o código de máquina; normalmente por um fator de dois para um. O código interpretado, entretanto, é executado cerca de dez vezes mais lento do que o código compilado na mesma máquina.

Os designers da linguagem de programação Java tentam tirar vantagem da compactação do código interpretado, porque um programa Java pode precisar ser transmitido pela Internet antes que a execução possa começar na Java Virtual Machine do destino .

Transferência de videogames

Portar também é o termo usado quando um videogame projetado para rodar em uma plataforma, seja um fliperama , console de videogame ou computador pessoal , é convertido para rodar em uma plataforma diferente, talvez com algumas pequenas diferenças. Do início dos videogames até a década de 1990, as "portas", na época conhecidas como "conversões", muitas vezes não eram portas verdadeiras, mas versões retrabalhadas dos jogos devido às limitações de diferentes sistemas. Por exemplo, o jogo de 1982, O Hobbit , uma aventura de texto aumentada com imagens gráficas, tem estilos gráficos significativamente diferentes em toda a gama de computadores pessoais para os quais suas portas foram desenvolvidas. No entanto, muitos videogames do século 21 são desenvolvidos usando software (geralmente em C ++ ) que pode produzir código para um ou mais consoles, bem como para um PC, sem a necessidade de transferência real (em vez disso, depende da transferência comum de bibliotecas de componentes individuais ).

Transferir jogos de arcade para sistemas domésticos com hardware inferior era difícil. A versão portada do Pac-Man para o Atari 2600 omitiu muitas das características visuais do jogo original para compensar a falta de espaço ROM e o hardware teve dificuldades quando vários fantasmas apareceram na tela criando um efeito de cintilação. O fraco desempenho do Atari 2600 Pac-Man é citado por alguns estudiosos como a causa da queda do videogame em 1983 .

Muitas portas anteriores sofreram problemas significativos de qualidade de jogo porque os computadores eram muito diferentes. Richard Garriott declarou em 1984 na Origins Game Fair que a Origin Systems desenvolveu jogos de computador para a série Apple II primeiro e depois os portou para o Commodore 64 e Atari 8-bit , porque os sprites das últimas máquinas e outros recursos sofisticados foram transferidos deles para a Apple " muito mais difícil, talvez até impossível ". As resenhas reclamaram de portos que sofriam de "conversão da Apple", mantendo o "som ruim e gráficos preto-branco-verde-roxo da Apple"; após a declaração de Garriott, quando Dan Bunten perguntou "Atari e Commodore pessoas na platéia, você está feliz com as reescritas da Apple?" o público gritou "Não!" Garriott respondeu: "[de outra forma] a versão da Apple nunca será concluída. Do ponto de vista de um editor, isso não é uma questão de dinheiro".

Outros trabalharam de forma diferente. Ozark Softscape , por exemplo, escreveu MULE para o Atari primeiro porque preferiu desenvolver para os computadores mais avançados, removendo ou alterando recursos conforme necessário durante a portabilidade. Essa política nem sempre foi viável; Bunten afirmou que "MULE não pode ser feito por uma Apple", e que as versões não-Atari de As Sete Cidades de Ouro eram inferiores. O Compute! 'S Gazette escreveu em 1986 que ao portar do Atari para o Commodore, o original era geralmente superior. A qualidade dos jogos deste último melhorou quando os desenvolvedores começaram a criar um novo software para ele no final de 1983, afirmou a revista.

Ao portar jogos de arcade , os termos "arcade perfeito" ou "arcade preciso" costumavam ser usados ​​para descrever o quanto a jogabilidade, os gráficos e outros recursos da versão portada combinavam com a versão de arcade. Muitas portas de arcade no início da década de 1980 estavam longe de ser perfeitas, pois os consoles e computadores domésticos não tinham o hardware sofisticado dos jogos de arcade, mas os jogos ainda podiam se aproximar da jogabilidade. Notavelmente, Space Invaders no Atari VCS se tornou o console killer app apesar de suas diferenças, enquanto a posterior Pac-Man porta era notório por seus desvios em relação à versão arcade. Os jogos de arcade precisos tornaram-se mais prevalentes a partir da década de 1990, começando com o sistema Neo Geo da SNK , que oferecia um console doméstico e um sistema de arcade com versões mais avançadas do hardware principal do console doméstico. Isso permitiu que jogos quase perfeitos fossem jogados em casa. Outros consoles, como o PlayStation e o Dreamcast , também baseados em hardware de arcade, tornaram os jogos de arcade perfeitos uma realidade.

Uma "porta de console" é um jogo originalmente feito para um console antes de ser criada uma versão idêntica, que pode ser jogada em um computador pessoal . Este termo tem sido amplamente utilizado pela comunidade de jogadores. O processo de portar um jogo de um console para um PC é frequentemente considerado negativamente devido aos níveis mais altos de desempenho que os computadores geralmente têm sido subutilizados, parcialmente devido ao hardware do console ser corrigido durante sua execução (com jogos sendo desenvolvidos para especificações do console), enquanto os PCs se tornam mais poderosos conforme o hardware evolui, mas também devido aos jogos portados às vezes serem mal otimizados para PCs, ou portados de forma preguiçosa. Embora amplamente semelhantes, podem existir diferenças de arquitetura, como o uso de memória unificada em um console.

Veja também

Notas

Referências