Portabilidade (informática)

 Nota: Para outros significados, veja Portabilidade.

No desenvolvimento de software, a portabilidade (do inglês porting) é o processo de adaptação de um software para ser executado em um contexto diferente. Muitas vezes, envolve a modificação do código-fonte para que um programa possa ser executado em uma plataforma diferente (ou seja, em uma CPU ou sistema operacional diferente) ou em um ambiente diferente (ou seja, com uma biblioteca ou framework diferente). O termo também descreve a adaptação de uma alteração ou recurso de uma base de código para outra — mesmo entre diferentes versões do mesmo software.[1]

Um software é classificado como portátil se pode ser hospedado em um contexto diferente sem alteração do código-fonte. Pode ser considerado portátil se o custo de adaptá-lo a um contexto for significativamente menor do que o custo de reescrevê-lo do zero. Quanto menor o custo de portabilidade em relação ao custo de reescrever, mais portátil ele é considerado. O esforço depende de vários fatores, incluindo a extensão em que o contexto original difere do novo contexto, a habilidade dos programadores e a portabilidade da base de código.

Etimologia

O termo "portar" é derivado do latim portāre, que significa "carregar". Quando o código não é compatível com um determinado sistema operacional ou arquitetura de computador, o código deve ser "carregado" para o novo sistema.[2]

História

O número de CPUs e sistemas operacionais significativamente diferentes usados nos desktops atualmente é 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 a três: Microsoft Windows, macOS e Linux. No entanto, nos mercados de sistemas embarcados e computação móvel, a portabilidade permanece uma questão significativa, sendo a arquitetura ARM uma alternativa amplamente utilizada.

Padrões internacionais, como os promulgados pela ISO, facilitam muito a portabilidade ao especificar detalhes do ambiente de computação de uma forma que ajuda a reduzir as diferenças entre diferentes plataformas conformes 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 compatíveis 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, mas os profissionais frequentemente descobrem que várias correções menores são necessárias, devido a diferenças sutis entre as plataformas. 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 crescente de ferramentas para facilitar a portabilidade, como a GNU Compiler Collection, que fornece linguagens de programação consistentes em diferentes plataformas, e o 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.

Portando compiladores

Em vez de traduzir diretamente para código de máquina, os compiladores modernos traduzem para um código intermediário independente de máquina para melhorar a portabilidade do compilador e minimizar os esforços de projeto. 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).[3] As instruções do código intermediário são traduzidas em sequências equivalentes de código de máquina por um gerador de código para criar código executável. Também é possível pular a geração do código de máquina implementando, na verdade, um interpretador ou compilador JIT para a máquina virtual.[4]

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

Um interpretador é menos complexo e, portanto, mais fácil de portar do que um gerador de código, porque 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 é necessária uma sequência para fazer otimização). Alguns interpretadores são extremamente fáceis de portar, porque fazem 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.[6]

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

  1. Porte o interpretador. Isso precisa ser codificado em código assembly, usando um montador já presente no alvo.
  2. Adapte o código-fonte do gerador de código para a nova máquina.
  3. Execute o código-fonte adaptado usando o interpretador com o código-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 da codificação das rotinas de otimização é feita usando a linguagem de alto nível em vez da linguagem assembly da máquina de destino.

De acordo com os designers da linguagem BCPL, o código interpretado (no caso do BCPL) é mais compacto do que o código de máquina, normalmente por um fator de dois para um. No entanto, o código interpretado é executado cerca de dez vezes mais lento do que o código compilado na mesma máquina.[7]

Os designers da linguagem de programação Java tentam aproveitar a 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 máquina virtual Java (JVM) do destino.

Portabilidade de jogos eletrônicos

A portabilidade também é o termo usado quando um jogo eletrônico projetado para ser executado em uma plataforma, seja um fliperama, console de videogame ou computador pessoal, é convertido para ser executado em uma plataforma diferente, talvez com algumas pequenas diferenças.[8] Desde o início dos jogos eletrônicos até a década de 1990, as "portabilidades", na época frequentemente chamadas de "conversões", muitas vezes não eram portabilidades verdadeiras, mas sim versões retrabalhadas dos jogos devido às limitações dos diferentes sistemas. Por exemplo, o jogo de 1982 The Hobbit, uma aventura textual aumentada com imagens gráficas, tem estilos gráficos significativamente diferentes na gama de computadores pessoais para os quais suas portabilidades foram desenvolvidas.[9] No entanto, muitos jogos eletrônicos do século XXI são desenvolvidos usando software (frequentemente em C++) que pode gerar código para um ou mais consoles, bem como para um PC, sem a necessidade de portabilidade real (conforme, em vez disso, na portabilidade comum de bibliotecas de componentes individuais).[9]

