Booting

In computing, booting is the process of starting a computer. It can be initiated by hardware such as a button press, or by a software command. After it is switched on, a computer's central processing unit (CPU) has no software in its main memory, so some process must load software into memory before it can be executed. This may be done by hardware or firmware in the CPU, or by a separate processor in the computer system.
Restarting a computer also is called rebooting, which can be "hard", e.g. after electrical power to the CPU is switched from off to on, or "soft", where the power is not cut. On some systems, a soft boot may optionally clear RAM to zero. Both hard and soft booting can be initiated by hardware such as a button press or by software command. Booting is complete when the operative runtime system, typically operating system and some applications, is attained.
The process of returning a computer from a state of sleep (suspension) does not involve booting; however, restoring it from a state of hibernation does. Minimally, some embedded systems do not require a noticeable boot sequence to begin functioning and when turned on may simply run operational programs that are stored in ROM. All computing systems are state machines, and a reboot may be the only method to return to a designated zero-state from an unintended, locked state.
In addition to loading an operating system or stand-alone utility, the boot process can also load a storage dump program for diagnosing problems in an operating system.
"Boot" is short for "bootstrap" or "bootstrap load" and derives from the phrase "to pull oneself up by one's bootstraps". The usage calls attention to the requirement that, if most software is loaded onto a computer by other software already running on the computer, some mechanism must exist to load the initial software onto the computer. Early computers used a variety of ad-hoc methods to get a small program into memory to solve this problem. The invention of read-only memory (ROM) of various types solved this paradox by allowing computers to be shipped with a start up program that could not be erased. Growth in the capacity of ROM has allowed ever more elaborate start up procedures to be implemented.
History.
There are many different methods available to load a short initial program into a computer. These methods reach from simple, physical input to removable media that can hold more complex programs.
Pre integrated-circuit-ROM examples.
Early computers.
Early computers in the 1940s and 1950s were one-of-a-kind engineering efforts that could take weeks to program and program loading was one of many problems that had to be solved. An early computer, ENIAC, had no program stored in memory, but was set up for each problem by a configuration of interconnecting cables. Bootstrapping did not apply to ENIAC, whose hardware configuration was ready for solving problems as soon as power was applied.
The EDSAC system, the second stored-program computer to be built, used stepping switches to transfer a fixed program into memory when its start button was pressed. The program stored on this device, which David Wheeler completed in late 1948, loaded further instructions from punched tape and then executed them.
First commercial computers.
The first programmable computers for commercial sale, such as the UNIVAC I and the IBM 701 included features to make their operation simpler. They typically included instructions that performed a complete input or output operation. The same hardware logic could be used to load the contents of a punch card (the most typical ones) or other input media, such as a magnetic drum or magnetic tape, that contained a bootstrap program by pressing a single button. This booting concept was called a variety of names for IBM computers of the 1950s and early 1960s, but IBM used the term "Initial Program Load" with the IBM 7030 Stretch and later used it for their mainframe lines, starting with the System/360 in 1964.
The IBM 701 computer (1952–1956) had a "Load" button that initiated reading of the first 36-bit word into main memory from a punched card in a card reader, a magnetic tape in a tape drive, or a magnetic drum unit, depending on the position of the Load Selector switch. The left 18-bit half-word was then executed as an instruction, which usually read additional words into memory. The loaded boot program was then executed, which, in turn, loaded a larger program from that medium into memory without further help from the human operator. The term "boot" has been used in this sense since at least 1958.
Other IBM computers of that era had similar features. For example, the IBM 1401 system (c. 1958) used a card reader to load a program from a punched card. The 80 characters stored in the punched card were read into memory locations 001 to 080, then the computer would branch to memory location 001 to read its first stored instruction. This instruction was always the same: move the information in these first 80 memory locations to an assembly area where the information in punched cards 2, 3, 4, and so on, could be combined to form the stored program. Once this information was moved to the assembly area, the machine would branch to an instruction in location 080 (read a card) and the next card would be read and its information processed.
Another example was the IBM 650 (1953), a decimal machine, which had a group of ten 10-position switches on its operator panel which were addressable as a memory word (address 8000) and could be executed as an instruction. Thus setting the switches to 7004000400 and pressing the appropriate button would read the first card in the card reader into memory (op code 70), starting at address 400 and then jump to 400 to begin executing the program on that card.
IBM's competitors also offered single button program load.
A noteworthy variation of this is found on the Burroughs B1700 where there is neither a bootstrap ROM nor a hardwired IPL operation. Instead, after the system is reset it reads and executes opcodes sequentially from a tape drive mounted on the front panel; this sets up a boot loader in RAM which is then executed. However, since this makes few assumptions about the system it can equally well be used to load diagnostic (Maintenance Test Routine) tapes which display an intelligible code on the front panel even in cases of gross CPU failure.
IBM System/360 and successors.
In the IBM System/360 and its successors, including the current z/Architecture machines, the boot process is known as "Initial Program Load" (IPL).
IBM coined this term for the 7030 (Stretch), revived it for the design of the System/360, and continues to use it in those environments today. In the System/360 processors, an IPL is initiated by the computer operator by selecting the three hexadecimal digit device address (CUU; C=I/O Channel address, UU=Control unit and Device address) followed by pressing the "LOAD" button. On the high end System/360 models, most System/370 and some later systems, the functions of the switches and the LOAD button are simulated using selectable areas on the screen of a graphics console, often an IBM 2250-like device or an IBM 3270-like device. For example, on the System/370 Model 158, the keyboard sequence 0-7-X (zero, seven and X, in that order) results in an IPL from the device address which was keyed into the input area. The Amdahl 470V/6 and related CPUs supported four hexadecimal digits on those CPUs which had the optional second channel unit installed, for a total of 32 channels. Later, IBM would also support more than 16 channels.
The IPL function in the System/360 and its successors, and its compatibles such as Amdahl's, reads 24 bytes from an operator-specified device into main storage starting at real address zero. The second and third groups of eight bytes are treated as Channel Command Words (CCWs) to continue loading the startup program (the first CCW is always simulated by the CPU and consists of a Read IPL command, , with command chaining and suppress incorrect length indication being enforced). When the I/O channel commands are complete, the first group of eight bytes is then loaded into the processor's Program Status Word (PSW) and the startup program begins execution at the location designated by that PSW. The IPL device is usually a disk drive, hence the special significance of the read-type command, but exactly the same procedure is also used to IPL from other input-type devices, such as tape drives, or even card readers, in a device-independent manner, allowing, for example, the installation of an operating system on a brand-new computer from an OS initial distribution magnetic tape. For disk controllers, the command also causes the selected device to seek to cylinder , head , simulating a Seek cylinder and head command, , and to search for record , simulating a Search ID Equal command, ; seeks and searches are not simulated by tape and card controllers, as for these device classes an command is simply a sequential read command, not a Read IPL command.
The disk, tape or card deck must contain a special program to load the actual operating system or standalone utility into main storage, and for this specific purpose "IPL Text" is placed on the disk by the stand-alone DASDI (Direct Access Storage Device Initialization) program or an equivalent program running under an operating system, e.g., ICKDSF, but IPL-able tapes and card decks are usually distributed with this "IPL Text" already present.
Minicomputers.
Minicomputers, starting with the Digital Equipment Corporation (DEC) PDP-5 and PDP-8 (1965) simplified design by using the CPU to assist input and output operations. This saved cost but made booting more complicated than pressing a single button. Minicomputers typically had some way to "toggle in" short programs by manipulating an array of switches on the front panel. Since the early minicomputers used magnetic core memory, which did not lose its information when power was off, these bootstrap loaders would remain in place unless they were erased. Erasure sometimes happened accidentally when a program bug caused a loop that overwrote all of memory.
Other minicomputers with such simple form of booting include Hewlett-Packard's HP 2100 series (mid-1960s), the original Data General Nova (1969), and DEC's PDP-11 (1970).
DEC later added an optional diode matrix read-only memory for the PDP-11 that stored a bootstrap program of up to 32 words (64 bytes). It consisted of a printed circuit card, the M792, that plugged into the Unibus and held a 32 by 16 array of semiconductor diodes. With all 512 diodes in place, the memory contained all "one" bits; the card was programmed by cutting off each diode whose bit was to be "zero". DEC also sold versions of the card, the BM792-Yx series, pre-programmed for many standard input devices by simply omitting the unneeded diodes.
Following the older approach, the earlier PDP-1 has a hardware loader, such that an operator need only push the "load" switch to instruct the paper tape reader to load a program directly into core memory. The Data General Supernova used front panel switches to cause the computer to automatically load instructions into memory from a device specified by the front panel's data switches, and then jump to loaded code; the Nova 800 and 1200 had a switch that loaded a program into main memory from a special read-only memory and jumped to it.
Early minicomputer boot loader examples.
In a minicomputer with a paper tape reader, the first program to run in the boot process, the boot loader, would read into core memory either the second-stage boot loader (often called a "Binary Loader") that could read paper tape with checksum or the operating system from an outside storage medium. Pseudocode for the boot loader might be as simple as the following eight instructions:
A related example is based on a loader for a Nicolet Instrument Corporation minicomputer of the 1970s, using the paper tape reader-punch unit on a Teletype Model 33 ASR teleprinter. The bytes of its second-stage loader are read from paper tape in reverse order.
The length of the second stage loader is such that the final byte overwrites location 7. After the instruction in location 6 executes, location 7 starts the second stage loader executing. The second stage loader then waits for the much longer tape containing the operating system to be placed in the tape reader. The difference between the boot loader and second stage loader is the addition of checking code to trap paper tape read errors, a frequent occurrence with relatively low-cost, "part-time-duty" hardware, such as the Teletype Model 33 ASR. (Friden Flexowriters were far more reliable, but also comparatively costly.)
Booting the first microcomputers.
The earliest microcomputers, such as the Altair 8800 (released first in 1975) and an even earlier, similar machine (based on the Intel 8008 CPU) had no bootstrapping hardware as such. When started, the CPU would see memory that would contain executable code containing only binary zeros—memory was cleared by resetting when powering up. The front panels of these machines carried toggle switches for entering addresses and data, one switch per bit of the computer memory word and address bus. Simple additions to the hardware permitted one memory location at a time to be loaded from those switches to store bootstrap code. Meanwhile, the CPU was kept from attempting to execute memory content. Once correctly loaded, the CPU was enabled to execute the bootstrapping code. This process was tedious and had to be error-free.
Integrated circuit read-only memory era.
The boot process for minicomputers and microcomputers was revolutionized by the introduction of integrated circuit read-only memory (ROM), with its many variants, including mask-programmed ROMs, programmable ROMs (PROM), erasable programmable ROMs (EPROM), and flash memory. These allowed firmware boot programs to be included as part of the computer. The introduction of an (external) ROM was in an Italian telephone switching elaborator, called "Gruppi Speciali", patented in 1975 by Alberto Ciaramella, a researcher at CSELT. Gruppi Speciali was, starting from 1975, a fully single-button machine booting into the operating system from a ROM memory composed from semiconductors, not from ferrite cores. Although the ROM device was not natively embedded in the computer of Gruppi Speciali, due to the design of the machine, it also allowed the single-button ROM booting in machines not designed for that (therefore, this "bootstrap device" was architecture-independent), e.g. the PDP-11. Storing the state of the machine after the switch-off was also in place, which was another critical feature in the telephone switching contest.
Typically, every microprocessor will, after a reset or power-on condition, perform a start-up process that usually takes the form of "begin execution of the code that is found starting at a specific address" or "look for a multibyte code at a specific address and jump to the indicated location to begin execution". A system built using that microprocessor will have the permanent ROM occupying these special locations so that the system always begins operating without operator assistance. For example, Intel x86 processors always start by running the instructions beginning at F000:FFF0, while for the MOS 6502 processor, initialization begins by reading a two-byte vector address at $FFFD (MS byte) and $FFFC (LS byte) and jumping to that location to run the bootstrap code.
Apple Inc.'s first computer, the Apple 1 introduced in 1976, featured PROM chips that eliminated the need for a front panel for the boot process (as was the case with the Altair 8800) in a commercial computer. According to Apple's ad announcing it "No More Switches, No More Lights ... the firmware in PROMS enables you to enter, display and debug programs (all in hex) from the keyboard."
Due to the expense of read-only memory at the time, the Apple II series booted its disk operating systems using a series of very small incremental steps, each passing control onward to the next phase of the gradually more complex boot process. (See Apple DOS: Boot loader). Because so little of the disk operating system relied on ROM, the hardware was also extremely flexible and supported a wide range of customized disk copy protection mechanisms. (See Software Cracking: History.)
Some operating systems, most notably pre-1995 Macintosh systems from Apple, are so closely interwoven with their hardware that it is impossible to natively boot an operating system other than the standard one. This is the opposite extreme of the scenario using switches mentioned above; it is highly inflexible but relatively error-proof and foolproof as long as all hardware is working normally. A common solution in such situations is to design a boot loader that works as a program belonging to the standard OS that hijacks the system and loads the alternative OS. This technique was used by Apple for its A/UX Unix implementation and copied by various freeware operating systems and BeOS Personal Edition 5.
Some machines, like the Atari ST microcomputer, were "instant-on", with the operating system executing from a ROM. Retrieval of the OS from secondary or tertiary store was thus eliminated as one of the characteristic operations for bootstrapping. To allow system customizations, accessories, and other support software to be loaded automatically, the Atari's floppy drive was read for additional components during the boot process. There was a timeout delay that provided time to manually insert a floppy as the system searched for the extra components. This could be avoided by inserting a blank disk. The Atari ST hardware was also designed so the cartridge slot could provide native program execution for gaming purposes as a holdover from Atari's legacy making electronic games; by inserting the Spectre GCR cartridge with the Macintosh system ROM in the game slot and turning the Atari on, it could "natively boot" the Macintosh operating system rather than Atari's own TOS.
The IBM Personal Computer included ROM-based firmware called the BIOS; one of the functions of that firmware was to perform a power-on self test when the machine was powered up, and then to read software from a boot device and execute it. Firmware compatible with the BIOS on the IBM Personal Computer is used in IBM PC compatible computers. The Extensible Firmware Interface was developed by Intel, originally for Itanium-based machines, and later also used as an alternative to the BIOS in x86-based machines, including Apple Macs using Intel processors.
Unix workstations originally had vendor-specific ROM-based firmware. Sun Microsystems later developed OpenBoot, later known as Open Firmware, which incorporated a Forth interpreter, with much of the firmware being written in Forth. It was standardized by the IEEE as IEEE standard 1275-1994; firmware that implements that standard was used in PowerPC-based Macs and some other PowerPC-based machines, as well as Sun's own SPARC-based computers. The Advanced RISC Computing specification defined another firmware standard, which was implemented on some MIPS-based and Alpha-based machines and the SGI Visual Workstation x86-based workstations.
Modern boot loaders.
When a computer is turned off, its softwareincluding operating systems, application code, and dataremains stored on non-volatile memory. When the computer is powered on, it typically does not have an operating system or its loader in random-access memory (RAM). The computer first executes a relatively small program stored in read-only memory (ROM) along with a small amount of needed data, to access the nonvolatile device or devices from which the operating system programs and data can be loaded into RAM.
The small program that starts this sequence is known as a "bootstrap loader", "bootstrap" or "boot loader". This small program's only job is to load other data and programs which are then executed from RAM. Often, multiple-stage boot loaders are used, during which several programs of increasing complexity load one after the other in a process of chain loading.
Some computer systems, upon receiving a boot signal from a human operator or a peripheral device, may load a very small number of fixed instructions into memory at a specific location, initialize at least one CPU, and then point the CPU to the instructions and start their execution. These instructions typically start an input operation from some peripheral device (which may be switch-selectable by the operator). Other systems may send hardware commands directly to peripheral devices or I/O controllers that cause an extremely simple input operation (such as "read sector zero of the system device into memory starting at location 1000") to be carried out, effectively loading a small number of boot loader instructions into memory; a completion signal from the I/O device may then be used to start execution of the instructions by the CPU.
Smaller computers often use less flexible but more automatic boot loader mechanisms to ensure that the computer starts quickly and with a predetermined software configuration. In many desktop computers, for example, the bootstrapping process begins with the CPU executing software contained in ROM (for example, the BIOS of an IBM PC) at a predefined address (some CPUs, including the Intel x86 series are designed to execute this software after reset without outside help). This software contains rudimentary functionality to search for devices eligible to participate in booting, and load a small program from a special section (most commonly the boot sector) of the most promising device, typically starting at a fixed entry point such as the start of the sector.
Boot loaders may face peculiar constraints, especially in size; for instance, on the IBM PC and compatibles, the boot code must fit in the Master Boot Record (MBR) and the Partition Boot Record (PBR), which in turn are limited to a single sector; on the IBM System/360, the size is limited by the IPL medium, e.g., card size, track size.
On systems with those constraints, the first program loaded into RAM may not be sufficiently large to load the operating system and, instead, must load another, larger program. The first program loaded into RAM is called a first-stage boot loader, and the program it loads is called a second-stage boot loader.
First-stage boot loader.
Examples of first-stage bootloaders include BIOS, coreboot, Libreboot and Das U-Boot. On the IBM PC, the boot loader in the Master Boot Record (MBR) and the Partition Boot Record (PBR) was coded to require at least 32 KB (later tightened to 64 KB) of system memory and only use instructions supported by the original 8088/8086 processors.
Second-stage boot loader.
Second-stage boot loaders, such as GNU GRUB, rEFInd, BOOTMGR, Syslinux, NTLDR or BootX, are not themselves operating systems, but are able to load an operating system properly and transfer execution to it; the operating system subsequently initializes itself and may load extra device drivers. The second-stage boot loader does not need drivers for its own operation, but may instead use generic storage access methods provided by system firmware such as the BIOS or Open Firmware, though typically with restricted hardware functionality and lower performance.
Many boot loaders (like GNU GRUB, rEFInd, Windows's BOOTMGR, Syslinux, and Windows NT/2000/XP's NTLDR) can be configured to give the user multiple booting choices. These choices can include different operating systems (for dual or multi-booting from different partitions or drives), different versions of the same operating system (in case a new version has unexpected problems), different operating system loading options (e.g., booting into a rescue or safe mode), and some standalone programs that can function without an operating system, such as memory testers (e.g., memtest86+), a basic shell (as in GNU GRUB), or even games (see List of PC Booter games). Some boot loaders can also load other boot loaders; for example, GRUB loads BOOTMGR instead of loading Windows directly. Usually a default choice is preselected with a time delay during which a user can press a key to change the choice; after this delay, the default choice is automatically run so normal booting can occur without interaction.
The boot process can be considered complete when the computer is ready to interact with the user, or the operating system is capable of running system programs or application programs.
Many embedded systems must boot immediately. For example, waiting a minute for a digital television or a GPS navigation device to start is generally unacceptable. Therefore, such devices have software systems in ROM or flash memory so the device can begin functioning immediately; little or no loading is necessary, because the loading can be precomputed and stored on the ROM when the device is made.
Large and complex systems may have boot procedures that proceed in multiple phases until finally the operating system and other programs are loaded and ready to execute. Because operating systems are designed as if they never start or stop, a boot loader might load the operating system, configure itself as a mere process within that system, and then irrevocably transfer control to the operating system. The boot loader then terminates normally as any other process would.
Network booting.
Most computers are also capable of booting over a computer network. In this scenario, the operating system is stored on the disk of a server, and certain parts of it are transferred to the client using a simple protocol such as the Trivial File Transfer Protocol (TFTP). After these parts have been transferred, the operating system takes over the control of the booting process.
As with the second-stage boot loader, network booting begins by using generic network access methods provided by the network interface's boot ROM, which typically contains a Preboot Execution Environment (PXE) image. No drivers are required, but the system functionality is limited until the operating system kernel and drivers are transferred and started. As a result, once the ROM-based booting has completed it is entirely possible to network boot into an operating system that itself does not have the ability to use the network interface.
Personal computers (PC).
Boot devices.
The boot device is the device from which the operating system is loaded. A modern PC's UEFI or BIOS firmware supports booting from various devices, typically a local solid state drive or hard disk drive via the GPT or Master Boot Record (MBR) on such a drive or disk, an optical disc drive (using El Torito), a USB mass storage device (FTL-based flash drive, SD card or multi-media card slot, USB hard disk drive, USB optical disc drive, etc.), or a network interface card (using PXE). Older, less common BIOS-bootable devices include floppy disk drives, Zip drives, and LS-120 drives.
Typically, the firmware (UEFI or BIOS) will allow the user to configure a "boot order". If the boot order is set to "first, the DVD drive; second, the hard disk drive", then the firmware will try to boot from the DVD drive, and if this fails (e.g. because there is no DVD in the drive), it will try to boot from the local hard disk drive.
For example, on a PC with Windows installed on the hard drive, the user could set the boot order to the one given above, and then insert a Linux Live CD in order to try out Linux without having to install an operating system onto the hard drive. This is an example of dual booting, in which the user chooses which operating system to start after the computer has performed its Power-on self-test (POST). In this example of dual booting, the user chooses by inserting or removing the DVD from the computer, but it is more common to choose which operating system to boot by selecting from a boot manager menu on the selected device, by using the computer keyboard to select from a BIOS or UEFI Boot Menu, or both; the Boot Menu is typically entered by pressing or keys during the POST; the BIOS Setup is typically entered by pressing or keys during the POST.
Several devices are available that enable the user to "quick-boot" into what is usually a variant of Linux for various simple tasks such as Internet access; examples are Splashtop and Latitude ON.
Boot sequence.
Upon starting, an IBM-compatible personal computer's x86 CPU, executes in real mode, the instruction located at reset vector (the physical memory address on 16-bit x86 processors and on 32-bit and 64-bit x86 processors), usually pointing to the firmware (UEFI or BIOS) entry point inside the ROM. This memory location typically contains a jump instruction that transfers execution to the location of the firmware (UEFI or BIOS) start-up program. This program runs a power-on self-test (POST) to check and initialize required devices such as main memory (DRAM), the PCI bus and the PCI devices (including running embedded Option ROMs). One of the most involved steps is setting up DRAM over SPD, further complicated by the fact that at this point memory is very limited.
After initializing required hardware, the firmware (UEFI or BIOS) goes through a pre-configured list of non-volatile storage devices ("boot device sequence") until it finds one that is bootable. A bootable MBR device is defined as one that can be read from, and where the last two bytes of the first sector contain the little-endian word , found as byte sequence , on disk (also known as the MBR boot signature), or where it is otherwise established that the code inside the sector is executable on x86 PCs.
Once the BIOS has found a bootable device it loads the boot sector to linear address (usually segment:offset :, but some BIOSes erroneously use :) and transfers execution to the boot code. In the case of a hard disk, this is referred to as the Master Boot Record (MBR). The conventional MBR code checks the MBR's partition table for a partition set as "bootable" (the one with "active" flag set). If an active partition is found, the MBR code loads the boot sector code from that partition, known as Volume Boot Record (VBR), and executes it. The MBR boot code is often operating-system specific.
The boot sector code is the first-stage boot loader. It is located on fixed disks and removable drives, and must fit into the first 446 bytes of the Master Boot Record in order to leave room for the default 64-byte partition table with four partition entries and the two-byte boot signature, which the BIOS requires for a proper boot loader — or even less, when additional features like more than four partition entries (up to 16 with 16 bytes each), a disk signature (6 bytes), a disk timestamp (6 bytes), an Advanced Active Partition (18 bytes) or special multi-boot loaders have to be supported as well in some environments. In floppy and superfloppy Volume Boot Records, up to 59 bytes are occupied for the Extended BIOS Parameter Block on FAT12 and FAT16 volumes since DOS 4.0, whereas the FAT32 EBPB introduced with DOS 7.1 requires even 87 bytes, leaving only 423 bytes for the boot loader when assuming a sector size of 512 bytes. Microsoft boot sectors therefore traditionally imposed certain restrictions on the boot process, for example, the boot file had to be located at a fixed position in the root directory of the file system and stored as consecutive sectors, conditions taken care of by the codice_1 command and slightly relaxed in later versions of DOS. The boot loader was then able to load the first three sectors of the file into memory, which happened to contain another embedded boot loader able to load the remainder of the file into memory. When Microsoft added LBA and FAT32 support, they even switched to a boot loader reaching over "two" physical sectors and using 386 instructions for size reasons. At the same time other vendors managed to squeeze much more functionality into a single boot sector without relaxing the original constraints on only minimal available memory (32 KB) and processor support (8088/8086). For example, DR-DOS boot sectors are able to locate the boot file in the FAT12, FAT16 and FAT32 file system, and load it into memory as a whole via CHS or LBA, even if the file is not stored in a fixed location and in consecutive sectors.
The VBR is often OS-specific; however, its main function is to load and execute the operating system boot loader file (such as codice_2 or codice_3), which is the second-stage boot loader, from an active partition. Then the boot loader loads the OS kernel from the storage device.
If there is no active partition, or the active partition's boot sector is invalid, the MBR may load a secondary boot loader which will select a partition (often via user input) and load its boot sector, which usually loads the corresponding operating system kernel. In some cases, the MBR may also attempt to load secondary boot loaders before trying to boot the active partition. If all else fails, it should issue an INT 18h BIOS interrupt call (followed by an INT 19h just in case INT 18h would return) in order to give back control to the BIOS, which would then attempt to boot off other devices, attempt a remote boot via network.
Most modern systems (newer Apple Macs and newer PCs) use UEFI.
Unlike BIOS, UEFI (not Legacy boot via CSM) does not rely on boot sectors, UEFI system loads the boot loader (EFI application file in USB disk or in the EFI System Partition) directly, and the OS kernel is loaded by the boot loader.
Other kinds of boot sequences.
Some modern CPUs and microcontrollers (for example, TI OMAP) or sometimes even DSPs may have boot ROM with boot code integrated directly into their silicon, so such a processor could perform quite a sophisticated boot sequence on its own and load boot programs from various sources like NAND flash, SD or MMC card and so on. It is difficult to hardwire all the required logic for handling such devices, so an integrated boot ROM is used instead in such scenarios. Boot ROM usage enables more flexible boot sequences than hardwired logic could provide. For example, the boot ROM could try to perform boot from multiple boot sources. Also, a boot ROM is often able to load a boot loader or diagnostic program via serial interfaces like UART, SPI, USB and so on. This feature is often used for system recovery purposes when for some reasons usual boot software in non-volatile memory got erased, and it could also be used for initial non-volatile memory programming when there is clean non-volatile memory installed and hence no software available in the system yet.
Some embedded system designs may also include an intermediary boot sequence step in form of additional code that gets loaded into system RAM by the integrated boot ROM. Additional code loaded that way usually serves as a way for overcoming platform limitations, such as small amounts of RAM, so a dedicated primary boot loader, such as Das U-Boot, can be loaded as the next step in system's boot sequence. The additional code and boot sequence step are usually referred to as "secondary program loader" (SPL).
It is also possible to take control of a system by using a hardware debug interface such as JTAG. Such an interface may be used to write the boot loader program into bootable non-volatile memory (e.g. flash) by instructing the processor core to perform the necessary actions to program non-volatile memory. Alternatively, the debug interface may be used to upload some diagnostic or boot code into RAM, and then to start the processor core and instruct it to execute the uploaded code. This allows, for example, the recovery of embedded systems where no software remains on any supported boot device, and where the processor does not have any integrated boot ROM. JTAG is a standard and popular interface; many CPUs, microcontrollers and other devices are manufactured with JTAG interfaces (as of 2009).
Some microcontrollers provide special hardware interfaces which cannot be used to take arbitrary control of a system or directly run code, but instead they allow the insertion of boot code into bootable non-volatile memory (like flash memory) via simple protocols. Then at the manufacturing phase, such interfaces are used to inject boot code (and possibly other code) into non-volatile memory. After system reset, the microcontroller begins to execute code programmed into its non-volatile memory, just like usual processors are using ROMs for booting. Most notably this technique is used by Atmel AVR microcontrollers, and by others as well. In many cases such interfaces are implemented by hardwired logic. In other cases such interfaces could be created by software running in integrated on-chip boot ROM from GPIO pins.
Most digital signal processors have a serial mode boot, and a parallel mode boot, such as the host port interface (HPI boot)
In case of DSPs there is often a second microprocessor or microcontroller present in the system design, and this is responsible for overall system behavior, interrupt handling, dealing with external events, user interface, etc. while the DSP is dedicated to signal processing tasks only. In such systems the DSP could be booted by another processor which is sometimes referred as the "host processor" (giving name to a Host Port). Such a processor is also sometimes referred as the "master", since it usually boots first from its own memories and then controls overall system behavior, including booting of the DSP, and then further controlling the DSP's behavior. The DSP often lacks its own boot memories and relies on the host processor to supply the required code instead. The most notable systems with such a design are cell phones, modems, audio and video players and so on, where a DSP and a CPU/microcontroller are co-existing.
Many FPGA chips load their configuration from an external serial EEPROM ("configuration ROM") on power-up.


