Portabilidad

En ingeniería de software, portar 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 al de un programa determinado (destinado a tal ejecución) fue diseñado originalmente para (por ejemplo, CPU diferente, sistema operativo o biblioteca de terceros). El término también se utiliza cuando se modifica el software o el hardware para que se pueda utilizar en diferentes entornos.

El software es portátil cuando el costo de migrarlo 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". Cuando el código no es compatible con un sistema operativo o arquitectura en particular, el código debe ser "llevado" 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 a menudo afirman 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 necesario 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 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 portátiles, y la cantidad de esfuerzo invertido por los autores originales en usar solo construcciones portátiles (las construcciones específicas de la plataforma a menudo brindan una solución más económica).

Historia

La cantidad 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 transfiere 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 sistemas integrados y los mercados 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 en gran medida la migración 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. Portar un programa de este tipo entre dos plataformas compatibles con los estándares (como POSIX.1) puede ser solo una cuestión de cargar el código fuente y volver a compilarlo en la nueva plataforma. Sin embargo, los profesionales a menudo encuentran que se requieren varias correcciones menores, debido a las diferencias sutiles de la plataforma. 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 migración, 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 para algunos lenguajes de programación de alto nivel (p. ej., 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 (pero distintas de) la migración son la emulación y la compilación cruzada.

Portar 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). 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 un 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.

El uso de código intermedio mejora la portabilidad del compilador, porque 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 ser procesado por el intérprete o generador de código portado, produciendo así el software del compilador o ejecutando directamente el código intermedio en el intérprete. La parte independiente de la máquina se puede desarrollar y probar en otra máquina (la máquina host). Esto reduce en gran medida los esfuerzos de diseño, porque la parte independiente de la máquina debe desarrollarse solo una vez para crear un código intermedio portátil.

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 realizar optimizaciones de código debido a su vista limitada del código del programa (solo ve una instrucción a la vez y necesita un 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.

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, mejor conocido como arranque del compilador, sea factible en la máquina de destino:

1. Por el intérprete. Esto necesita ser codificado en código de montaje, utilizando un ensamblador ya presente en el objetivo.
2. Adapte la fuente del generador de código a la nueva máquina.
3. Ejecute la fuente adaptada usando 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 de BCPL) es más compacto que el código de máquina; típicamente por un factor de dos a uno. Sin embargo, el código interpretado se ejecuta diez veces más lento que el código compilado en la misma máquina.

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 objetivo..

Portabilidad de videojuegos

Portar también es el término que se usa 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. Desde el comienzo de los videojuegos hasta la década de 1990, las "portaciones", en ese momento conocidas como "conversiones", a menudo no eran verdaderas versiones, sino versiones modificadas de los juegos debido a 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. 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 necesidad de una portabilidad real (en lugar de depender de la portabilidad común de bibliotecas de componentes individuales).

Transportar juegos de arcade a sistemas domésticos con hardware inferior fue difícil. 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 en la ROM y el hardware tuvo problemas cuando aparecieron múltiples fantasmas en la pantalla creando un parpadeo. efecto. Algunos académicos citan el bajo rendimiento del Atari 2600 Pac-Man como una de las causas del colapso del videojuego de 1983.

Muchos de los primeros puertos sufrieron problemas significativos en la calidad del juego porque las computadoras diferían mucho. Richard Garriott declaró en 1984 en Origins Game Fair que Origin Systems desarrolló juegos de computadora para la serie Apple II primero y luego los transfirió a Commodore 64 y Atari de 8 bits, porque estas últimas máquinas & # 39; los sprites y otras características sofisticadas hicieron que la migración de ellos a Apple fuera "mucho más difícil, quizás incluso imposible". Las revisiones se quejaron de los puertos que sufrían de 'conversión de Apple', conservando el 'sonido pésimo y los gráficos negro-blanco-verde-púrpura' de Apple; después de la declaración de Garriott, cuando Dan Bunten preguntó 'A la gente de Atari y Commodore en la audiencia, ¿estás contento con las reescrituras de Apple?' el público gritaba "¡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 cuestión de dinero.

Otros funcionaron de manera diferente. Ozark Softscape, por ejemplo, primero escribió M.U.L.E. para Atari porque prefería desarrollar para las computadoras más avanzadas, eliminando o alterando funciones según fuera necesario durante la migración. Tal política no siempre fue factible; Bunten declaró que "M.U.L.E. no se puede hacer para Apple, y que las versiones que no son de Atari de Las siete ciudades de oro eran inferiores. Compute!'s Gazette escribió en 1986 que al migrar de Atari a Commodore, el original solía ser superior. Los juegos de este último la calidad mejoró cuando los desarrolladores comenzaron a crear un nuevo software para él a fines de 1983, afirmó la revista.

Al portar juegos de arcade, los términos "arcade perfect" o "arcade precisa" a menudo se usaban para describir qué tan cerca la jugabilidad, los gráficos y otros activos en 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 para arcade, ya que las consolas domésticas y las computadoras carecían del hardware sofisticado en 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 estrella de la consola a pesar de sus diferencias, mientras que el posterior puerto de Pac-Man fue notorio por sus desviaciones de la versión arcade. Los juegos con precisión 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 arcade perfectos.

Un "puerto 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 migrar un juego de una consola a una PC a menudo se considera negativo debido a que los niveles más altos de rendimiento que las computadoras generalmente tienen están infrautilizados, en parte debido a que el hardware de la consola se repara a lo largo de su ejecución (con juegos que se desarrollan para las especificaciones de la consola), mientras que las PC se vuelven más poderosas a medida que el hardware evoluciona, pero también debido a que los juegos portados a veces están mal optimizados para PC o se portan con lentitud. Si bien son muy similares, pueden existir diferencias arquitectónicas, como el uso de memoria unificada en una consola.