Portar jogos de fliperama para sistemas domésticos com hardware inferior era difícil. A versão portada de Pac-Man para o Atari 2600 omitiu muitos dos recursos visuais do jogo original para compensar a falta de espaço na ROM e o hardware lutava quando vários fantasmas apareciam na tela, criando um efeito de cintilação. O desempenho fraco do Pac-Man do Atari 2600 é citado por alguns estudiosos como uma causa do crash do videogame de 1983.[10]

Muitas portabilidades iniciais sofriam de problemas significativos de qualidade de jogabilidade porque os computadores diferiam muito. Richard Garriott afirmou em 1984 na Origins Game Fair que a Origin Systems desenvolvia jogos eletrônicos para o Apple II primeiro e depois os portava para o Commodore 64 e computadores Atari de 8 bits, porque os sprites e outros recursos sofisticados dessas últimas máquinas tornavam a portabilidade delas para o Apple "muito mais difícil, talvez até impossível".[11] As resenhas reclamavam de portabilidades que sofriam de "conversite Apple",[12] mantendo o "som péssimo e gráficos em preto-branco-verde-roxo" do Apple;[13][14] depois da declaração de Garriott, quando Dan Bunten perguntou "Pessoas da Atari e Commodore na plateia, vocês estão felizes com as regravações da Apple?" a plateia gritou "Não!" Garriott respondeu: "[caso contrário] a versão Apple nunca ficará pronta. Do ponto de vista de um editor, isso não é financeiramente sábio".[15]

Outros trabalhavam de forma diferente. A Ozark Softscape, por exemplo, escreveu M.U.L.E. para o Atari primeiro porque preferia desenvolver para os computadores mais avançados, removendo ou alterando os recursos conforme necessário durante a portabilidade. Tal política nem sempre era viável; Bunten afirmou que "M.U.L.E. não pode ser feito para um Apple",[16] e que as versões não-Atari de The Seven Cities of Gold eram inferiores.[17] A Compute!'s Gazette escreveu em 1986 que, ao portar do Atari para o Commodore, o original geralmente era superior. A qualidade dos jogos deste último melhorou quando os desenvolvedores começaram a criar novos softwares para ele no final de 1983, afirmou a revista.[18]

Ao portar jogos de fliperama, os termos "perfeito para arcade" ou "preciso para arcade" eram frequentemente usados para descrever o quão próximas a jogabilidade, os gráficos e outros recursos na versão portada correspondiam à versão arcade. Muitas portabilidades de arcade no início da década de 1980 estavam longe de ser perfeitas para arcade, pois os consoles domésticos e computadores não tinham o hardware sofisticado dos jogos de arcade, mas os jogos ainda podiam aproximar a jogabilidade. Notavelmente, Space Invaders no Atari VCS tornou-se o aplicativo matador do console, apesar de suas diferenças,[19] enquanto a posterior portabilidade de Pac-Man foi notória por seus desvios da versão arcade.[20] Jogos precisos para arcade tornaram-se mais prevalentes a partir da década de 1990, quando os consoles domésticos alcançaram o poder dos sistemas de arcade. Notavelmente, o sistema Neo Geo da SNK, que foi introduzido como um sistema de arcade multijogo, também seria oferecido como um console doméstico com as mesmas especificações. Isso permitiu que jogos perfeitos para arcade fossem jogados em casa.[9]

Uma "portabilidade de console" é um jogo que foi originalmente ou principalmente feito para um console antes que uma versão seja criada que possa ser jogada em um computador pessoal. O processo de portar jogos do console para o PC é frequentemente visto com mais cinismo do que outros tipos de portabilidade devido ao hardware mais poderoso de alguns PCs, mesmo no lançamento do console, sendo subutilizado, parcialmente porque o hardware do console é fixo ao longo de cada geração, enquanto PCs mais novos constantemente se tornam ainda mais poderosos. Embora amplamente semelhantes hoje, algumas diferenças arquitetônicas persistem, como o uso de memória unificada e SOs menores nos consoles. Outras objeções surgem das diferenças de interface do usuário convencionais para consoles, como gamepads, interfaces de 10 pés acompanhadas por FoV estreito, pontos de verificação fixos, online restrito a servidores oficiais ou P2P, suporte a modificação pobre ou inexistente, bem como a maior dependência geral entre os desenvolvedores de consoles na hard coding interna e padrões em vez de APIs externas e configurabilidade, tudo o que pode exigir uma reformulação profunda e cara para evitar uma portabilidade para PC considerada "preguiçosa".[21]