Linux for Tegra

Linux for Tegra (Linux4Tegra, L4T) is a Linux based system software distribution by Nvidia for the Tegra processor series, used in platforms like the Nvidia Jetson board series. It is similar to Nvidia's Vibrante Linux distribution.
This system software comes with JetPack, a Software Development Kit (SDK) from Nvidia. The official Nvidia download page bears an entry for JetPack 3.2 (uploaded there on 2018-03-08) that states:


FCMOV

FCMOV is a floating point conditional move opcode of the Intel x86 architecture, first introduced in Pentium Pro processors. It copies the contents of one of the floating point stack register, depending on the contents of EFLAGS integer flag register, to the ST(0) (top of stack) register. There are 8 variants of the instruction selected by the condition codes that need be set for the instruction to perform the move.
Similar to the CMOV instruction, FCMOV allows some conditional operations to be performed without the usual branching overhead. However, it has a higher latency than conditional branch instructions. Therefore, it is most useful for simple yet unpredictable comparison or conditional operations, where it can provide substantial performance gains.
The instruction is usually used with the FCOMI instruction or the FCOM-FSTSW-SAHF idiom to set the relevant condition codes based on the result of a floating point comparison.
Variants.
This table shows the variants of the FCMOV instructions. The first operand is always the ST(0) register (equivalently, the top of the floating point stack). The Opcode column indicates a two-byte sequence where the second byte is a base value indicating the number of the floating point stack register to use for the second operand. Add the desired number to complete the corresponding opcode value.


