Portabilidad
Proceso de adaptación de software para ejecutarse en otros entornos informáticos.

En ingeniería de software , la portabilidad es el proceso de adaptar software con el fin de lograr alguna forma de ejecución en un entorno informático diferente de aquel para el que se diseñó originalmente un programa determinado (pensado para dicha ejecución) (por ejemplo, una CPU , un sistema operativo o una biblioteca de terceros diferentes ). El término también se utiliza cuando se cambia el software o el hardware para que se puedan utilizar en entornos diferentes. [1] [2]

El software es portable cuando el costo de trasladarlo a una nueva plataforma es significativamente menor que el costo de escribirlo desde cero. Cuanto menor sea el costo de trasladar el software en relación con su costo de implementación, se dice que es más portable.

Etimología

El término "puerto" se deriva del latín portāre , que significa "transportar". [3] Cuando el código no es compatible con un sistema operativo o una arquitectura en particular , el código debe ser "transportado" al nuevo sistema.

El término no se aplica generalmente al proceso de adaptación del software para que funcione con menos memoria en la misma CPU y sistema operativo.

Los desarrolladores de software suelen afirmar que el software que escriben es portable , lo que significa que se necesita poco esfuerzo para adaptarlo a un nuevo entorno. La cantidad de esfuerzo que realmente se necesita depende de varios factores, entre ellos, el grado en que el entorno original (la plataforma de origen ) difiere del nuevo entorno (la plataforma de destino ), la experiencia de los autores originales en saber qué construcciones de lenguaje de programación y llamadas a bibliotecas de terceros es poco probable que sean portables, y la cantidad de esfuerzo invertido por los autores originales en utilizar únicamente construcciones portables (las construcciones específicas de la plataforma suelen proporcionar una solución más económica).

Historia

Hoy en día, la cantidad de CPU y sistemas operativos significativamente diferentes que se utilizan en los equipos de escritorio es mucho menor que en el pasado. El predominio de la arquitectura x86 significa que la mayoría del software de escritorio nunca se traslada a una CPU diferente. En ese mismo mercado, la elección de sistemas operativos se ha reducido efectivamente a tres: Microsoft Windows , macOS y Linux . Sin embargo, en los mercados de sistemas integrados y móviles , la portabilidad sigue siendo un problema importante, y ARM es una alternativa ampliamente utilizada.

Los estándares internacionales, como los promulgados por la ISO , facilitan enormemente la portabilidad al especificar detalles del entorno informático de una manera que ayuda a reducir las diferencias entre las diferentes plataformas que cumplen con los estándares. Escribir software que se mantenga dentro de los límites especificados por estos estándares representa un esfuerzo práctico aunque no trivial. La portabilidad de un programa de este tipo entre dos plataformas que cumplen con los estándares (como POSIX.1 ) puede ser simplemente una cuestión de cargar el código fuente y volver a compilarlo en la nueva plataforma, pero los profesionales a menudo descubren que se requieren varias correcciones menores, debido a las sutiles diferencias de plataforma. La mayoría de los estándares sufren de "zonas grises" donde las diferencias en la interpretación de los estándares conducen a pequeñas variaciones de una plataforma a otra.

También existe un número cada vez mayor de herramientas para facilitar la portabilidad, como GNU Compiler Collection , que proporciona lenguajes de programación consistentes en diferentes plataformas, y Autotools , que automatiza la detección de variaciones menores en el entorno y adapta el software en consecuencia antes de la compilación.

Los compiladores de algunos lenguajes de programación de alto nivel (por ejemplo, Eiffel , Esterel ) ganan portabilidad al generar el código fuente en otro lenguaje intermedio de alto nivel (como C ) para el cual generalmente hay compiladores disponibles para muchas plataformas.

Dos actividades relacionadas con la portabilidad (pero distintas de ella) son la emulación y la compilación cruzada .

Portabilidad de compiladores

