Insoftware engineering,porting is the process of adaptingsoftware for the purpose of achieving some form of execution in acomputing environment that is different from the one that a given program (meant for such execution) was originally designed for (e.g., differentCPU, operating system, or third partylibrary). The term is also used when software/hardware is changed to make them usable in different environments.[1][2]
Software isportable when the cost of porting it to a new platform is significantly less than the cost of writing it from scratch. The lower the cost of porting software relative to its implementation cost, the more portable it is said to be. This is distinct fromcross-platform software, which is designed from the ground up without any single "native" platform.
The term "port" is derived from the Latinportāre, meaning "to carry".[3] When code is not compatible with a particularoperating system orarchitecture, the code must be "carried" to the new system.
The term is not generally applied to the process of adapting software to run with less memory on the same CPU and operating system.
Software developers often claim that the software they write isportable, meaning that little effort is needed to adapt it to a new environment. The amount of effort actually needed depends on several factors, including the extent to which the original environment (thesource platform) differs from the new environment (thetarget platform), the experience of the original authors in knowing whichprogramming language constructs and third party library calls are unlikely to be portable, and the amount of effort invested by the original authors in only using portable constructs (platform specific constructs often provide a cheaper solution).
The number of significantly different CPUs and operating systems used on the desktop today is much smaller than in the past. The dominance of thex86architecture means that most desktop software is never ported to a different CPU. In that same market, the choice of operating systems has effectively been reduced to three:Microsoft Windows,macOS, andLinux. However, in theembedded systems andmobile markets,portability remains a significant issue, with theARM being a widely used alternative.
International standards, such as those promulgated by theISO, greatly facilitate porting by specifying details of the computing environment in a way that helps reduce differences between different standards-conformingplatforms. Writing software that stays within the bounds specified by these standards represents a practical although nontrivial effort. Porting such a program between two standards-compliant platforms (such asPOSIX.1) can be just a matter of loading the source code andrecompiling it on the new platform, but practitioners often find that various minor corrections are required, due to subtle platform differences. Most standards suffer from "gray areas" where differences in interpretation of standards lead to small variations from platform to platform.
There also exists an ever-increasing number of tools to facilitate porting, such as theGNU Compiler Collection, which provides consistent programming languages on different platforms, andAutotools, which automates the detection of minor variations in the environment and adapts the software accordingly before compilation.
The compilers for somehigh-level programming languages (e.g.Eiffel,Esterel) gain portability by outputting source code in another high levelintermediate language (such asC) for which compilers for many platforms are generally available.
Two activities related to (but distinct from) porting areemulating andcross-compiling.
Instead of translating directly intomachine code, moderncompilers translate to a machine independentintermediate code in order to enhance portability of the compiler and minimize design efforts. The intermediate language defines avirtual machine that can execute all programs written in theintermediate language (a machine is defined by its language and vice versa).[4] The intermediate code instructions are translated into equivalent machine code sequences by acode generator to createexecutable code. It is also possible to skip the generation of machine code by actually implementing aninterpreter orJIT for the virtual machine.[5]
The use of intermediate code enhances portability of the compiler, because only the machine dependent code (the interpreter or the code generator) of the compiler itself needs to be ported to the target machine. The remainder of the compiler can be imported as intermediate code and then further processed by the ported code generator or interpreter, thus producing the compiler software or directly executing the intermediate code on the interpreter. The machine independent part can be developed andtested on another machine (thehost machine). This greatly reduces design efforts, because the machine independent part needs to be developed only once to create portable intermediate code.[6]
An interpreter is less complex and therefore easier to port than a code generator, because it is not able to do code optimizations due to its limited view of the program code (it only sees one instruction at a time, and users need a sequence to do optimization). Some interpreters are extremely easy to port, because they only make minimal assumptions about the instruction set of the underlying hardware. As a result, the virtual machine is even simpler than the target CPU.[7]
Writing the compiler sources entirely in the programming language the compiler is supposed to translate, makes the following approach, better known ascompiler bootstrapping, feasible on the target machine:
The difficult part of coding the optimization routines is done using the high-level language instead of the assembly language of the target.
According to the designers of theBCPL language, interpreted code (in the BCPL case) is more compact than machine code, typically by a factor of two to one. Interpreted code however runs about ten times slower than compiled code on the same machine.[8]
The designers of theJava programming language try to take advantage of the compactness of interpreted code, because a Java program may need to be transmitted over the Internet before execution can start on the target'sJava virtual machine (JVM).
Porting is also the term used when avideo game designed to run on one platform, be it anarcade,video game console, orpersonal computer, is converted to run on a different platform, perhaps with some minor differences.[9] From the beginning of video games through to the 1990s, "ports", at the time often known as "conversions", were often not true ports, but rather reworked versions of the games due to the limitations of different systems. For example, the 1982 gameThe Hobbit, a text adventure augmented with graphic images, has significantly different graphic styles across the range of personal computers that its ports were developed for.[10] However, many 21st century video games are developed using software (often inC++) that can output code for one or more consoles as well as for a PC without the need for actual porting (instead relying on the common porting of individual componentlibraries).[10]
Porting arcade games to home systems with inferior hardware was difficult. The ported version ofPac-Man for theAtari 2600 omitted many of the visual features of the original game to compensate for the lack ofROM space and the hardware struggled when multiple ghosts appeared on the screen creating a flickering effect. The poor performance of theAtari 2600Pac-Man is cited by some scholars as a cause of thevideo game crash of 1983.[11]
Many early ports suffered significant gameplay quality issues because computers greatly differed.[12]Richard Garriott stated in 1984 atOrigins Game Fair thatOrigin Systems developed video games for theApple II first then ported them toCommodore 64 andAtari 8-bit computers, because the latter machines'sprites and other sophisticated features made porting from them to Apple "far more difficult, perhaps even impossible".[13] Reviews complained of ports that suffered from "Apple conversionitis",[14] retaining the Apple's "lousy sound and black-white-green-purple graphics";[15][16] after Garriott's statement, whenDan Bunten asked "Atari and Commodore people in the audience, are you happy with the Apple rewrites?" the audience shouted "No!" Garriott responded, "[otherwise] the Apple version will never get done. From a publisher's point of view that's not money wise".[13]
Others worked differently.Ozark Softscape, for example, wroteM.U.L.E. for the Atari first because it preferred to develop for the most advanced computers, removing or altering features as necessary during porting. Such a policy was not always feasible; Bunten stated that "M.U.L.E. can't be done for an Apple",[12] and that the non-Atari versions ofThe Seven Cities of Gold were inferior.[17]Compute!'s Gazette wrote in 1986 that when porting from Atari to Commodore the original was usually superior. The latter's games' quality improved when developers began creating new software for it in late 1983, the magazine stated.[18]
In portingarcade games, the terms "arcade perfect" or "arcade accurate" were often used to describe how closely the gameplay, graphics, and other assets on the ported version matched the arcade version. Many arcade ports in the early 1980s were far from arcade perfect as home consoles and computers lacked the sophisticated hardware in arcade games, but games could still approximate the gameplay. Notably,Space Invaders on theAtari VCS became the console'skiller app despite its differences,[19] while the laterPac-Man port was notorious for its deviations from the arcade version.[20] Arcade-accurate games became more prevalent starting in the 1990s as home consoles caught up to the power of arcade systems. Notably, theNeo Geo system fromSNK, which was introduced as a multi-game arcade system, would also be offered as a home console with the same specifications. This allowed arcade perfect games to be played at home.[10]
A "console port" is a game that was originally or primarily made for a console before a version is created which can be played on apersonal computer. The process of porting games from console to PC is often regarded more cynically than other types of port due to the more powerful hardware some PCs have even at console launch being underutilized, partially due to console hardware being fixed throughout eachgeneration as newer PCs constantly become even more powerful. While broadly similar today, some architectural differences persist, such as the use ofunified memory and smallerOSs on consoles. Other objections arise fromuser interface differences conventional to consoles, such asgamepads,TFUIs accompanied by narrowFoV, fixedcheckpoints,online restricted to officialservers orP2P, poor or nomodding support, as well as the generally greater reliance among console developers on internalhard coding anddefaults instead of externalAPIs andconfigurability, all of which may require expensive deep reaching redesign to avoid a "lazy" feeling port to PC.[21]
.. discusses .. portability of .. Fortran
Origin: Of multiple origins. Partly a borrowing from French. Partly a borrowing from Latin. Etymons: Frenchporter; Latinportāre. ... 1.trans. To carry, bear, or convey; to bring.