Namco System 357

The Namco System 357 is an arcade system board based on the Sony PlayStation 3. It was released in 2007 as the board for "Tekken 6". Unlike its predecessor, it did not see widespread adoption by other manufacturers.
In 2011, Namco released an upgraded version of the arcade board, the System 369, also known as System 359, for use with "Tekken Tag Tournament 2". The System 369's specifications are the same as "Slim" model retail PS3 consoles, and as such feature a smaller chassis with less heat.


Evdev

evdev (short for 'event device') is a generic input event interface in the Linux kernel and FreeBSD. It generalizes raw input events from device drivers and makes them available through character devices in the codice_1 directory.
The user-space library for the kernel component evdev is called libevdev. Libevdev abstracts the evdev ioctls through type-safe interfaces and provides functions to change the appearance of the device. Libevdev shares similarities with the read system call.
It sits below the process that handles input events, in between the kernel and that process.
For Weston/Wayland, the stack would look like this:
Since version 1.16 the xorg-xserver obtained support for libinput:
evdev is primarily used by display servers like X.org (via xf86-input-evdev driver and libevdev) and Weston.


Nhttpd

nhttpd is an open-source web server, also known as the Nostromo web server, designed by Marcus Glocker. It runs as a single process, and handles normal concurrent connections by select calls, but for efficiency during more demanding connections such as directory listings and CGI execution it forks. It supports HTTP/1.1 and CGI/1.1, Basic access authentication, SSL, IPv6, custom responses, aliases and virtual hosts. Security measures include running setuid and chrooting. Public access is controlled using the world readable flags and CGI execution by the world executable flags of the file system permissions.


