stringtranslate.com

Portabilidad

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

El software es portátil 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 portar software en relación con su costo de implementación, más portátil se dice que es.

Etimología

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

El término generalmente no se aplica al proceso de adaptar el software para que se ejecute con menos memoria en la misma CPU y sistema operativo.

Los desarrolladores de software suelen afirmar que el software que escriben es portátil , lo que significa que se necesita poco esfuerzo para adaptarlo a un nuevo entorno. La cantidad de esfuerzo realmente necesaria depende de varios factores, incluido 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é lenguaje de programación construye y el de terceros. Es poco probable que las llamadas a la biblioteca sean portátiles, y la cantidad de esfuerzo invertida por los autores originales en utilizar únicamente construcciones portátiles (las construcciones específicas de la plataforma a menudo proporcionan una solución más barata).

Historia

El número de CPU y sistemas operativos significativamente diferentes que se utilizan en el escritorio hoy en día 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, siendo ARM una alternativa ampliamente utilizada.

Los estándares internacionales, como los promulgados por ISO , facilitan enormemente la portabilidad al especificar detalles del entorno informático de una manera que ayuda a reducir las diferencias entre 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. Portar un programa de este tipo entre dos plataformas compatibles con estándares (como POSIX.1 ) puede ser simplemente una cuestión de cargar el código fuente y recompilarlo en la nueva plataforma. Sin embargo, los profesionales a menudo descubren que se requieren varias correcciones menores debido a diferencias sutiles entre plataformas. La mayoría de los estándares sufren de "áreas 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 (pero distintas) con la portabilidad son la emulación y la compilación cruzada .

Portando 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 de 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 un intérprete o JIT para la máquina virtual. [5]

El uso de código intermedio mejora la portabilidad del compilador, porque sólo el código dependiente de la máquina (el intérprete o el generador de código) del propio compilador necesita ser portado a la máquina de destino. El resto del compilador se puede importar como código intermedio y luego procesarlo adicionalmente mediante el generador o intérprete de código adaptado, produciendo así el software del compilador o ejecutando directamente el código intermedio en el intérprete. La pieza independiente de la máquina se puede desarrollar y probar 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 solo necesita desarrollarse una vez para crear un código intermedio portátil. [6]

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

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

  1. Port 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ódigos.

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 BCPL) es más compacto que el código máquina; normalmente por 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 es posible que sea necesario transmitir un programa Java a través de Internet antes de que pueda comenzar la ejecución en la máquina virtual Java (JVM) del destino.

Portación de videojuegos

Portación es también el término utilizado cuando un videojuego diseñado para ejecutarse en una plataforma, ya sea una sala de juegos , una consola de videojuegos o una computadora personal , se convierte para ejecutarse en una plataforma diferente, quizás con algunas diferencias menores. [9] Desde el comienzo de los videojuegos hasta la década de 1990, los "ports", en ese momento conocidos como "conversiones", a menudo no eran verdaderos ports, 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 toda la gama de computadoras personales para las que se desarrollaron sus adaptaciones. [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 depender de la portabilidad común de componentes individuales). bibliotecas ). [10]

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

