Port (informática)

En ingeniería de software, un port es una adaptación de un programa a otra plataforma. Un programa se considera portable si el precio de adaptarlo a otra plataforma es significativamente menos que el precio de programarlo desde cero.

Etimología

El término port proviene del latín portāre, 'portar'.^[1]​ Si un programa no es compatible con un sistema operativo o arquitectura particular, el código debe ser «portado» al nuevo sistema.

El término generalmente no se aplica al proceso de adaptar un programa para usar menos memoria en el mismo sistema operativo y CPU, ni al proceso de escribir desde cero el código de fuente en otro lenguaje de programación (es decir, conversión de lenguaje o traducción).

Algunos desarrolladores de software afirman que su código es portable, refiriéndose a que poco esfuerzo se necesita para adaptar el programa a otro sistema. Sin embargo, cuanto esfuerzo se necesita depende de varios factores, incluidas la diferencia del sistema original entre el sistema nuevo y la experiencia de los autores originales en saber en qué cada lenguaje de programación constituye. También esto es teniendo en cuenta que muchas librerías de terceros son imposibles de ser portadas.

Historia

El número de CPUs y sistemas operativos significativamente diferentes instalados en las computadoras de hoy es mucho más pequeño que en el pasado. El predominio de la arquitectura x86 significa que la mayoría de software nunca se porta a una CPU diferente. En el mismo mercado, la elección de sistemas operativos fue efectivamente reducida a tres: Microsoft Windows, MacOS y GNU/Linux. Sin embargo, en los sistemas embebidos y en el mercado móvil, la portabilidad sigue siendo un problema significativo, con la ARM siendo una alternativa ampliamente usada.

Las normas internacionales, como las que promulgó la ISO, facilitan el desarrollo de ports por la especificación de detalles del entorno informático que ayuda a reducir diferencias entre plataformas que conforman con normas diferentes. Escribir programas conformes a las normas especificadas representa un esfuerzo práctico pero no trivial. Hacer un port de tal programa entre dos plataformas que cumplen con las mismas normas puede ser mera cuestión de cargar el código de fuente y volver a compilarlo en la nueva plataforma. Sin embargo, los practicantes encuentran que varias correcciones menores se requieren, debido a las diferencias sutiles entre plataformas. La mayoría de las normas sufren de «áreas grises» donde las diferencias de interpretación de normas causan variaciones pequeñas dependiendo de la plataforma.

También existe un gran número creciente de herramientas para facilitar el desarrollo de ports, como el GNU Compiler Collection, que provee 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 según corresponda antes de compilarlo.

Los compiladores de algunos lenguajes de programación de alto nivel, (por ejemplo Eiffel y Esterel) obtienen portabilidad ejecutando el código de fuente en otro lenguaje intermedio (como C) para el cual muchas plataformas están generalmente disponibles.

Dos conceptos relacionados con ports, pero distintos, son emuladores y compiladores cruzados.

Port de compiladores

En vez de traducir directamente a un lenguaje 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).^[2]​ Las instrucciones del lenguaje intermedio se traducen a secuencias equivalentes por 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 interpretador o JIT para la máquina virtual.^[3]​

El uso de código intermedio mejora la portabilidad del compilador, porque solo el código dependiente de la máquina (el interpretador o el generador de código) necesita ser portado al nuevo sistema. El resto del compilador puede ser portado como código intermedio y luego procesado por el generador de código portado o el interpretador, así produciendo el software del compilador o directamente ejecutando el código intermedio en el interpretador. La parte que depende de la máquina puede desarrollarse y testearse en otra máquina (la máquina anfitriona). Esto reduce significativamente los empeños de diseño, porque la parte independiente de la máquina necesita desarrollarse solamente una vez para crear código intermedio portable.^[4]​