Clarksfield (microprocessor)

Clarksfield is the code name for an Intel processor, initially sold as mobile Intel Core i7. It is closely related to the desktop Lynnfield processor, both use quad-core dies based on the 45 nm
Nehalem microarchitecture and have integrated PCI Express and DMI links.
The predecessor of Clarksfield, Penryn-QC was a multi-chip module with two dual-core Penryn dies based on Penryn microarchitecture, a shrink of Core microarchitecture. The name of the direct successor of Clarksfield has not been announced. Arrandale is a later mobile processor but opens a new line of mid-range dual-core processors with integrated graphics.
At the time of its release at the Intel Developer Forum on September 23, 2009, Clarksfield processors were significantly faster than any other laptop processor, including the Core 2 Extreme QX9300. The initial laptop manufacturers shipping products based on Clarksfield processors include MSI, Dell/Alienware, Hewlett-Packard, Toshiba and Asustek.
Brand names.
As of September 2009, all Clarksfield processors are marketed as Core i7, in three product lines differing in thermal design power and the amount of third-level cache that is enabled.
See the respective lists for details about each model.


W. Richard Stevens

William Richard (Rich) Stevens (February 5, 1951September 1, 1999) was a Northern Rhodesia-born American author of computer science books, in particular books on UNIX and TCP/IP.
Biography.
Richard Stevens was born in 1951 in Luanshya, Northern Rhodesia (now Zambia), where his father worked for the copper industry. The family later moved to Salt Lake City, Hurley, New Mexico, Washington, D.C. and Phalaborwa, South Africa. Stevens attended Fishburne Military School in Waynesboro, Virginia. He received a bachelor's degree in Aerospace Engineering from the University of Michigan in 1973 and both a master's degree (in 1978) and PhD (in 1982) in Systems Engineering from the University of Arizona. He moved to Tucson in 1975 where he was employed at Kitt Peak National Observatory as a computer programmer until 1982. From 1982 until 1990 he was Vice President of Computing Services at Health Systems International in New Haven, Connecticut. Stevens moved back to Tucson in 1990 where he pursued his career as an author and consultant. He was also an avid pilot and a part-time flight instructor during the 1970s.
Stevens died in 1999, at the age of 48. In 2000, he was posthumously awarded the Usenix Lifetime Achievement Award.
RFCs.
Stevens also co-authored several internet Request for Comments (RFC) documents for the Internet Engineering Task Force, the process by which the internet's "technical and organizational notes" are disseminated. Stevens' RFCs covered updates to the Berkeley sockets API for IPv6, as well as a standard method of congestion control for TCP sessions.


Apple A9

The Apple A9 is a 64-bit ARM-based system-on-chip (SoC), designed by Apple Inc. Manufactured for Apple by both TSMC and Samsung, it first appeared in the iPhone 6S and 6S Plus which were introduced on September 9, 2015. Apple states that it has 70% more CPU performance and 90% more graphics performance compared to its predecessor, the Apple A8.
Design.
The A9 features an Apple-designed 64-bit 1.85 GHz ARMv8-A dual-core CPU called Twister. The A9 in the iPhone 6S has 2 GB of LPDDR4 RAM included in the package. The A9 has a per-core L1 cache of 64 KB for data and 64 KB for instructions, an L2 cache of 3 MB shared by both CPU cores, and a 4 MB L3 cache that services the entire SoC and acts as a victim cache. The A9 also features a custom PowerVR Series7XT @ 650 MHz GPU, featuring 6x custom shader cores and compiler from Apple.
The A9 includes a new image processor, a feature originally introduced in the A5 and last updated in the A7, with better temporal and spatial noise reduction as well as improved local tone mapping. The A9 directly integrates an embedded M9 motion coprocessor, a feature originally introduced with the A7 as a separate chip. In addition to servicing the accelerometer, gyroscope, compass, and barometer, the M9 coprocessor can recognize Siri voice commands. The A9 adds hardware decoding for HEIF and 8-bit and 10-bit HEVC.
The A9 features a custom storage solution, which uses an Apple-designed NVMe-based controller that communicates over a PCIe connection. The iPhone 6s' NAND design is more akin to a PC-class SSD than embedded flash memory common on mobile devices. This gives the phone a significant storage performance advantage over competitors which often use eMMC or UFS to connect to their flash memory.
Microarchitecture.
The A9's microarchitecture is similar to the second generation Cyclone (used in A8 chip) microarchitecture. Some of the microarchitectural features are as follows:
About half of the performance boost over A8 comes from the 1.85 GHz frequency. About a quarter comes from the better memory subsystem (3× bigger caches). The remaining quarter comes from the microarchitectural tuning and smaller technology node.
Encryption.
According to Apple, "Every iOS device has a dedicated AES-256 crypto engine built into the DMA path between the flash storage and main system memory, making file encryption highly efficient. On A9 or later A-series processors, the flash storage subsystem is on an isolated bus that is only granted access to memory containing user data via the DMA crypto engine."
Dual sourcing.
Apple A9 chips are fabricated by two companies: Samsung and TSMC. The Samsung version is called APL0898, which is manufactured on a 14 nm FinFET process and is 96 mm2 large, while the TSMC version is called APL1022, which is manufactured on a 16 nm FinFET process and is 104.5 mm2 large.
There was intended to be no significant difference in performance between the parts, but in October 2015, it was alleged that iPhone 6S models with Samsung-fabricated A9 chips consistently measured shorter battery life than those with TSMC-fabricated versions in CPU heavy usage; web browsing and graphics were not very different. Apple responded that "tests which run the processors with a continuous heavy workload until the battery depletes are not representative of real-world usage", and said that internal testing combined with customer data demonstrated a variance of only 2–3%.
Naming.
While the Twister CPU core implements the ARMv8-A instruction set architecture licensed from ARM Holdings, it is an independent CPU design and is unrelated to the much older but similarly named Cortex-A9 and ARM9 CPU that are designed by ARM themselves and implement the 32-bit ARMv7-A and ARMv5E versions of the architecture.
Gallery.
The processors are nearly identical visually. The packaging have the same dimensions (approx 15.0×14.5 mm) and only superficial differences, like the designation text. Inside the packaging the silicon die differs in size.
ARKit.
The A9 processor is listed as the minimum requirement for ARKit.


POWER5