Ver também

Referências

  1. ↑ Whitten, D.E.; Demaine, P.A.D. (março de 1975). «Um Fortran independente de máquina e configuração: Fortran Portátil». IEEE Transactions on Software Engineering. SE–1 (1): 111–124. doi:10.1109/TSE.1975.6312825 
  2. ↑ «port, v.2». Oxford English Dictionary (OED Online). Oxford University Press. Consultado em 21 de dezembro de 2017. Origem: De múltiplas origens. Parcialmente um empréstimo do francês. Parcialmente um empréstimo do latim. Etimon: francês porter; latim portāre. ... 1. trans. Para carregar, suportar ou transportar; para trazer. 
  3. ↑ Tanenbaum 1984, § 1.1 Languages, Levels, and Virtual Machines, p. 3 descreve os termos e suas relações.
  4. ↑ Tanenbaum 1984, p. 2. Cap. 1 Introdução explica tradução e interpretação.
  5. ↑ Richards & Whitby-Strevens 1984, § 7.1 Introdução, p. 124 explica a portabilidade do compilador usando código intermediário.
  6. ↑ Richards & Whitby-Strevens 1984, § 7.4 O processo de bootstrapping e INTCODE, p. 133 explica o papel do interpretador INTCODE.
  7. ↑ Richards & Whitby-Strevens 1984, § 7.4.3 Exemplo, p. 136 dá um exemplo de tradução de um programa BCPL para INTCODE para o interpretador.
  8. ↑ Wolf, Mark J. P. (2008). «Glossary». The Video Game Explosion: A History from PONG to Playstation and Beyond. [S.l.]: Bloomsbury Academic. p. 315. ISBN 978-0-313-33868-7 
  9. ↑ a b c Grabarczyk, Pawel; Aarseth, Espen (2019), Port or conversion? An ontological framework for classifying game versions | DiGRA Conference 2019 
  10. ↑ Nicoll, Benjamin (2015). «Bridging the Gap: The Neo Geo, the Media Imaginary, and the Domestication of Arcade Games». Games and Culture. doi:10.1177/1555412015590048 
  11. ↑ «The CGW Computer Game Conference». Computer Gaming World (discussão em painel). Outubro de 1984. 30 páginas. Consultado em 31 de outubro de 2013 
  12. ↑ Dunnington, Benn; Brown, Mark R.; Malcolm, Tom (janeiro–fevereiro de 1987). «64/128 Gallery». Info. pp. 14–21 
  13. ↑ Stanton, Jeffrey; Wells, Robert P.; Rochowansky, Sandra; Mellid, Michael, eds. (1984). The Addison-Wesley Book of Atari Software. [S.l.]: Addison-Wesley. pp. 12,21,44,126. ISBN 0-201-16454-X 
  14. ↑ Bernstein, Harvey (maio de 1985). «Beyond Castle Wolfenstein». Antic. 83 páginas. Consultado em 8 de janeiro de 2015 
  15. ↑ «CGW Museum - Galleries». www.cgwmuseum.org. Consultado em 27 de setembro de 2025 
  16. ↑ Bunten, Dan (dezembro de 1984). «Dispatches / Insights From the Strategy Game Design Front». Computer Gaming World. 40 páginas. Consultado em 31 de outubro de 2013 
  17. ↑ Bunten, Dan. «The Game Collection». Ozark Softscape M.U.L.E. Consultado em 4 de outubro de 2017 
  18. ↑ Yakal, Kathy (junho de 1986). «The Evolution of Commodore Graphics». Compute!'s Gazette. pp. 34–42. Consultado em 18 de junho de 2019 
  19. ↑ Kent, Steven (2001). Ultimate History of Video Games. [S.l.]: Three Rivers Press. p. 190. ISBN 0-7615-3643-4 
  20. ↑ Kent, Steven (2001). «The Fall». The Ultimate History of Video Games. [S.l.]: Three Rivers Press. pp. 237–239. ISBN 978-0-7615-3643-7 
  21. ↑ «Stop making horrible console ports - a guide». PC Gamer. 2013 

Fontes

  • Richards, Martin; Whitby-Strevens, Colin (1984). BCPL, the language and its compiler. [S.l.]: Cambridge University Press. ISBN 0-521-28681-6 
  • Tanenbaum, Andrew S. (1984). Structured computer organization. [S.l.]: Prentice-Hall. ISBN 0-13-854605-3 
Este artigo é emitido por Wikipédia. O texto é licenciado sob Creative Commons Attribution-Share Alike 4.0. Termos adicionais podem ser aplicados aos arquivos de mídia.