En lugar de traducir directamente a código de máquina , los compiladores modernos traducen a un código intermedio independiente de la máquina para mejorar la portabilidad del compilador y minimizar los esfuerzos de diseño. El lenguaje intermedio define una máquina virtual que puede ejecutar todos los programas escritos en el lenguaje intermedio (una máquina se define por su lenguaje y viceversa). [4] Las instrucciones del código intermedio se traducen en secuencias de código de máquina equivalentes mediante un generador de código para crear código ejecutable . También es posible omitir la generación de código de máquina implementando realmente un intérprete o JIT para la máquina virtual. [5]

El uso de código intermedio mejora la portabilidad del compilador, ya que solo el código dependiente de la máquina (el intérprete o el generador de código) del compilador en sí necesita ser portado a la máquina de destino. El resto del compilador puede importarse como código intermedio y luego procesarse más por el generador de código portado o el intérprete, produciendo así el software del compilador o ejecutando directamente el código intermedio en el intérprete. La parte independiente de la máquina puede desarrollarse y probarse en otra máquina (la máquina anfitriona ). Esto reduce en gran medida los esfuerzos de diseño, porque la parte independiente de la máquina necesita desarrollarse solo una vez para crear código intermedio portable. [6]

Un intérprete es menos complejo y, por lo tanto, más fácil de portar que un generador de código, porque no puede hacer optimizaciones de código debido a su visión limitada del código del programa (solo ve una instrucción a la vez y los usuarios necesitan una secuencia para hacer la optimización). Algunos intérpretes son extremadamente fáciles de portar, porque solo hacen suposiciones mínimas sobre el conjunto de instrucciones del hardware subyacente. Como resultado, la máquina virtual es incluso más simple que la CPU de destino. [7]

Escribir las fuentes del compilador completamente en el lenguaje de programación que se supone que el compilador debe traducir, hace que el siguiente enfoque, mejor conocido como arranque del compilador , sea factible en la máquina de destino:

  1. Portar el intérprete. Esto debe codificarse en código ensamblador , utilizando un ensamblador ya presente en el destino.
  2. Adaptar la fuente del generador de código a la nueva máquina.
  3. Ejecute la fuente adaptada utilizando el intérprete con la fuente del generador de código como entrada. Esto generará el código de máquina para el generador de código.

La parte difícil de codificar las rutinas de optimización se realiza utilizando el lenguaje de alto nivel en lugar del lenguaje ensamblador del objetivo.

Según los diseñadores del lenguaje BCPL , el código interpretado (en el caso de BCPL) es más compacto que el código de máquina, normalmente en un factor de dos a uno. Sin embargo, el código interpretado se ejecuta aproximadamente diez veces más lento que el código compilado en la misma máquina. [8]

Los diseñadores del lenguaje de programación Java intentan aprovechar la compacidad del código interpretado, porque puede ser necesario transmitir un programa Java a través de Internet antes de que pueda iniciarse la ejecución en la máquina virtual Java (JVM) del destino.

Portabilidad de videojuegos

Portar es también el término utilizado cuando un videojuego diseñado para funcionar en una plataforma, ya sea una sala de juegos , una consola de videojuegos o una computadora personal , se convierte para funcionar en una plataforma diferente, quizás con algunas diferencias menores. [9] Desde el comienzo de los videojuegos hasta la década de 1990, los "puertos", en ese momento a menudo conocidos como "conversiones", a menudo no eran verdaderos puertos, sino versiones reelaboradas de los juegos debido a las limitaciones de los diferentes sistemas. Por ejemplo, el juego de 1982 El Hobbit , una aventura de texto aumentada con imágenes gráficas, tiene estilos gráficos significativamente diferentes en la gama de computadoras personales para las que se desarrollaron sus puertos. [10] Sin embargo, muchos videojuegos del siglo XXI se desarrollan utilizando software (a menudo en C++ ) que puede generar código para una o más consolas, así como para una PC sin la necesidad de una portabilidad real (en lugar de confiar en la portabilidad común de bibliotecas de componentes individuales ). [10]

