User:Jsoon eu/thoughts on porting

This is a Wikipedia user page.
This is not an encyclopedia article or the talk page for an encyclopedia article. If you find this page on any site other than Wikipedia, you are viewing a mirror site. Be aware that the page may be outdated and that the user in whose space this page is located may have no personal affiliation with any site other than Wikipedia. The original page is located at https://en.wikipedia.org/wiki/User:Jsoon_eu/thoughts_on_porting.

In computer science, porting is the process of adapting software so that an executable program can be created for a computing environment that is different from the one for which it was originally designed (e.g. different CPU, operating system, or third party library). The term's also used for when software/hardware is changed to make them usable in different environments.

Software is portable when the cost of porting it to a new platform is 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.

Etymology

The term 'port' is derived from the Latin portare, meaning 'to carry'.^{[citation needed]} When code is not compatible with a particular OS or architecture, 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, nor is it applied to the rewriting of source code in a different language (i.e. language conversion or translation).

Software developers often claim that the software they write is portable, 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 (the source platform) differs from the new environment (the target platform), the experience of the original authors in knowing which programming 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).

History

The number of significantly different CPUs and operating systems used on the desktop today is much smaller than in the past. ^{[citation needed]} The dominance of the x86 architecture 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, Mac OS/Mac OS X, and Unix/Linux. However, in the embedded systems market, portability remains a significant issue.

International standards, such as those promulgated by the ISO, greatly facilitate porting by specifying details of the computing environment in a way that helps reduce differences between different standards-conforming platforms. 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 as POSIX.1) can be just a matter of loading the source code and recompiling it on the new platform. However, 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 the GNU Compiler Collection, which provides consistent programming languages on different platforms, and Autotools, which automates the detection of minor variations in the environment and adapts the software accordingly before compilation.

The compilers for some high-level programming languages (e.g. Eiffel, Esterel) gain portability by outputting source code in another high level intermediate language (such as C) for which compilers for many platforms are generally available.

Two activities related to (but distinct from) porting are emulating and cross-compiling.

Porting compilers

Instead of translating directly into machine code, modern compilers translate to a machine independent intermediate code in order to enhance portability of the compiler and minimize design efforts. The intermediate language defines a virtual machine that can execute all programs written in the intermediate language (a machine is defined by its language and vice versa).^[1] The intermediate code instructions are translated into equivalent machine code sequences by a code generator to create executable code. It is also possible to skip the generation of machine code by actually implementing the virtual machine in machine code. This virtual machine implementation is called an interpreter, because it reads in the intermediate code instructions one by one and after each read executes the equivalent machine code sequences (the interpretation) of the read intermediate instruction directly.^[2]

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 and tested on another machine (the host machine). This greatly reduces design efforts, because the machine independent part needs to be developed only once to create portable intermediate code.^[3]

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 you need a sequence to do optimization). Some interpreters are extremely easy to port, because they only make very minimal assumptions about the instruction set of the underlying hardware. As a result the virtual machine is even simpler than the target CPU.^[4]

Writing the compiler sources entirely in the programming language the compiler is supposed to translate, makes the following aproach, better known as compiler bootstrapping, feasible on the target machine:

Port the interpreter. This needs to be coded in assembly code, using an already present assembler on the target.
Adapt the source of the code generator to the new machine.
Execute the adapted source using the interpreter with the code generator source as input. This will generate the machine code for the code generator.

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 the BCPL 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.^[5]

The designers of the Java programming language try to take advantage of the compactness of interpreted code, because in Java a program needs to be transmitted over the Internet before execution can start on the target's Java Virtual Machine.

Porting in gaming

Porting is also the term used when a computer game designed to run on one platform, be it a personal computer or a video game console, is converted to run on a different platform. Earlier video game "ports" were often not true ports, but rather reworked versions of the games. However, more and more video games are now being developed using software that can output code for PCs as well as for one or more consoles. Many early ports suffered significant gameplay quality issues because the hardware of PCs and consoles differed so dramatically.

Arcade perfect is a term used to describe video games which have been ported from an arcade version to another platform, such as a console, without any alterations to the game's workings. This means that graphics, sound and gameplay, along with the game's other characteristics, are identical to the arcade version.

"Console Port" has been dubbed as a term specifically used to describe a game that has been previously made for a console (such as PS3 or XBOX 360) an making an identical version that can be played on a personal computer. This term has been widely used by the gaming community, primarily in a negative way. Example: In a webcast by www.bashandslash.com found specifally at url: http://bash.podbean.com/2010/01/17/bash-136-tears-of-joy/ , Activision's "Call of Duty, Modern Warfare 2" was referred to as the definition of a "console port."

Notes

^ Tanenbaum 1984, Section 1.1 - LANGUAGES,LEVELS, AND VIRTUAL MACHINES, p. 3, describes the terms and their relations.
^ Tanenbaum 1984, Chapter 1 - INTRODUCTION, p. 2, explains translation and interpretation.
^ Richards,Whitby-Strevens 1984, Section 7.1 - Introduction, p. 124, explains compiler portability using intermediate code.
^ Richards,Whitby-Strevens 1984, Section 7.4 - The bootstrapping process and INTCODE, p. 133, explains the role of the INTCODE interpreter.
^ Richards,Whitby-Strevens 1984, Section 7.4.3 - Example, p. 136, gives an example translation of a BCPL program into INTCODE for the interpreter.

References

Martin Richards and Colin Whitby-Strevens (1984): BCPL, the language and its compiler. ISBN 0-521-28681-6.
Andrew S. Tanenbaum (1984): Structured computer organization 10th Print. ISBN 0-13-854605-3.

Category:Source code

[Machinelanguage-1] Tanenbaum 1984, Section 1.1 - LANGUAGES,LEVELS, AND VIRTUAL MACHINES, p. 3, describes the terms and their relations.

[2] Tanenbaum 1984, Chapter 1 - INTRODUCTION, p. 2, explains translation and interpretation.

[3] Richards,Whitby-Strevens 1984, Section 7.1 - Introduction, p. 124, explains compiler portability using intermediate code.

[4] Richards,Whitby-Strevens 1984, Section 7.4 - The bootstrapping process and INTCODE, p. 133, explains the role of the INTCODE interpreter.

[5] Richards,Whitby-Strevens 1984, Section 7.4.3 - Example, p. 136, gives an example translation of a BCPL program into INTCODE for the interpreter.

[1]

[2]

[3]

[4]

[5]