Un interpretador es menos complejo y es más fácil de portar que un generador de código, porque no es capaz de hacer optimización de código debido a su acceso limitado al código del programa. (solo procesa una instrucción a la vez, y necesita una secuencia para la optimización). Algunos interpretadores son extremadamente fáciles de portar, porque únicamente hacen suposiciones mínimas sobre el conjunto de instrucciones del hardware subyacente. Como resultado, la máquina virtual es aún más simple que la CPU de destino.^[5]​

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

1. Portar el interpretador. Este código debe ser escrito en lenguaje ensamblador, usando un ensamblador preexistente.
2. Adaptar la fuente del generador de código al nuevo sistema.
3. Ejecutar la fuente adaptada utilizando el interpretador con el generador de código como input. Esto generará el código de máquina para el generador de código.

La parte difícil de la optimización de código se hace empleando lenguaje de alto nivel en vez del lenguaje ensamblador del destino.

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, ejecutar código interpretado es 10 veces más lento que código compilado en la misma máquina.^[6]​

Los diseñadores del lenguaje de programación Java intentan aprovecharse de la compacidad del código interpretado, porque un programa de Java tal vez necesite ser transmitido a través de Internet antes de su ejecución en la máquina virtual Java de destino.

Port de videojuegos

Véase también: Conversión de videojuegos

Port también se refiere al hecho de convertir un videojuego diseñado a ejecutarse en una sola plataforma, ya sea de arcade, una consola de videojuegos, o una computadora personal, para ejecutarse en otra plataforma. Desde el comienzo de videojuegos hasta 1990, muchos ports, en aquel entonces llamados «conversiones», a menudo no eran ports verdaderos, sino versiones modificadas de los juegos debido a las limitaciones de los diferentes sistemas. Sin embargo, muchos videojuegos del siglo XXI se desarrollan usando software (comúnmente usando C++) capaz de ejecutar código en una o más consolas sin la necesidad de hacer port (usando el port común de la librería de componentes individual).

Hacer ports de juegos de arcade para sistemas domésticos con hardware inferior resultó difícil. La versión port de Pac-man del sistema Atari 2600 omitió muchos de los aspectos visuales del juego original para compensar la falta de espacio en la imagen ROM. Hubo problemas de mal funcionamiento de hardware cuando estaba más de un fantasma en la pantalla, haciéndola parpadear. Algunos académicos citan que la crisis del videojuego de 1983 se debió a los malos resultados del port de Pac-Man.^[7]​

Muchos de los primeros ports sufrieron problemas significativos de jugabilidad a causa de las grandes diferencias existentes entre computadoras.^[8]​ Richard Garriott dijo que en 1984 en Origins Game Fair que Origin Systems desarrolló videojuegos para la familia de computadores de Apple II primero y luego hizo ports de ellos para los sistemas Commodore 64 y Atari 8-bit, ya que por los sprites y aspectos de estas últimas máquinas, hacer ports a sistemas Apple era «mucho más difícil, quizás incluso imposible».^[9]​ Hubo quejas sobre ports que sufrieron de "Apple conversionitis",^[10]​ conservando "el audio pésimo y los gráficos blanco-negro-verde-violeta" de Apple;^[11]​^[12]​ después de la declaración de Garriott, cuando le preguntó Danielle Bunten Berry a la audiencia «gente de Atari y Commodore, ¿están felices con las reescrituras de Apple?», la audiencia gritó, «¡No!» Garriott respondió, «[sino] la versión de Apple nunca va a ser terminada. Desde el punto de vista de un editor, sería imprudente en cuanto al dinero.»^[9]​

Sin embargo, algunos juegos eran diferentes. Por ejemplo, Ozark Softscape, escribió M.U.L.E. primero en la Atari porque prefirió desarrollar en los computadores más avanzados, removiendo o cambiando aspectos según sea necesario al hacer el port. Pero esta política no era del todo factible; Bunten dijo que, "M.U.L.E. no puede ser hecha para un sistema de Apple,"^[8]​ y que las versiones no Atari de The Seven Cities of Gold eran inferiores.^[13]​ Compute!'s Gazette escribió en 1986 que al portar desde Atari a Commodore la original era usualmente superior. La calidad de los juegos de esta última mejoró cuando se comenzó a desarrollar software para ella a finales de 1983, cita la revista.^[14]​