The POWER5 is a microprocessor developed and fabricated by IBM. It is an improved version of the POWER4. The principal improvements are support for simultaneous multithreading (SMT) and an on-die memory controller. The POWER5 is a dual-core microprocessor, with each core supporting one physical thread and two logical threads, for a total of two physical threads and four logical threads.
History.
Technical details of the microprocessor were first presented at the 2003 Hot Chips conference. A more complete description was given at Microprocessor Forum 2003 on 14 October 2003. The POWER5 was not sold openly and was used exclusively by IBM and their partners. Systems using the microprocessor were introduced in 2004. The POWER5 competed in the high-end enterprise server market, mostly against the Intel Itanium 2 and to a lesser extent, the Sun Microsystems UltraSPARC IV and the Fujitsu SPARC64 V. It was superseded in 2005 by an improved iteration, the POWER5+.
Description.
The POWER5 is a further development of the POWER4. The addition of two-way multithreading required the duplication of the return stack, program counter, instruction buffer, group completion unit and store queue so that each thread may have its own. Most resources, such as the register files and execution units, are shared, although each thread sees its own set of registers. The POWER5 implements simultaneous multithreading (SMT), where two threads are executed simultaneously. The POWER5 can disable SMT to optimize for the current workload.
As many resources such as the register files are shared by two threads, they are increased in capacity in many cases to compensate for the loss of performance. The number of integer and floating-point registers is increased to 120 each, from 80 integer and 72 floating-point registers in the POWER4. The floating-point instruction cache is also increased in capacity to 24 entries from 20. The capacity of the L2 unified cache was increased to 1.875 MB and the set-associativity to 10-way. The unified L3 cache was brought on-package instead of located externally in separate chips. Its capacity was increased to 36 MB. Like the POWER4, the cache is shared by the two cores. The cache is accessed via two unidirectional 128-bit buses operating at half the core frequency.
The on-die memory controller supports up to 64 GB of DDR and DDR2 memory. It uses high-frequency serial buses to communicate with external buffers that interface the dual inline memory modules (DIMMs) to the microprocessor.
The POWER5 contains 276 million transistors and has an area of 389 mm2. It is fabricated by IBM in a 0.13 μm silicon on insulator (SOI) complementary metal–oxide–semiconductor (CMOS) process with eight layers of copper interconnect. The POWER5 die is packaged in either a dual chip module (DCM) or a multi-chip module (MCM). The DCM contains one POWER5 die and its associated L3 cache die. The MCM contains four POWER5 dies and four L3 cache dies, one for each POWER5 die, and measures 95 mm by 95 mm.
Several POWER5 processors in high-end systems can be coupled together to act as a single vector processor by a technology called ViVA (Virtual Vector Architecture).
POWER5+.
The POWER5+ is an improved iteration of the POWER5 introduced on 4 October 2005. Improvements initially were lower power consumption, due to the newer process it was fabricated in. The POWER5+ chip uses a 90 nm fabrication process. This resulted in the die size decrease from 389 mm2 to 243 mm2.
Clock frequency was not increased at launch and remained between at 1.5 to 1.9 GHz. On 14 February 2006, new versions raised the clock frequency to 2.2 GHz and then to 2.3 GHz on 25 July 2006.
The POWER5+ was packaged in the same packages as previous POWER5 microprocessors, but was also available in a quad-chip module (QCM) containing two POWER5+ dies and two L3 cache dies, one for each POWER5+ die. These QCM chips ran at a clock frequency of between 1.5 and 1.8 GHz.
Users.
IBM uses the DCM and MCM POWER5 microprocessors in its System p and System i server families, in its DS8000 storage server, and as embedded microprocessors in its high-end Infoprint printers. DCM POWER5 microprocessors are used by IBM in its high-end IntelliStation POWER 285 workstation. Third-party users of POWER5 microprocessors are Groupe Bull, in its Escala servers, and Hitachi, in its SR11000 computers with up to 128 POWER5+ microprocessors, which have several installations featured in the 2007 TOP500 list of supercomputers. IBM uses the POWER5+ in its System p5 510Q, 520Q, 550Q and 560Q servers.


CDOS.COM


IQue Player

The iQue Player (, stylised as iQue "PLAYER) is a home video game console that was manufactured by iQue, a joint venture between Nintendo and Chinese-American scientist Wei Yen after China had made claims of banning video games. The system's Chinese name was Shén Yóu Ji" (神游机), literally "Divine Gaming Machine". "Shényóu" (神游) serves a double entendre because the term also means "to make a mental journey". Although the console was never released in any English-speaking countries, the name "iQue Player" appears in the console's instruction manual. The console itself takes the form of the controller and plugs directly into the television. A box accessory is available that allows multiplayer gaming. It was only marketed in mainland China, as the console's unusual game distribution method is an attempt to curb game piracy in that region.
Games for the iQue Player are stored on a 64 MB flash card which is contained within a cartridge that plugs directly into the controller/console. Games were purchased at a special "iQue depot", where games could be downloaded onto the cartridge and played later, in a similar manner to the Famicom Disk System, Satellaview, Nintendo 64DD and Nintendo DS Download Play. Games could also be downloaded by connecting the iQue to a PC. Time-limited demos that come with the iQue include "", "Super Mario 64", and "Star Fox 64". Full versions of the three titles are available, as are other first party Nintendo titles such as "Dr. Mario 64", "Mario Kart 64", "Wave Race 64", and "F-Zero X".
Technical details.
The iQue Player is based on the Nintendo 64, but uses system-on-a-chip technology to reduce size. It plays Nintendo 64 games specifically ported to the system.
Main menu.
Once the player has turned on the system, the iQue logo will appear. Then, an image of a character from a game will appear alongside some options, selectable using the stick, such as "游戏" (games), "管理" (management), and in some cases "俱乐部" (club, referencing iQue Club), and it will say to press the A button to continue. Once the player has entered the games menu, the system lists the games and demos that the player owns and some info on each, such as size, name and status.
Once the player has selected a game with the stick, they can press the A button to start it. A warning will appear, the "healthy gaming advice" screen required to be shown by Chinese law, followed by a screen with some more information about the game, such as its ISBN (if it has one). The first time a game is played after having been transferred to the console, a loading bar will also appear as the console 'recrypts' (i.e. applies a second layer of encryption using a randomly-generated key) the game.
If the player instead presses the Z button on the highlighted game, a menu will appear allowing the player to allocate memory pak files for the game, if this feature is required.
The console allows parents to set a limit on the usage of the console, similar to parental controls in modern consoles, in the management menu. The first item in the menu, "设置密码" (set password), can be used to enable a 4-digit code that must be entered correctly to access the menu. The second item, "设置时钟" (set time), is used to set the console's RTC (this option only has an effect if the console's internal battery is not depleted). The third item, "设置游戏时间" (set gaming time), allows a parent to set a limit on the amount of time that can be spent playing games, selectable from values starting at 00:00 and increasing in 30-minute increments until 08:00, with one more option for 24:00 (essentially removing the limit). The final item, "密码过期时间" (password expiration date), allows a date to be set for the password and other settings to expire, allowing the console to be used normally.
On older firmware versions, the player can also start the iQue Club application from the main menu, which allows them to set a username, phone number, date of birth, gender and address.
Online services.
The iQue Player has online services for buying games, cloud storage, game updates, etc. Currently, there is only one online service for the iQue Player, which is broadband based. In the past, some gas stations had a kiosk based service for accessing games.
iQue Depot.
The iQue depot is a network of kiosks that allows users to download games, update games, and more. Each game comes with a game code that can be used so the user can download the game. Players can also store their games on the iQue Depot network for free. Users must be a member of the iQue Club and have a special iQue Ticket to download games.
iQue@Home.
iQue@Home (神游在线, "iQue Online") was an online service that allowed users to get free access to trial software, update their system, purchase games and more, at home. To connect to the iQue@Home service, players connected the iQue Player to their computer via USB. Games were downloaded onto the computer, in a similar manner to an MP3 player. The user needed an "iQue Ticket", which was similar to a gift card and was used to purchase games. iQue@Home was only compatible with iQue Players that had been upgraded to one of the two most recent firmware versions. The drivers for the iQue Player only support 32-bit versions of Windows, and cannot run on 64-bit or non-Windows operating systems.
Accessories.
iQue Card.
The iQue Card (神游卡) is bundled with the system. It is required to start the system and to load the games. The games, the console's operating system and the game saves, as well as various other system files, are stored on the iQue Card.
Multiplayer Box.
The iQue Player Multiplayer Box (共游盒) is a multitap, and is required to play local multiplayer. The Multiplayer Box has four ports; one for the main iQue Player system, and three for Multiplayer Controllers. Due to this design, only one iQue Player system can be used, and the other players must use Multiplayer Controllers. When using the Multiplayer Box, the iQue Player system is Player 1.
Multiplayer Controller.
The Multiplayer Controller (共游机) is used for local multiplayer. The Multiplayer Controller connects to the Multiplayer Box, and can't load games alone. Games have to be loaded on the iQue Player system.
History.
Development.
China has a large black market for video games and usually only a few games officially make it to the Chinese market. Many Chinese gamers tend to purchase pirated cartridge or disc copies or download ROMs and ISOs to play via emulator. Nintendo wanted to curb the software piracy in China, and bypass the ban that the Chinese government has implemented on home game consoles since 2000. Nintendo partnered with Wei Yen, who helped Nintendo in other projects, and together they created a game system to get around China's black market, as well as loophole through the government's ban. Originally, the system would support games released on Nintendo consoles prior to the GameCube, which include the NES, Super NES and Nintendo 64, but later in the system's development, it was decided only to include Nintendo 64 games. Additionally, "" was going to be included in the software library but it was later cancelled; however, the game's promotional picture is still on the back of the box.
Release.
The iQue Player was released on November 17, 2003 with a few launch titles. Nintendo's strategy to market games in China was to show how video games can help improve children's mental and social development. However, the launch was not successful. The total estimated sales was between 8,000 and 12,000 units. At first, the only way to get games was to buy them via the iQue Depot, but in 2009, Nintendo released iQue@Home to download games at home. The last game for the console, Animal Crossing (动物森林, "Animal Forest") was released in 2006.
Discontinuation.
On October 31, 2016, iQue reported that iQue@Home service would be discontinued by the end of December 2016. The service was gradually phased out until the content distribution servers went offline in 2018.
Games.
The iQue Player's library has 14 games. All these games were released for the Nintendo 64 in Europe, North America and Japan prior to the iQue Player. One game - ' - was cancelled and another - a Traditional Chinese version of ' - was completed but never announced.
Differences.
iQue Player games differ slightly from their Nintendo 64 counterparts, with the text and voices having been translated to Chinese. The only exceptions are the "Mario" games and the previously Japan-only title "Sin and Punishment", where the text has been translated while the voices remain in English. Additionally, many glitches and errors from the original games have been fixed. Some features were removed due to the system's lack of support for Nintendo 64 controller accessories like the Rumble Pak. Due to this, many games that originally supported the rumble feature no longer support it. Some features were added. Many games that allow the player to enter their name now have the option to use their iQue Player's username, which can be set at the iQue Player's main menu. Speedruns of several games, such as "" and "Star Fox 64", are sometimes carried out on the iQue Player due to quicker loading times and faster scrolling text than the Nintendo 64 versions.
Nintendo had plans to support network multiplayer in games that originally only supported local multiplayer, which would work in a similar manner to that of an emulator.


