In computing, executable code or an executable file or executable program, sometimes referred to as an executable, causes a computer "to perform indicated tasks according to encoded instructions," as opposed to a data file that must be parsed by a program to be meaningful. The exact interpretation depends upon the use - while "instructions" is traditionally taken to mean machine code instructions for a physical CPU, in some contexts a file containing bytecode or scripting language instructions may be considered executable. Executable files can be hand-coded in machine language, although it is far more convenient to develop software as source code in a high-level language that can be understood by humans. In some cases, source code might be specified in assembly language instead, which remains human-readable while being associated with machine code instructions; the high-level language is compiled into either an executable machine code file or a non-executable machine-code object file of some sort.
Several object files are linked to create the executable. Object files, executable or not, are in a container format, such as Executable and Linkable Format; this structures the generated machine code, for example dividing it into sections such as the.text.data, and.rodata. In order to be executed by the system, an executable file must conform to the system's application binary interface. Most a file is executed by loading the file into memory and jumping to the start of the address space and executing from there, but in more complicated interfaces executable files have additional metadata, specifying a separate entry point. For example, in ELF, the entry point is specified in the header in the e_entry field, which specifies the memory address at which to start execution. In the GCC this field is set by the linker based on the _start symbol. Executable files also include a runtime system, which implements runtime language features and interactions with the operating system, notably passing arguments and returning an exit status, together with other startup and shutdown features such as releasing resources like file handles.
For C, this is done by linking in the crt0 object, which contains the actual entry point and does setup and shutdown by calling the runtime library. Executable files thus contain significant additional machine code beyond that directly generated from the specific source code. In some cases it is desirable to omit this, for example for embedded systems development or to understand how compilation and loading work. In C this can be done by omitting the usual runtime, instead explicitly specifying a linker script, which generates the entry point and handles startup and shutdown, such as calling main to start and returning exit status to kernel at end. Comparison of executable file formats EXE File Format at What Is
The Zend Engine is the open source scripting engine that interprets the PHP programming language. It was developed by Andi Gutmans and Zeev Suraski while they were students at the Technion – Israel Institute of Technology, they founded a company called Zend Technologies in Ramat Gan, Israel. The name Zend is a combination of their forenames and Andi; the first version of the Zend Engine appeared in 1999 in PHP version 4. It was written in C as a optimized modular back-end, which for the first time could be used in applications outside of PHP; the Zend Engine provides memory and resource management, other standard services for the PHP language. Its performance and extensibility played a significant role in PHP's increasing popularity; this was followed by Zend Engine II at the heart of PHP 5. The newest version is Zend Engine III codenamed phpng, developed for PHP 7 and improves performance; the source code for the Zend Engine has been available under the Zend Engine License since 2001, as part of the official releases from php.net, as well as the official git repository or the GitHub mirror.
Various volunteers contribute to the PHP/Zend Engine codebase. Zend Engine is used internally by PHP as a Runtime engine. PHP Scripts are compiled into Zend opcodes; these opcodes are executed and the HTML generated is sent to the client. To implement a Web script interpreter, you need three parts: The interpreter part analyzes the input code, translates it, executes it; the functionality part implements the functionality of the language. The interface part talks to etc.. Zend takes part 1 and a bit of part 2. Zend itself forms only the language core, implementing PHP at its basics with some predefined functions. Zend Engine Homepage Zend Engine 2.0 Design document The Zend Engine License, version 2.00 Official git repository Github repository mirror Zend Engine 1 section in PHP manual Zend Engine 2 API reference in PHP manual Zend Engine 3 section in PHP manual Documentation on the PHP development wiki
Machine code is a computer program written in machine language instructions that can be executed directly by a computer's central processing unit. Each instruction causes the CPU to perform a specific task, such as a load, a store, a jump, or an ALU operation on one or more units of data in CPU registers or memory. Machine code is a numerical language, intended to run as fast as possible, may be regarded as the lowest-level representation of a compiled or assembled computer program or as a primitive and hardware-dependent programming language. While it is possible to write programs directly in machine code, it is tedious and error prone to manage individual bits and calculate numerical addresses and constants manually. For this reason, programs are rarely written directly in machine code in modern contexts, but may be done for low level debugging, program patching, assembly language disassembly; the overwhelming majority of practical programs today are written in higher-level languages or assembly language.
The source code is translated to executable machine code by utilities such as compilers and linkers, with the important exception of interpreted programs, which are not translated into machine code. However, the interpreter itself, which may be seen as an executor or processor, performing the instructions of the source code consists of directly executable machine code. Machine code is by definition the lowest level of programming detail visible to the programmer, but internally many processors use microcode or optimise and transform machine code instructions into sequences of micro-ops, this is not considered to be a machine code per se; every processor or processor family has its own instruction set. Instructions are patterns of bits that by physical design correspond to different commands to the machine. Thus, the instruction set is specific to a class of processors using the same architecture. Successor or derivative processor designs include all the instructions of a predecessor and may add additional instructions.
A successor design will discontinue or alter the meaning of some instruction code, affecting code compatibility to some extent. Systems may differ in other details, such as memory arrangement, operating systems, or peripheral devices; because a program relies on such factors, different systems will not run the same machine code when the same type of processor is used. A processor's instruction set may have all instructions of the same length, or it may have variable-length instructions. How the patterns are organized varies with the particular architecture and also with the type of instruction. Most instructions have one or more opcode fields which specifies the basic instruction type and the actual operation and other fields that may give the type of the operand, the addressing mode, the addressing offset or index, or the actual value itself. Not all machines or individual instructions have explicit operands. An accumulator machine has a combined left operand and result in an implicit accumulator for most arithmetic instructions.
Other architectures have accumulator versions of common instructions, with the accumulator regarded as one of the general registers by longer instructions. A stack machine has all of its operands on an implicit stack. Special purpose instructions often lack explicit operands; this distinction between explicit and implicit operands is important in code generators in the register allocation and live range tracking parts. A good code optimizer can track implicit as well as explicit operands which may allow more frequent constant propagation, constant folding of registers and other code enhancements. A computer program is a list of instructions. A program's execution is done in order for the CPU, executing it to solve a specific problem and thus accomplish a specific result. While simple processors are able to execute instructions one after another, superscalar processors are capable of executing a variety of different instructions at once. Program flow may be influenced by special'jump' instructions that transfer execution to an instruction other than the numerically following one.
Conditional jumps are not depending on some condition. A much more readable rendition of machine language, called assembly language, uses mnemonic codes to refer to machine code instructions, rather than using the instructions' numeric values directly. For example, on the Zilog Z80 processor, the machine code 00000101, which causes the CPU to decrement the B processor register, would be represented in assembly language as DEC B; the MIPS architecture provides a specific example for a machine code whose instructions are always 32 bits long. The general type of instruction is given by the op field. J-type and I-type instructions are specified by op. R-type instructions include an additional field funct to determine the exact operation; the fields used in the
PHP: Hypertext Preprocessor is a general-purpose programming language designed for web development. It was created by Rasmus Lerdorf in 1994. PHP stood for Personal Home Page, but it now stands for the recursive initialism PHP: Hypertext Preprocessor. PHP code may be executed with a command line interface, embedded into HTML code, or it can be used in combination with various web template systems, web content management systems, web frameworks. PHP code is processed by a PHP interpreter implemented as a module in a web server or as a Common Gateway Interface executable; the web server combines the results of the interpreted and executed PHP code, which may be any type of data, including images, with the generated web page. PHP can be used for many programming tasks outside of the web context, such as standalone graphical applications and robotic drone control; the standard PHP interpreter, powered by the Zend Engine, is free software released under the PHP License. PHP has been ported and can be deployed on most web servers on every operating system and platform, free of charge.
The PHP language evolved without a written formal specification or standard until 2014, with the original implementation acting as the de facto standard which other implementations aimed to follow. Since 2014, work has gone on to create a formal PHP specification. PHP development began in 1994 when Rasmus Lerdorf wrote several Common Gateway Interface programs in C, which he used to maintain his personal homepage, he extended them to work with web forms and to communicate with databases, called this implementation "Personal Home Page/Forms Interpreter" or PHP/FI. PHP/FI could be used to build dynamic web applications. To accelerate bug reporting and improve the code, Lerdorf announced the release of PHP/FI as "Personal Home Page Tools version 1.0" on the Usenet discussion group comp.infosystems.www.authoring.cgi on June 8, 1995. This release had the basic functionality that PHP has today; this included Perl-like variables, form handling, the ability to embed HTML. The syntax was simpler, more limited and less consistent.
Early PHP was not intended to be a new programming language, grew organically, with Lerdorf noting in retrospect: "I don't know how to stop it, there was never any intent to write a programming language I have no idea how to write a programming language, I just kept adding the next logical step on the way." A development team began to form and, after months of work and beta testing released PHP/FI 2 in November 1997. The fact that PHP was not designed, but instead was developed organically has led to inconsistent naming of functions and inconsistent ordering of their parameters. In some cases, the function names were chosen to match the lower-level libraries which PHP was "wrapping", while in some early versions of PHP the length of the function names was used internally as a hash function, so names were chosen to improve the distribution of hash values. Zeev Suraski and Andi Gutmans rewrote the parser in 1997 and formed the base of PHP 3, changing the language's name to the recursive acronym PHP: Hypertext Preprocessor.
Afterwards, public testing of PHP 3 began, the official launch came in June 1998. Suraski and Gutmans started a new rewrite of PHP's core, producing the Zend Engine in 1999, they founded Zend Technologies in Ramat Gan, Israel. On May 22, 2000, PHP 4, powered by the Zend Engine 1.0, was released. As of August 2008 this branch reached version 4.4.9. PHP 4 will any security updates be released. On July 14, 2004, PHP 5 was released, powered by the new Zend Engine II. PHP 5 included new features such as improved support for object-oriented programming, the PHP Data Objects extension, numerous performance enhancements. In 2008, PHP 5 became the only stable version under development. Late static binding had been missing from PHP and was added in version 5.3. Many high-profile open-source projects ceased to support PHP 4 in new code as of February 5, 2008, because of the GoPHP5 initiative, provided by a consortium of PHP developers promoting the transition from PHP 4 to PHP 5. Over time, PHP interpreters became available on most existing 32-bit and 64-bit operating systems, either by building them from the PHP source code, or by using pre-built binaries.
For PHP versions 5.3 and 5.4, the only available Microsoft Windows binary distributions were 32-bit x86 builds, requiring Windows 32-bit compatibility mode while using Internet Information Services on a 64-bit Windows platform. PHP version 5.5 made. Official security support for PHP 5.6 ended on 31 December 2018, but Debian 8.0 Jessie will extend support until June 2020. PHP received mixed reviews due to lacking native Unicode support at the core language level. In 2005, a project headed by Andrei Zmievski was initiated to bring native Unicode support throughout PHP, by embedding the International Components for Unicode library, representing text strings as UTF-16 internally. Since this would cause major changes both to the internals of the language and to user code, it was planned to release this as version 6.0 of the language, along with other major features in development. However, a shortage of developers who understood the necessary changes, performance problems arising from conversion to and from UTF-16, used in a web context, led to delays in the project.
As a result, a PHP 5.3 release was created in 2009, with many non-Unicode f
Android Runtime is an application runtime environment used by the Android operating system. Replacing Dalvik, the process virtual machine used by Android, ART performs the translation of the application's bytecode into native instructions that are executed by the device's runtime environment. Android 2.2 "Froyo" brought trace-based just-in-time compilation into Dalvik, optimizing the execution of applications by continually profiling applications each time they run and dynamically compiling executed short segments of their bytecode into native machine code. While Dalvik interprets the rest of application's bytecode, native execution of those short bytecode segments, called "traces", provides significant performance improvements. Unlike Dalvik, ART introduces the use of ahead-of-time compilation by compiling entire applications into native machine code upon their installation. By eliminating Dalvik's interpretation and trace-based JIT compilation, ART improves the overall execution efficiency and reduces power consumption, which results in improved battery autonomy on mobile devices.
At the same time, ART brings faster execution of applications, improved memory allocation and garbage collection mechanisms, new applications debugging features, more accurate high-level profiling of applications. To maintain backward compatibility, ART uses the same input bytecode as Dalvik, supplied through standard.dex files as part of APK files, while the.odex files are replaced with Executable and Linkable Format executables. Once an application is compiled by using ART's on-device dex2oat utility, it is run from the compiled ELF executable; as a downside, ART requires additional time for the compilation when an application is installed, applications take up larger amounts of secondary storage to store the compiled code. Android 4.4 KitKat brought a technology preview of ART, including it as an alternative runtime environment and keeping Dalvik as the default virtual machine. In the subsequent major Android release, Android 5.0 Lollipop, Dalvik was replaced by ART. Android 7.0 Nougat introduced JIT compiler with code profiling to ART, which lets it improve the performance of Android apps as they run.
The JIT compiler complements ART's current Ahead of Time compiler and helps improve runtime performance. Android software development – various concepts and software development utilities used for the creation of Android applications Android version history – a history and descriptions of Android releases, listed by their official API levels Comparison of application virtualization software – various portable and scripting language virtual machines Virtual machine – an emulation of a particular computer system, with different degrees of implemented functionality Official website Android Basics 101: Understanding ART, the Android Runtime on YouTube, XDA Developers, February 12, 2014 ART: Android's Runtime Evolved on YouTube, Google I/O 2014, by Anwar Ghuloum, Brian Carlstrom and Ian Rogers A JIT Compiler for Android's Dalvik VM on YouTube, Google I/O 2010, by Ben Cheng and Bill Buzbee Delivering Highly Optimized Android Runtime and Web Runtime on Intel Architecture, August 4, 2015, by Haitao Feng and Jonathan Ding Android 7.1 for Developers: Profile-guided JIT/AOT compilation, Android Developers, describes ART changes in Android 7 Optimise Android For Better Performance, Refer By Android Developer
Java virtual machine
A Java virtual machine is a virtual machine that enables a computer to run Java programs as well as programs written in other languages that are compiled to Java bytecode. The JVM is detailed by a specification that formally describes what is required of a JVM implementation. Having a specification ensures interoperability of Java programs across different implementations so that program authors using the Java Development Kit need not worry about idiosyncrasies of the underlying hardware platform; the JVM reference implementation is developed by the OpenJDK project as open source code and includes a JIT compiler called HotSpot. The commercially supported Java releases available from Oracle Corporation are based on the OpenJDK runtime. Eclipse OpenJ9 is another open source JVM for OpenJDK; the Java virtual machine is an abstract computer defined by a specification. The garbage-collection algorithm used and any internal optimization of the Java virtual machine instructions are not specified; the main reason for this omission is to not unnecessarily constrain implementers.
Any Java application can be run only inside some concrete implementation of the abstract specification of the Java virtual machine. Starting with Java Platform, Standard Edition 5.0, changes to the JVM specification have been developed under the Java Community Process as JSR 924. As of 2006, changes to specification to support changes proposed to the class file format are being done as a maintenance release of JSR 924; the specification for the JVM was published as the blue book, The preface states: We intend that this specification should sufficiently document the Java Virtual Machine to make possible compatible clean-room implementations. Oracle provides tests that verify the proper operation of implementations of the Java Virtual Machine. One of Oracle's JVMs is named the other, inherited from BEA Systems is JRockit. Clean-room Java implementations include Kaffe, IBM J9 and Skelmir's CEE-J. Oracle owns the Java trademark and may allow its use to certify implementation suites as compatible with Oracle's specification.
One of the organizational units of JVM byte code is a class. A class loader implementation must be able to recognize and load anything that conforms to the Java class file format. Any implementation is free to recognize other binary forms besides class files, but it must recognize class files; the class loader performs three basic activities in this strict order: Loading: finds and imports the binary data for a type Linking: performs verification and resolution Verification: ensures the correctness of the imported type Preparation: allocates memory for class variables and initializing the memory to default values Resolution: transforms symbolic references from the type into direct references. Initialization: invokes Java code that initializes class variables to their proper starting values. In general, there are two types of class loader: bootstrap class loader and user defined class loader; every Java virtual machine implementation must have a bootstrap class loader, capable of loading trusted classes.
The Java virtual machine specification doesn't specify. The JVM operates on primitive references; the JVM is fundamentally a 32-bit machine. Long and double types, which are 64-bits, are supported natively, but consume two units of storage in a frame's local variables or operand stack, since each unit is 32 bits. Boolean, byte and char types are all sign-extended and operated on as 32-bit integers, the same as int types; the smaller types only have a few type-specific instructions for loading and type conversion. Boolean is operated on with 0 representing false and 1 representing true; the JVM has a garbage-collected heap for storing arrays. Code and other class data are stored in the "method area"; the method area is logically part of the heap, but implementations may treat the method area separately from the heap, for example might not garbage collect it. Each JVM thread has its own call stack, which stores frames. A new frame is created each time a method is called, the frame is destroyed when that method exits.
Each frame provides an "operand stack" and an array of "local variables". The operand stack is used for operands to computations and for receiving the return value of a called method, while local variables serve the same purpose as registers and are used to pass method arguments. Thus, the JVM is both a register machine; the JVM has instructions for the following groups of tasks: The aim is binary compatibility. Each particular host operating system needs its own implementation of the runtime; these JVMs interpret the bytecode semantically the same way, but the actual implementation may be different. More complex than just emulating bytecode is compatibly and efficiently im