La adaptación de los juegos arcade a sistemas domésticos con hardware inferior fue difícil. La versión adaptada de Pac-Man para Atari 2600 omitió muchas de las características visuales del juego original para compensar la falta de espacio en la ROM y el hardware tuvo problemas cuando aparecieron múltiples fantasmas en la pantalla creando un efecto de parpadeo. Algunos académicos citan el bajo rendimiento del Pac-Man de Atari 2600 como una de las causas del colapso de los videojuegos en 1983. [ 11]

Muchos de los primeros ports sufrieron problemas de calidad de juego significativos debido a que las computadoras diferían enormemente. [12] Richard Garriott declaró en 1984 en Origins Game Fair que Origin Systems desarrolló videojuegos para Apple II primero y luego los portó a las computadoras Commodore 64 y Atari de 8 bits , porque los sprites de estas últimas máquinas y otras características sofisticadas hacían que la portabilidad de ellas a Apple fuera "mucho más difícil, quizás incluso imposible". [13] Las reseñas se quejaron de los ports que sufrieron de "conversión de Apple", [14] conservando el "pésimo sonido y los gráficos en blanco, negro, verde y morado" de Apple; [15] [16] después de la declaración de Garriott, cuando Dan Bunten preguntó "Gente de Atari y Commodore en la audiencia, ¿están contentos con las reescrituras de Apple?" la audiencia gritó "¡No!" Garriott respondió, "[de lo contrario] la versión de Apple nunca se hará. Desde el punto de vista de un editor, eso no es económico". [13]

Otros trabajaron de manera diferente. Ozark Softscape , por ejemplo, escribió MULE para Atari primero porque prefería desarrollar para las computadoras más avanzadas, eliminando o alterando características según fuera necesario durante la migración. Tal política no siempre fue factible; Bunten afirmó que "MULE no se puede hacer para un Apple", [12] y que las versiones no Atari de The Seven Cities of Gold eran inferiores. [17] La ​​Gazette de Compute! escribió en 1986 que al migrar de Atari a Commodore, el original era generalmente superior. La calidad de los juegos de este último mejoró cuando los desarrolladores comenzaron a crear nuevo software para él a fines de 1983, afirmó la revista. [18]

En la adaptación de juegos arcade , los términos "arcade perfecto" o "arcade preciso" se usaban a menudo para describir qué tan cerca la jugabilidad, los gráficos y otros recursos de la versión adaptada coincidían con la versión arcade. Muchos ports arcade a principios de la década de 1980 estaban lejos de ser arcade perfectos, ya que las consolas domésticas y las computadoras carecían del hardware sofisticado de los juegos arcade, pero los juegos aún podían aproximarse a la jugabilidad. En particular, Space Invaders en Atari VCS se convirtió en la aplicación estrella de la consola a pesar de sus diferencias, [19] mientras que el posterior port de Pac-Man fue conocido por sus desviaciones de la versión arcade. [20] Los juegos arcade precisos se volvieron más frecuentes a partir de la década de 1990 cuando las consolas domésticas se pusieron al día con el poder de los sistemas arcade. En particular, el sistema Neo Geo de SNK , que se presentó como un sistema arcade multijuego, también se ofrecería como una consola doméstica con las mismas especificaciones. Esto permitió que los juegos arcade perfectos se jugaran en casa. [10]

Un "port de consola" es un juego que se hizo originalmente para una consola antes de que se creara una versión idéntica que se puede jugar en una computadora personal . Este término ha sido ampliamente utilizado por la comunidad de juegos. El proceso de portar un juego de una consola a una PC a menudo se considera negativo debido a que los niveles más altos de rendimiento que generalmente tienen las computadoras están subutilizados, en parte debido a que el hardware de la consola se fija durante su ejecución (y los juegos se desarrollan para las especificaciones de la consola), mientras que las PC se vuelven más poderosas a medida que evoluciona el hardware, pero también debido a que los juegos portados a veces están mal optimizados para PC o se portan de manera perezosa. Si bien en general son similares, pueden existir diferencias arquitectónicas, como el uso de memoria unificada en una consola.

Véase también