Muchos de los primeros ports sufrieron importantes problemas de calidad de juego porque las computadoras diferían mucho. [12] Richard Garriott declaró en 1984 en Origins Game Fair que Origin Systems desarrolló primero juegos de computadora para la serie Apple II y luego los portó a Commodore 64 y Atari de 8 bits , porque los sprites de estas últimas máquinas y otras características sofisticadas hicieron que la portabilidad fuera de ellos. para Apple "mucho más difícil, quizás incluso imposible". [13] Las revisiones se quejaron de los puertos que sufrían de "conversionitis de Apple", [14] conservando el "pésimo sonido y los gráficos negro-blanco-verde-púrpura" de Apple; [15] [16] después de la declaración de Garriott, cuando Dan Bunten preguntó: "La gente de Atari y Commodore en la audiencia, ¿están contentos con las reescrituras de Apple?" el público gritó "¡No!" Garriott respondió: "[de lo contrario] la versión de Apple nunca se realizará. Desde el punto de vista del editor, eso no es una cuestión de dinero". [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 funciones según fuera necesario durante la migración. Esa política no siempre fue viable; Bunten afirmó que "MULE no se puede hacer para una Apple", [12] y que las versiones que no eran de Atari de Las Siete Ciudades de Oro eran inferiores. [17] Compute!'s Gazette escribió en 1986 que cuando se portaba de Atari a Commodore, el original generalmente era superior. La calidad de los juegos de este último mejoró cuando los desarrolladores comenzaron a crear nuevo software a finales de 1983, afirmó la revista. [18]

Al portar juegos de arcade , los términos "arcade perfecto" o "arcade preciso" se usaban a menudo para describir en qué medida la jugabilidad, los gráficos y otros recursos de la versión portada coincidían con la versión arcade. Muchos puertos de arcade a principios de la década de 1980 estaban lejos de ser perfectos, ya que las consolas domésticas y las computadoras carecían del hardware sofisticado de los juegos de 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 principal de la consola a pesar de sus diferencias, [19] mientras que la versión posterior de Pac-Man fue notoria por sus desviaciones de la versión arcade. [20] Los juegos arcade se hicieron más frecuentes a partir de la década de 1990, comenzando con el sistema Neo Geo de SNK , que ofrecía tanto una consola doméstica como un sistema arcade con versiones más avanzadas del hardware principal de la consola doméstica. Esto permitió jugar juegos perfectos casi arcade en casa. Otras consolas como PlayStation y Dreamcast , también basadas en hardware arcade, hicieron realidad los juegos perfectos para arcade. [10]

Un "portado de consola" es un juego que se creó 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 jugadores. 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 infrautilizados, en parte debido a que el hardware de la consola se repara 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 con pereza. Si bien en términos generales son similares, pueden existir diferencias arquitectónicas, como el uso de memoria unificada en una consola.

Ver también

Referencias

  1. ^ Whitten, DE; Demaine, PAD (marzo de 1975). "Un Fortran independiente de máquina y configuración: Fortran portátil". Transacciones IEEE sobre ingeniería de software . SE-1 (1): 111–124. doi :10.1109/TSE.1975.6312825. S2CID  16485156.
  2. ^ "Problemas de portabilidad". .. analiza .. portabilidad de .. Fortran
  3. ^ "puerto, v.2" . Diccionario de inglés Oxford (OED en línea) . Prensa de la Universidad de Oxford . Consultado el 21 de diciembre de 2017 . Origen: De múltiples orígenes. En parte un préstamo del francés. En parte un préstamo del latín. Etimos: portero francés ; Latín portāre . ... 1. trans. Llevar, soportar o transmitir; traer.
  4. ^ Tanenbaum 1984, pág. 3. §1.1 Idiomas, Niveles y Máquinas Virtuales describe los términos y sus relaciones.
  5. ^ Tanenbaum 1984, pág. 2. cap. 1 La Introducción explica la traducción y la interpretación.
  6. ^ Richards y Whitby-Strevens 1984, pág. 124. §7.1 Introducción explica la portabilidad del compilador utilizando código intermedio.
  7. ^ Richards y Whitby-Strevens 1984, pág. 133. §7.4 El proceso de arranque e INTCODE explica el papel del intérprete de INTCODE.
  8. ^ Richards y Whitby-Strevens 1984, pág. 136. §7.4.3 Ejemplo proporciona un ejemplo de traducción de un programa BCPL a INTCODE para el intérprete.
  9. ^ Lobo, Mark JP (2008). "Glosario". La explosión de los videojuegos: una historia desde PONG hasta Playstation y más allá . Académico de Bloomsbury. pag. 315.ISBN _ 978-0-313-33868-7.
  10. ^ abc Grabarczyk, Pawel; Aarseth, Espen (2019), ¿ Puerto o conversión? Un marco ontológico para clasificar versiones de juegos | Conferencia DiGRA 2019
  11. ^ Nicoll, Benjamín (2015). "Cerrando la brecha: Neo Geo, el imaginario de los medios y la domesticación de los juegos arcade". Juegos y Cultura . doi :10.1177/1555412015590048. S2CID  147981978.
  12. ^ ab Bunten, Dan (diciembre de 1984). "Despachos/Información desde el frente del diseño de juegos de estrategia". Mundo de los juegos de computadora . pag. 40 . Consultado el 31 de octubre de 2013 .
  13. ^ ab "La conferencia sobre juegos de computadora CGW". Mundo de los juegos de computadora (panel de discusión). Octubre de 1984. p. 30 . Consultado el 31 de octubre de 2013 .
  14. ^ Dunnington, Benn; Marrón, 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 Addison-Wesley del software 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 Wolfenstein". Antico . pag. 83 . Consultado el 8 de enero de 2015 .
  17. ^ Bunten, Dan. "La colección de juegos". MULA Ozark Softscape . Consultado el 4 de octubre de 2017 .
  18. ^ Yakal, Kathy (junio de 1986). "La evolución de Commodore Graphics". Gaceta de Compute !. págs. 34–42 . Consultado el 18 de junio de 2019 .
  19. ^ Kent, Steven (2001). Historia definitiva de los videojuegos . Prensa de Tres Ríos . pag. 190.ISBN _ 0-7615-3643-4.
  20. ^ Kent, Steven (2001). "La caída". La historia definitiva de los videojuegos . Prensa de Tres Ríos . págs. 237-239. ISBN 978-0-7615-3643-7.