Que un juego sea «arcade perfect», quiere decir que el juego fue portado de una versión de arcade a otra plataforma, como a una consola o una computadora, sin alteraciones significativas al funcionamiento del juego. Esto significa que el gráfico, el audio y la jugabilidad, junto con las otras características del juego (como bugs), son iguales a los de la versión original. Esto usualmente significa que las diferencias son menores (como tiempo de carga más largo), o simplemente que el port era el que más conservó la experiencia del juego original.

Port (de consola) es un juego originalmente hecho para una consola (como una Wii o Xbox 360) antes de la creación de una versión idéntica que puede ser jugada en una computadora personal o en cualquier otra consola. Este término ha sido altamente usado por la comunidad de videojuegos. El proceso de portar un juego de una consola a PC muchas veces se considera negativamente debido a que se infravaloren los niveles altos de rendimiento que generalmente tienen las PCs, en parte porque se lanzan versiones de arreglo de hardware de consolas durante su curso (con juegos que se desarrollan para las especificaciones de la consola), mientras las PCs se vuelven más poderosas a medida que el hardware evoluciona, pero también porque a veces los ports de juegos están mal optimizados para PC, o hechos perezosamente. Si bien son muy similares, pueden existir diferencias arquitectónicas, como el uso de memoria unificada en una consola.

Referencias

• Esta obra contiene una traducción derivada de «Porting» de Wikipedia en inglés, publicada por sus editores bajo la Licencia de documentación libre de GNU y la Licencia Creative Commons Atribución-CompartirIgual 4.0 Internacional.

Véase también

• Emulador de videoconsola
• Interoperabilidad
• Multiplataforma

Referencias

1. «port, v.2». Oxford English Dictionary (OED Online). Oxford University Press. Consultado el 21 de diciembre de 2017. 
2. Tanenbaum, 1984, p. 3. §1.1 Languages, Levels, and Virtual Machines describes the terms and their relations.
3. Tanenbaum, 1984, p. 2. Ch. 1 Introduction explains translation and interpretation.
4. Richards y Whitby-Strevens, 1984, p. 124. §7.1 Introduction explains compiler portability using intermediate code.
5. Richards y Whitby-Strevens, 1984, p. 133. §7.4 The bootstrapping process and INTCODE explains the role of the INTCODE interpreter.
6. Richards y Whitby-Strevens, 1984, p. 136. §7.4.3 Example gives an example translation of a BCPL program into INTCODE for the interpreter.
7. 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. 
8. Bunten, Dan (December 1984). «Dispatches / Insights From the Strategy Game Design Front». Computer Gaming World: 40. Consultado el 31 de octubre de 2013. 
9. «The CGW Computer Game Conference». Computer Gaming World (panel discussion): 30. October 1984. Consultado el 31 de octubre de 2013. 
10. Dunnington, Benn; Brown, Mark R.; Malcolm, Tom (January–February 1987). «64/128 Gallery». Info: 14-21. 
11. Stanton, Jeffrey; Wells, Robert P.; Rochowansky, Sandra et al., eds. (1984). The Addison-Wesley Book of Atari Software. Addison-Wesley. pp. 12,21,44,126. ISBN 0-201-16454-X.  Se sugiere usar |número-editores= (ayuda)
12. Bernstein, Harvey (May 1985). «Beyond Castle Wolfenstein». Antic. p. 83. Consultado el 8 de enero de 2015. 
13. Bunten, Dan. «The Game Collection». Ozark Softscape M.U.L.E. Archivado desde el original el 28 de enero de 2021. Consultado el 4 de octubre de 2017. 
14. Yakal, Kathy (June 1986). «The Evolution of Commodore Graphics». Compute!'s Gazette: 34-42. Consultado el 18 de junio de 2019. 

• Datos: Q851989