Referencias

  1. ^ Whitten, DE; Demaine, PAD (marzo de 1975). "Un Fortran independiente de la máquina y de la configuración: Fortran portátil". IEEE Transactions on Software Engineering . SE-1 (1): 111–124. doi :10.1109/TSE.1975.6312825. S2CID  16485156.
  2. ^ "Problemas de portabilidad" ... analiza.. la portabilidad de.. Fortran
  3. ^ "puerto, v.2" . Oxford English Dictionary (OED Online) . Oxford University Press . Consultado el 21 de diciembre de 2017 . Origen: De orígenes múltiples. En parte un préstamo del francés. En parte un préstamo del latín. Étimos: francés porter ; latín portāre . ... 1. trans. Llevar, soportar o transportar; traer.
  4. ^ Tanenbaum 1984, p. 3, § 1.1 Lenguajes, niveles y máquinas virtuales describe los términos y sus relaciones.
  5. ^ Tanenbaum 1984, p. 2. Cap. 1 La introducción explica la traducción y la interpretación.
  6. ^ Richards & Whitby-Strevens 1984, p. 124, § 7.1 La introducción explica la portabilidad del compilador utilizando código intermedio.
  7. ^ Richards & Whitby-Strevens 1984, p. 133, § 7.4 El proceso de arranque y INTCODE explica el papel del intérprete INTCODE.
  8. ^ Richards & Whitby-Strevens 1984, p. 136, § 7.4.3 El ejemplo ofrece un ejemplo de traducción de un programa BCPL a INTCODE para el intérprete.
  9. ^ Wolf, Mark JP (2008). "Glosario". La explosión de los videojuegos: una historia desde PONG hasta Playstation y más allá . Bloomsbury Academic. pág. 315. ISBN 978-0-313-33868-7.
  10. ^ abc Grabarczyk, Pawel; Aarseth, Espen (2019), ¿ Portación o conversión? Un marco ontológico para clasificar versiones de juegos | Conferencia DiGRA 2019
  11. ^ Nicoll, Benjamin (2015). "Bridging the Gap: The Neo Geo, the Media Imaginary, and the Domestication of Arcade Games" (Cerrando la brecha: Neo Geo, el imaginario mediático y la domesticación de los juegos arcade). Juegos y cultura . doi :10.1177/1555412015590048. S2CID  147981978.
  12. ^ ab Bunten, Dan (diciembre de 1984). "Dispatches / Insights From the Strategy Game Design Front". Computer Gaming World . pág. 40 . Consultado el 31 de octubre de 2013 .
  13. ^ ab "The CGW Computer Game Conference". Computer Gaming World (mesa redonda). Octubre de 1984. p. 30. Consultado el 31 de octubre de 2013 .
  14. ^ Dunnington, Benn; Brown, Mark R.; Malcolm, Tom (enero-febrero de 1987). "Galería 64/128". Información . págs. 14-21.
  15. ^ Stanton, Jeffrey; Wells, Robert P.; Rochowansky, Sandra; Mellid, Michael, eds. (1984). El libro de Addison-Wesley sobre el software de Atari. Addison-Wesley. págs. 12, 21, 44, 126. ISBN 0-201-16454-X.
  16. ^ Bernstein, Harvey (mayo de 1985). «Más allá del castillo de Wolfenstein». Antic . pág. 83 . Consultado el 8 de enero de 2015 .
  17. ^ Bunten, Dan. "The Game Collection". Ozark Softscape MULE . Consultado el 4 de octubre de 2017 .
  18. ^ Yakal, Kathy (junio de 1986). "La evolución de los gráficos Commodore". Compute!'s Gazette . págs. 34–42 . Consultado el 18 de junio de 2019 .
  19. ^ Kent, Steven (2001). Historia definitiva de los videojuegos . Three Rivers Press . pág. 190. ISBN. 0-7615-3643-4.
  20. ^ Kent, Steven (2001). "The Fall". La historia definitiva de los videojuegos . Three Rivers Press . Págs. 237-239. ISBN. 978-0-7615-3643-7.
Obtenido de "https://es.wikipedia.org/w/index.php?title=Portación&oldid=1236444044"