CHDIR


Scalable Link Interface

Scalable Link Interface (SLI) is a brand name for a multi-GPU technology developed by Nvidia for linking two or more video cards together to produce a single output. SLI is a parallel processing algorithm for computer graphics, meant to increase the available processing power.
The initialism SLI was first used by 3dfx for Scan-Line Interleave, which was introduced to the consumer market in 1998 and used in the Voodoo2 line of video cards. After buying out 3dfx, Nvidia acquired the technology but did not use it. Nvidia later reintroduced the SLI name in 2004 and intended for it to be used in modern computer systems based on the PCI Express (PCIe) bus; however, the technology behind the name SLI has changed dramatically.
Implementation.
SLI allows two, three, or four graphics processing units (GPUs) to share the workload when rendering real-time 3D computer graphics. Ideally, identical GPUs are installed on the motherboard that contains enough PCI Express slots, set up in a master–slave configuration. All graphics cards are given an equal workload to render, but the final output of each card is sent to the master card via a connector called the SLI Bridge. For example, in a two graphics card setup, the master works on the top half of the scene, the slave the bottom half. Once the slave is done, it sends its render to the master to combine into one image before sending it to the monitor.
The SLI bridge is used to reduce bandwidth constraints and send data between both graphics cards directly. It is possible to run SLI without using the bridge connector on a pair of "low-end to mid-range" graphics cards (e.g. 7100GS or 6600GT) with Nvidia's Forceware drivers 80.XX or later. Since these graphics cards do not use as much bandwidth, data can be relayed through just the chipsets on the motherboard. However, if there are two "high-end" graphics cards installed and the SLI bridge is omitted, the performance will suffer severely, as the chipset does not have enough bandwidth.
Configurations currently include:
Nvidia has created a set of custom video game profiles in cooperation with video game publishers that will automatically enable SLI in the mode that gives the largest performance boost.
Nvidia has 3 types of SLI bridges:
The Standard Bridge is traditionally included with motherboards that support SLI and is recommended for monitors up to 1920×1080 and 2560×1440@60 Hz. The LED Bridge is sold by Nvidia, EVGA, and others and is recommended for monitors up to 2560×1440@120 Hz+ and 4K. The LED Bridges can only function at the increased Pixel Clock if the GPU supports that clock. The High-Bandwidth Bridge is only sold by Nvidia and is recommended for monitors up to 5K and Surround.
The following table provides an overview on the maximum theoretical bandwidth for data transfers depending on bridge type specifications as found on the open market:
SLI Modes.
Split Frame Rendering (SFR).
This analyzes the rendered image in order to split the workload equally between the two GPUs. To do this, the frame is split horizontally in varying ratios depending on geometry. For example, in a scene where the top half of the frame is mostly empty sky, the dividing line will lower, balancing geometry workload between the two GPUs.
Alternate Frame Rendering (AFR).
Each GPU renders entire frames in sequence. For example, in a Two-Way setup, one GPU renders the odd frames, the other the even frames, one after the other. Finished outputs are sent to the master for display. Ideally, this would result in the rendering time being cut by the number of GPUs available. In their advertising, Nvidia claims up to 1.9x the performance of one card with the Two-Way setup. While AFR may produce higher overall framerates than SFR, it also exhibits the temporal artifact known as Micro stuttering, which may affect frame rate perception. It is noteworthy that while the frequency at which frames arrive may be doubled, the time to produce the frame is not reduced - which means that AFR is not a viable method of reducing input lag.
SLI Antialiasing.
This is a standalone rendering mode that offers up to double the antialiasing performance by splitting the antialiasing workload between the two graphics cards, offering superior image quality. One GPU performs an antialiasing pattern which is slightly offset to the usual pattern (for example, slightly up and to the right), and the second GPU uses a pattern offset by an equal amount in the opposite direction (down and to the left). Compositing both the results gives higher image quality than is normally possible. This mode is not intended for higher frame rates, and can actually lower performance, but is instead intended for games which are not GPU-bound, offering a clearer image in place of better performance. When enabled, SLI Antialiasing offers advanced antialiasing options: SLI 8X, SLI 16X, and SLI 32x (for Quad SLI systems only).
Hybrid SLI.
Hybrid SLI is the generic name for two technologies, GeForce Boost and HybridPower.
GeForce Boost allowed the rendering power of an IGP and a discrete GPU to be combined in order to increase performance.
HybridPower, on the other hand, is another mode that is not for performance enhancement. The setup consists of an IGP as well as a GPU on MXM module. The IGP would assist the GPU to boost performance when the laptop is plugged to a power socket while the MXM module would be shut down when the laptop was unplugged from power socket to lower overall graphics power consumption. Hybrid SLI is also available on desktop Motherboards and PCs with PCI-E discrete video cards. NVIDIA claims that twice the performance can be achieved with a Hybrid SLI capable IGP motherboard and a GeForce 8400 GS video card.
HybridPower was later renamed as Nvidia Optimus.
SLI HB.
In May 2016 Nvidia announced that the GeForce 10 series would feature a new SLI HB (High Bandwidth) bridge; this bridge uses 2 SLI fingers on the PCB of each card and essentially doubles the available bandwidth between them. Currently, only GeForce 10 series cards support SLI HB and only 2-way SLI is supported over this bridge for single-GPU cards. SLI HB interface runs at 650 MHz, while legacy SLI interface runs at slower 400 MHz.
Electrically there is little difference between the regular SLI bridge and the SLI HB bridge. It is similar to two regular bridges combined in one PCB. The signal quality of the bridge improved, however, as the SLI HB bridge has an adjusted trace-length to make sure all traces on the bridge have exactly the same length.
A PC gaming magazine has done research with x-rays for comparing SLI bridges with their SLI HB successors and found adjusted signal lengths by planned Meandering of certain wires so that clock rates can go up from 400 MHz to 650 MHz and thus the data rates along with that. With the increased bus width a noticeable bandwidth increase should be expected. Tests with a GTX 1080 GPU-board model showed that the improvements in gaming performance is quite marginal. Other than that it was discovered or determined, that LED illuminated bridges (often back-side-illuminating some logo) will mainly result in a noticeable increased market price at a comparable base functionality.


3DNow!

3DNow! is an extension to the x86 instruction set developed by Advanced Micro Devices (AMD). It adds single instruction multiple data (SIMD) instructions to the base x86 instruction set, enabling it to perform vector processing, which improves the performance of many graphic-intensive applications. The first microprocessor to implement 3DNow was the AMD K6-2, which was introduced in 1998. When the application was appropriate, this raised the speed by about 2–4 times.
However, the instruction set never gained much popularity, and AMD announced on August 2010 that support for 3DNow would be dropped in future AMD processors, except for two instructions (the codice_1 and codice_2 instructions). The two instructions are also available in Bay-Trail Intel processors.
History.
3DNow was developed at a time when 3D graphics were becoming mainstream in PC multimedia and games. Realtime display of 3D graphics depended heavily on the host CPU's floating-point unit (FPU) to perform floating-point calculations, a task in which AMD's K6 processor was easily outperformed by its competitor, the Intel Pentium II.
As an enhancement to the MMX instruction set, the 3DNow instruction-set augmented the MMX SIMD registers to support common arithmetic operations (add/subtract/multiply) on single-precision (32-bit) floating-point data. Software written to use AMD's 3DNow instead of the slower x87 FPU could execute up to 4x faster, depending on the instruction-mix.
Versions.
3DNow.
The first implementation of 3DNow technology contains 21 new instructions that support SIMD floating-point operations. The 3DNow data format is packed, single-precision, floating-point. The 3DNow instruction set also includes operations for SIMD integer operations, data prefetch, and faster MMX-to-floating-point switching. Later, Intel would add similar (but incompatible) instructions to the Pentium III, known as SSE (Streaming SIMD Extensions).
3DNow floating-point instructions are the following:
3DNow integer instructions are the following:
3DNow performance-enhancement instructions are the following:
3DNow extensions.
There is little or no evidence that the second version of 3DNow was ever officially given its own trade name. This has led to some confusion in documentation that refers to this new instruction set. The most common terms are "Extended 3DNow", "Enhanced 3DNow" and "3DNow+". The phrase "Enhanced 3DNow" can be found in a few locations on the AMD website but the capitalization of "Enhanced" appears to be either purely grammatical or used for emphasis on processors that may or may not have these extensions (the most notable of which references a benchmark page for the K6-III-P that does not have these extensions).
This extension to the 3DNow instruction set was introduced with the first-generation Athlon processors. The Athlon added 5 new 3DNow instructions and 19 new MMX instructions. Later, the K6-2+ and K6-III+ (both targeted at the mobile market) included the 5 new 3DNow instructions, leaving out the 19 new MMX instructions. The new 3DNow instructions were added to boost DSP. The new MMX instructions were added to boost streaming media.
The 19 new MMX instructions are a subset of Intel's SSE1 instruction set. In AMD technical manuals, AMD segregates these instructions apart from the 3DNow extensions. In AMD customer product literature, however, this segregation is less clear where the benefits of all 24 new instructions are credited to enhanced 3DNow technology. This has led programmers to come up with their own name for the 19 new MMX instructions. The most common appears to be "Integer SSE" ("ISSE"). "SSEMMX" and "MMX2" are also found in video filter documentation from the public domain sector. ISSE could also refer to Internet SSE, an early name for SSE.
3DNow extension DSP instructions are the following:
MMX extension instructions (Integer SSE) are the following:
3DNow Professional.
"3DNow Professional" is a trade name used to indicate processors that combine 3DNow technology with a complete SSE instructions set (such as SSE1, SSE2 or SSE3). The Athlon XP was the first processor to carry the 3DNow Professional trade name, and was the first product in the Athlon family to support the complete SSE1 instruction set (for the total of: 21 original 3DNow instructions; five 3DNow extension DSP instructions; 19 MMX extension instructions; and 52 additional SSE instructions for complete SSE1 compatibility).
3DNow and the Geode GX/LX.
The Geode GX and Geode LX added two new 3DNow instructions which are currently absent in all the other processors.
3DNow "professional" instructions unique to the Geode GX/LX are the following:
Advantages and disadvantages.
One advantage of 3DNow is that it is possible to add or multiply the two numbers that are stored in the same register. With SSE, each number can only be combined with a number in the same position in another register. This capability, known as "horizontal" in Intel terminology, was the major addition to the SSE3 instruction set.
A disadvantage with 3DNow is that 3DNow instructions and MMX instructions share the same register-file, whereas SSE adds 8 new independent registers (codice_50–codice_51).
Because MMX/3DNow registers are shared by the standard x87 FPU, 3DNow instructions and x87 instructions cannot be executed simultaneously. However, because it is aliased to the x87 FPU, the 3DNow and MMX register states can be saved and restored by the traditional x87 codice_52 and codice_53 instructions. This arrangement allowed operating systems to support 3DNow with no explicit modifications, whereas SSE registers required explicit operating system support to properly save and restore the new XMM registers (via the added codice_54 and codice_55 instructions.)
The FX* instructions are an upgrade to the older x87 save and restore instructions because these could save not only SSE register states but also those x87 register states (hence which meant that it could save MMX and 3DNow registers too).
On AMD Athlon XP and K8-based cores (i.e. Athlon 64), assembly programmers have noted that it is possible to combine 3DNow and SSE instructions to reduce register pressure, but in practice it is difficult to improve performance due to the instructions executing on shared functional units.


Macpup

Macpup is an operating system based on Puppy Linux, which has Puppy's normal JWM window manager available, but also includes the Enlightenment WM; users can quickly switch window managers without rebooting. The Macpup Enlightenment interface as installed features a Mac OS X-like dockbar, but many Enlightenment themes are available. Macpup comes with the Firefox web browser, and like its parent, Macpup can be run from RAM. The live .iso only uses 184MB of RAM.


WinBuilder

WinBuilder is a free application designed to build and customize boot disks (Live CDs) based on Microsoft Windows (WinPE).
Scripts.
Scripts are the building blocks of Live CD compiled with Winbuilder, and are used to build the core components of the Live CD for adding applications, and for configuration of a specific project.
Scripts consist of a human-readable text file with the .script extension, and can contain Winbuilder scripting commands, the scripts graphical user interface, and sometimes encoded applications to be extracted when needed.
Projects.
A Project is a collection of Winbuilder scripts maintained for building a complete Live CD. Each project contains multiple scripts, each responsible for adding features or applications to the build.
Users may build their own projects from scratch or use one of many projects actively developed by the boot-land community. Projects can be downloaded directly using Winbuilder's built-in download manager and used as-is or further customized to meet the individual's needs.
Inactive Projects.
All of these projects are developed and distributed freely and aim to provide an alternative to other popular Live CD distributions based on Linux such as Knoppix, Slax, Damn Small Linux, which are known for their use in rescue or administrative actions on PCs.
Use and reception.
Use of the software to build various customized boot disks has been covered in articles from PC Quest, (the German edition of PC World, which also offers some customized scripts for building disk images including additional utilities, branded as pcwVistaPE and pcwWin7PE), the Russian edition of CHIP, and by TeraByte Unlimited.
CNET editor's review found that "WinBuilder is one of the most easy-to-use boot disk creation tools in the genre," and praised it for its "novice-friendly interface", but at the same time warned that the "program expects experienced users. For the most part, boot disk applications are for experts only." The built-in Download Center was remarked because it "simplifies procuring the boot disk applications." Other features praised were "its small size, fair memory overhead, simple instructions, and robust application installation wizards."


NETWARS.EXE


PIP.COM


DRBDOS.SYS


Animaniacs (video game)

 are a series of platform video games developed by Konami, based on the hit animated series of the same name. Two games were developed featuring significantly different gameplay and storylines; one for Super Nintendo Entertainment System, and one for the Sega Mega Drive/Genesis and Game Boy. The SNES and Genesis versions were released in 1994, and the Game Boy version in 1995.
The Game Boy version features a unique soundtrack if played on the Super Game Boy accessory, and is one of the few games to take full advantage of the accessory.
Plot.
In the Genesis version, the Warner Siblings, Yakko, Wakko, and Dot, decide to open up a hip pop culture shop in order to become closer to their favorite movie stars. To this end, they travel across various movie sets in the Warner Bros. studio lot in order to retrieve movie memorabilia to sell. However, once they collect all the memorabilia, Pinky and the Brain attempt to steal them in order to further their world domination plans.
In the SNES version, the Brain once again has another plan to conquer the world by deciding to steal the script of the new Warner Bros. film while it was under development. The CEO of Warner Bros. studio reluctantly asks the Warner Siblings for their assistance to retrieve all 24 pages of the script and foil the Brain's plan, which is the primary objective of the game. The ending of the game depends on how many script pages are collected, with the best ending leading to Warner Bros. being able to complete the film, pleasing the CEO, only to find out that the film was about the Warner Siblings, which pleases them.
Gameplay.
Genesis/Game Boy version.
The game features four main levels, which can be entered in any order. The player must reach the end of each level and beat the boss to obtain a piece of movie memorabilia. A fifth level will then open to obtain a final piece of movie memorabilia. After clearing all five levels, players travel to the final level where they must fight Pinky and the Brain. Players control Yakko, Wakko, and Dot, switching control between them to use their respective powers accordingly. Yakko uses a paddleball to stun enemies, and is also able to push and pull objects such as crates. Wakko uses a mallet which can be used to hit switches, break certain objects and light fuses. Dot is able to blow kisses which, when used on certain characters, triggers certain actions needed to progress.
The Warner Brothers and Sister have health indicators and a number of lives. The lives can be increased by obtaining either 100 stars, or obtaining a small golden form of their faces. Their health is indicated by their faces on the top left of the screen. When they smile, they are healthy, but when they are looking either tired, unhappy, or weak, then they should find health soon (which is found in the forms of several forms of ice cream or sweets or other kinds of food). The levels are timed.
This version was ported to the Game Boy by Factor 5, but due to space constraints, only three levels are present in this version and certain parts of the three levels are absent. Both the "Science Fiction/Space Opera – Space Wars (Space Trucking)" and nearly all of the final "Action Movie – Once There Was A Man Named Oscar" levels are absent from this version. On easy mode, the Game Boy version ends early, on the first three levels. On normal and hard modes, the Game Boy version continues after the player completes the first three levels, goes to "Once There Was A Man Named Oscar", and battles Pinky and the Brain.
SNES version.
Players navigate the three characters through a linear, three-dimensional playing field. The primary objective of the game is to collect 24 pages of a script, with multiple pages being scattered around different areas of the studio, though the game can be completed without obtaining all of them. Scripts are hidden in stages, with them being placed in hard-to-reach areas, and several hidden ones which are revealed by performing certain actions such as moving objects or interacting with characters. The ending of the game, with three endings in total, alternates depending on how many scripts are collected. The game focuses more on parodies of films at the different stages, that are once more based on different genres of movies. Several stages feature boss sections, which must be defeated by harming them with certain objects. The final stage, the Editing Room, is unlocked after completing all the other stages, in which the player must defeat all the bosses previously fought in the form of a boss rush, following with a final battle with Pinky and the Brain.
The characters have no health bar, lives (the game ends when all the characters are defeated/captured, one by one) or special abilities. Characters can be swapped freely in almost all places. Characters are defeated from touching harmful enemies or objects, or being captured by the security guard, Ralph. Defeated/captured characters can be recovered by completing a "Rescue" stage that appears when one or two characters are defeated or captured. Characters can pick up and throw things as well as execute a dash move. If all three are together, they can also stack themselves up to reach higher platforms. The stack move can be performed with two characters, however the power of the stack is weakened. A slot machine at the bottom of the screen is activated after obtaining a certain number of coins and can be used for a range of power ups, such as temporary invincibility, bringing back characters who were defeated or captured earlier, and giving or taking away extra coins.
Throughout the game, there are small robots with white block heads, red bodies and yellow appendages who work for Pinky and the Brain.
Reception.
Reviewing the Genesis version, "GamePro" assessed that the game successfully appeals to the TV show's preadolescent target audience. They criticized the limited music and absence of voices, but praised the cartoony and detailed graphics and the way the level design requires the player to make regular use of all three characters. They gave the Super NES version a negative review, citing overly simplistic and frustrating gameplay, though they did praise the graphics for their large and colorful sprites and background references to the TV show. Reviewing the Game Boy version, they criticized the slow-moving characters and trial-and-error gameplay, but approved of the graphics and audio and concluded, "The humor and spirit of the Animaniacs lives on in this handheld game."
"Super Play" was more negative on the SNES version, giving it only 28%
"Digital Press" gave the Genesis version 8 out of 10.
"Next Generation" reviewed the Genesis version of the game, rating it three stars out of five, and stated that "Cutting edge innovation isn't here, but what is here is plenty of fun."


Restricted shell

The restricted shell is a Unix shell that restricts some of the capabilities available to an interactive user session, or to a shell script, running within it. It is intended to provide an additional layer of security, but is insufficient to allow execution of entirely untrusted software. A restricted mode operation is found in the original Bourne shell and its later counterpart , and in the KornShell. In some cases a restricted shell is used in conjunction with a chroot jail, in a further attempt to limit access to the system as a whole.
Invocation.
The restricted mode of the Bourne shell , and its POSIX workalikes, is used when the interpreter is invoked in one of the following ways:
The restricted mode of Bash is used when Bash is invoked in one of the following ways:
Similarly KornShell's restricted mode is produced by invoking it thus:
Setting Up rbash.
For some systems (e.g., CentOS), the invocation through is not enabled by default, and the user obtains a error if invoked directly, or a login failure if the /etc/passwd file indicates as the user's shell.
It suffices to create a link named pointing directly to . Though this invokes Bash directly, without the or options, Bash does recognize that it was invoked through and it does come up as a restricted shell.
This can be accomplished with the following simple commands (executed as root, either logged in as user root, or using sudo):
root@host:~# cd /bin
root@host:/bin# ln bash rbash
Limited operations.
The following operations are not permitted in a restricted shell:
Bash adds further restrictions, including:
Restrictions in the restricted KornShell are much the same as those in the restricted Bourne shell.
Weaknesses of a restricted shell.
The restricted shell is not secure. A user can break out of the restricted environment by running a program that features a shell function. The following is an example of the shell function in vi being used to escape from the restricted shell:
user@host:~$ vi
Or by simply starting a new unrestricted shell, if it is in the , as demonstrated here:
user@host:~$ rbash
user@host:~$ cd /
rbash: cd: restricted
user@host:~$ bash
user@host:~$ cd /
user@host:/$
List of programs.
Beyond the restricted modes of usual shells, specialized restricted shell programs include:


Inotify

"Inotify" (inode notify) is a Linux kernel subsystem which monitors changes to the filesystem, and reports those changes to applications. It can be used to automatically update directory views, reload configuration files, log changes, backup, synchronize, and upload. Inotifywait and inotifywatch commands allows use inotify subsystem from command line. One major use is in desktop search utilities like Beagle, where its functionality permits reindexing of changed files without scanning the filesystem for changes every few minutes, which would be very inefficient.
inotify replaced an earlier facility, dnotify, which had similar goals. It was merged into the Linux kernel mainline in kernel version 2.6.13, released on August 29, 2005; later kernel versions included further improvements. The required library interfaces were added into the GNU C Library (glibc) in its version 2.4, released in March 2006, while the support for inotify was completed in glibc version 2.5, released in September 2006.
Limitations.
Limitations imposed by inotify include the following:
Advantages over dnotify.
There are a number of advantages when using inotify when compared to the older dnotify API that it replaced. With dnotify, a program had to use one file descriptor for each directory that it was monitoring. This can become a bottleneck since the limit of file descriptors per process could be reached. Later, fanotify was created to overcome this issue. The use of file descriptors along with dnotify also proved to be a problem when using removable media. Devices could not be unmounted since file descriptors kept the resource busy.
Another drawback of dnotify is the level of granularity, since programmers can only monitor changes at the directory level. To access detailed information about the environmental changes that occur when a notification message is sent, a stat structure must be used; this is considered a necessary evil in that a cache of stat structures has to be maintained, for every new stat structure generated a comparison is run against the cached one.
The inotify API uses fewer file descriptors, allowing programmers to use the established select and poll interface, rather than the signal notification system used by dnotify. This also makes integration with existing select- or poll-based libraries (like GLib) easier.


Link register

A link register is a special-purpose register which holds the address to return to when a function call completes. This is more efficient than the more traditional scheme of storing return addresses on a call stack, sometimes called a machine stack. The link register does not require the writes and reads of the memory containing the stack which can save a considerable percentage of execution time with repeated calls of small subroutines.
A link register is used in many instruction set architectures, such as PowerPC, ARM, and PA-RISC. Other architectures (such as SPARC) have a register with the same purpose but another name (in this case, "output register 7" or "o7").
The usage of a link register (or a general-purpose register, as is done in some other instruction set architectures) allows for faster calls to leaf subroutines. When the subroutine is non-leaf, passing the return address in a register can still result in generation of more efficient code for thunks, e.g. for a function whose sole purpose is to call another function with arguments rearranged in some way. Other subroutines can benefit from the use of link register because it can be saved in a batch with other callee-used registers—e.g. an ARM subroutine pushes registers 4-7 along with the link register, LR, by the single instruction
codice_1 pipelining all memory writes required.


Cyrix Cx486SLC

The Cyrix Cx486SLC was Cyrix's first CPU offering, released after years of selling coprocessors that competed with Intel's units and offered better performance at a comparable or lower price.
The 486SLC is based on the i386SX bus, and was intended as an entry-level chip to compete with the Intel 386SX and 486SX. Texas Instruments manufactured the 486SLC for Cyrix, and also sold it under its own name as TX486SLC. Later, they also released their own version of the chip, the TI486SXLC which featured 8kB internal cache vs 1kB in the original Cyrix design. The similarly named IBM 486SLC, 486SLC2, 486SLC3 (16-bit external bus version of IBM 486DLC aka Blue Lightning) and IBM 386SLC are often confused with the Cyrix chips, but are not related and instead based on an Intel CPU core.
Introduced in May 1992, like the later and more famous Cyrix Cx5x86 it was a hybrid CPU, incorporating features of a new CPU (in this case the Intel 80486) while having a pin out similar to the existing 386SX, enabling existing board designs to be easily modified for the new chip. It ran at speeds of 20, 25, 33, and 40 MHz, although it had difficulty running reliably at 40 MHz using some operating systems. In December 1992 Cyrix also released the Cyrix Cx486SLC/e (25, 33 MHz) which offered power management, and a low voltage laptop version, the 3.3v Cyrix Cx486SLC/e-V (20, 25 MHz). In December 1993 Cyrix released a clock doubled version (25/50 MHz) cx486SLC2, as well as a clip-on upgrade for 386SX systems, the cx486SRx2 (16/33, 20/40 & 25/50 MHz).
The 486SLC can be described as a 386SX with the 486 instruction set and 1K of onboard L1 cache added. Unfortunately it inherited the 386SX's 24-bit address bus (16mb max. DRAM), and 16-bit datapath which limited its memory bandwidth. Like the 386 and 486SX, it had no on-board math coprocessor, but unlike the 486SX, it could make use of an Intel 287, 387SX or compatible coprocessor. Due to the limitations of the 386SX's bus and its smaller L1 cache, its performance could not compete with the 486SX when the latter was running on a full 32-bit bus.
The 486SLC was primarily used in very inexpensive low-end motherboards and PC clones. Because of its low power consumption, it also saw use in laptops. The 486SLC was also available as a 32-bit version based on the i386DX bus, see 486DLC.


MOVHPD

In the x86 assembly programming language, MOVHPD is the name for a specific action performable by modern x86 processors with 2nd-generation Streaming SIMD Extensions (SSE2). This action involves either copying a number from memory to temporary space or copying a number from temporary space to memory.
Specifically, MOVHPD causes the value at an 8-byte memory region to be either copied to or assigned from the upper half of an XMM register.
Usage.
The source operand can be either an XMM register ("codice_1") or a memory address ("codice_2"). When the source operand is an XMM register, the destination operand must be a memory address. When the source operand is a memory address, the destination operand must be an XMM register.
Note that the lower half of the XMM register is unaffected by this operation.
See also.
x86 instruction listings


UltraSPARC IIIi


SPARC64 GP


Nokia N77

The Nokia N77 is a 3G smartphone from Nokia, introduced on 12 February 2007 and released in June 2007. It runs on Symbian 9.1 (S60 3rd Edition). The N77's specs were somewhat basic compared with most Nseries devices at the time, but it included a DVB-H television tuner. As stated in Nokia's press release, the N77 was designed as a low-cost mobile TV to accelerate DVB-H adoption. Sporting a candybar design similar to the N73, it was the company's second DVB-H device after the N92, though it did have a smaller screen. The N77 was thus only available in limited DVB-H markets and are now hard to come by.


List of x86 manufacturers

Manufacturers.
x86-compatible processors have been designed, manufactured and sold by a number of companies, including:
x86-processors for regular PCs.
In the past:
x86-processors for embedded designs only.
In the past:
Manufacturing-only of x86-processors designed by others.
In the past:
Manufactured and sold under its own name of x86-processors designed by others.
In the past: