Advanced Vector Extensions

Advanced Vector Extensions (AVX, also known as Sandy Bridge New Extensions) are extensions to the x86 instruction set architecture for microprocessors from Intel and AMD proposed by Intel in March 2008 and first supported by Intel with the Sandy Bridge processor shipping in Q1 2011 and later on by AMD with the Bulldozer processor shipping in Q3 2011. AVX provides new features, new instructions and a new coding scheme.
AVX2 (also known as Haswell New Instructions) expands most integer commands to 256 bits and introduces fused multiply-accumulate (FMA) operations. They were first supported by Intel with the Haswell processor, which shipped in 2013.
AVX-512 expands AVX to 512-bit support using a new EVEX prefix encoding proposed by Intel in July 2013 and first supported by Intel with the Knights Landing processor, which shipped in 2016.
Advanced Vector Extensions.
AVX uses sixteen YMM registers to perform a Single Instruction on Multiple pieces of Data (see SIMD). Each YMM register can hold and do simultaneous operations (math) on:
The width of the SIMD registers is increased from 128 bits to 256 bits, and renamed from XMM0–XMM7 to YMM0–YMM7 (in x86-64 mode, from XMM0–XMM15 to YMM0–YMM15). The legacy SSE instructions can be still utilized via the VEX prefix to operate on the lower 128 bits of the YMM registers.
AVX introduces a three-operand SIMD instruction format called VEX coding scheme, where the destination register is distinct from the two source operands. For example, an SSE instruction using the conventional two-operand form "a = a + b" can now use a non-destructive three-operand form "c = a + b", preserving both source operands. Originally, AVX's three-operand format was limited to the instructions with SIMD operands (YMM), and did not include instructions with general purpose registers (e.g. EAX). It was later used for coding new instructions on general purpose registers in later extensions, such as BMI. VEX coding is also used for instructions operating on the k0-k7 mask registers that were introduced with AVX-512.
The alignment requirement of SIMD memory operands is relaxed. Unlike their non-VEX coded counterparts, most VEX coded vector instructions no longer require their memory operands to be aligned to the vector size. Notably, the codice_1 instruction still requires its memory operand to be aligned.
The new VEX coding scheme introduces a new set of code prefixes that extends the opcode space, allows instructions to have more than two operands, and allows SIMD vector registers to be longer than 128 bits. The VEX prefix can also be used on the legacy SSE instructions giving them a three-operand form, and making them interact more efficiently with AVX instructions without the need for codice_2 and codice_3.
The AVX instructions support both 128-bit and 256-bit SIMD. The 128-bit versions can be useful to improve old code without needing to widen the vectorization, and avoid the penalty of going from SSE to AVX, they are also faster on some early AMD implementations of AVX. This mode is sometimes known as AVX-128.
New instructions.
These AVX instructions are in addition to the ones that are 256-bit extensions of the legacy 128-bit SSE instructions; most are usable on both 128-bit and 256-bit operands.
CPUs with AVX.
Not all CPUs from the listed families support AVX. Generally, CPUs with the commercial denomination "Core i3/i5/i7/i9" support them, whereas "Pentium" and "Celeron" CPUs don't.
Issues regarding compatibility between future Intel and AMD processors are discussed under XOP instruction set.
Operating system support.
AVX adds new register-state through the 256-bit wide YMM register file, so explicit operating system support is required to properly save and restore AVX's expanded registers between context switches. The following operating system versions support AVX:
Advanced Vector Extensions 2.
Advanced Vector Extensions 2 (AVX2), also known as Haswell New Instructions, is an expansion of the AVX instruction set introduced in Intel's Haswell microarchitecture. AVX2 makes the following additions:
Sometimes another extension using a different cpuid flag is considered part of AVX2; those instructions are listed on their own page and not below:
AVX-512.
"AVX-512" are 512-bit extensions to the 256-bit Advanced Vector Extensions SIMD instructions for x86 instruction set architecture proposed by Intel in July 2013, and are supported with Intel's Knights Landing processor.
AVX-512 instruction are encoded with the new EVEX prefix. It allows 4 operands, 8 new 64-bit opmask registers, scalar memory mode with automatic broadcast, explicit rounding control, and compressed displacement memory addressing mode. The width of the register file is increased to 512 bits and total register count increased to 32 (registers ZMM0-ZMM31) in x86-64 mode.
AVX-512 consists of multiple extensions not all meant to be supported by all processors implementing them. The instruction set consists of the following:
Only the core extension AVX-512F (AVX-512 Foundation) is required by all implementations, though all current processors also support CD (conflict detection); computing coprocessors will additionally support ER, PF, 4VNNIW, 4FMAPS, and VPOPCNTDQ, while desktop processors will support VL, DQ, BW, IFMA, VBMI, VPOPCNTDQ, VPCLMULQDQ etc.
The updated SSE/AVX instructions in AVX-512F use the same mnemonics as AVX versions; they can operate on 512-bit ZMM registers, and will also support 128/256 bit XMM/YMM registers (with AVX-512VL) and byte, word, doubleword and quadword integer operands (with AVX-512BW/DQ and VBMI).
Downclocking.
Since AVX instructions are wider and generate more heat, some Intel processors have provisions to reduce the Turbo Boost frequency limit when such instructions are being executed. On Skylake and its derivatives, the throttling is divided into three levels:
The frequency transition can be soft or hard. Hard transition means the frequency is reduced as soon as such an instruction is spotted; soft transition means that the frequency is reduced only after reaching a threshold number of matching instructions. The limit is per-thread.
In Ice Lake, only two levels persist:
Rocket Lake processors do not trigger frequency reduction upon executing any kind of vector instructions regardless of the vector size. However, downclocking can still happen due to other reasons, such as reaching thermal and power limits.
Downclocking means that using AVX in a mixed workload with an Intel processor can incur a frequency penalty despite it being faster in a "pure" context. Avoiding the use of wide and heavy instructions help minimize the impact in these cases. AVX-512VL allows for using 256-bit or 128-bit operands in AVX-512, making it a sensible default for mixed loads.


Fujitsu A64FX

The A64FX is a 64-bit ARM architecture microprocessor designed by Fujitsu. The processor is replacing the SPARC64 V as Fujitsu's processor for supercomputer applications. It powers the Fugaku supercomputer, the fastest supercomputer in the world by TOP500 rankings as of June 2020 as well as November 2020.
Design.
Fujitsu collaborated with ARM to develop the processor; it is the first processor to use the ARMv8.2-A Scalable Vector Extension SIMD instruction set with 512-bit vector implementation. A prototype computer using the processors was ranked as the 159th fastest computer in the world on the TOP500 list in November 2019.
It has "Four-operand FMA with Prefix Instruction", i.e. MOVPRFX instruction followed by FMA3 (ARM, like RISC in general, is a 3-operand machine, doesn't have space for 4 operands), which get packed into a single operation in the pipeline. For the processor the designer claim ">90% execution efficiency in (D|S|H)GEMM and INT16/8 dot product".
The processor uses 32 gigabytes of HBM2 memory with a bandwidth of 1 TB per second. The processor contains 16 PCI Express generation 3 lanes to connect to accelerators (hypothetical e.g. GPUs and FPGAs). The reported transistor count is about 8.8 billion.
Each A64FX processor has 4 NUMA nodes, with each NUMA node having 12 compute cores, for a total of 48 cores per processor. Each NUMA node also has its own level 2 cache, HBM2 memory, and assistant cores for non-computational purposes.
Fujitsu intends to produce lower specification machines with reduced assistant cores. Reliability, availability and serviceability (RAS) capabilities are claimed, i.e. ~128,400 error checkers in total.
Implementations.
Fujitsu designed the A64FX for the Fugaku. As of June and November 2020, the Fugaku is the fastest supercomputer in the world by TOP500 rankings. Fujitsu intends to sell smaller machines with A64FX processors. Anandtech reported in June 2020 that the cost of a PRIMEHPC FX700 server, with 2 A64FX nodes, was (c. ).
Cray is developing supercomputers using the A64FX. The supercomputer is being built for a consortium in the United Kingdom, led by the University of Bristol and also including the Met Office, using the Fujitsu processors. It is an upgrade to the Isambard supercomputer which was built with the Marvell ThunderX2, another ARM architecture microprocessor.
Ookami is an open testbed system supported by NSF run by Stony Brook University and the University at Buffalo providing researchers access to A64FX processors.


GlobalView

GlobalView was an integrated “desktop environment” including word-processing, desktop-publishing, and simple calculation (spreadsheet) and database functionality. It was developed at Xerox Parc as a way to run the software originally developed for their Xerox Alto, Xerox Star and Xerox Daybreak 6085 specialized workstations on Sun Microsystems workstations and IBM PC-based platforms.
Overview.
Initially GlobalView required an additional processor on a PC expansion card, later it was run using emulation. Though the software it was based on had once been far ahead of its time (in terms of its integration and use of a graphical user interface), the high cost of the processor and later low speed of the emulator doomed it to poor sales (almost exclusively old customers of the Alto and Star, recognized as precursors of the Apple Macintosh but in themselves expensive corporate niche machines). The resulting lack of resources for development left it to fall further and further behind its competitors. It existed from the late 1980s until the early 1990s.
Reception.
Stewart Alsop II in 1988 cited "two significant problems with Viewpoint". He said that the lack of freedom for third-party software "to develop a separate identity" meant that they would be "invisible" like expansion cards. Alsop believed that Viewpoint had changed little from the original Xerox PARC technology created more than ten years earlier, because (unlike Apple and Microsoft's "hundreds of thousands of users") not enough consumers had used it to give Xerox feedback. He advised the company to "be much less defensive and much more open minded; it needs to stop resting on its laurels".


Joshua Bloch

Joshua J. Bloch (born August 28, 1961) is an American software engineer and a technology author, formerly employed at Sun Microsystems and Google. He led the design and implementation of numerous Java platform features, including the Java Collections Framework, the package, and the mechanism. He is the author of the programming guide "Effective Java" (2001), which won the 2001 Jolt Award, and is a co-author of two other Java books, "Java Puzzlers" (2005) and "Java Concurrency In Practice" (2006).
Bloch holds a B.S. in computer science from Columbia University and a Ph.D. in computer science from Carnegie Mellon University. His 1990 thesis was titled "A Practical Approach to Replication of Abstract Data Objects" and was nominated for the ACM Distinguished Doctoral Dissertation Award.
Bloch has worked as a Senior Systems Designer at Transarc, and later as a Distinguished Engineer at Sun Microsystems. In June 2004, he left Sun and became Chief Java Architect at Google. On August 3, 2012, Bloch announced that he would be leaving Google.
In December 2004, "Java Developer's Journal" included Bloch in its list of the "Top 40 Software People in the World".
Bloch has proposed the extension of the Java programming language with two features: Concise Instance Creation Expressions (CICE) (coproposed with Bob Lee and Doug Lea) and Automatic Resource Management (ARM) blocks. The combination of CICE and ARM formed one of the three early proposals for adding support for closures to Java. ARM blocks were added to the language in JDK7.
Bloch is currently an affiliated faculty member of the Institute for Software Research at Carnegie Mellon University, where he holds the title "Adjunct Professor of the Practice".


List of Intel Core i9 processors

The following is a list of Intel Core i9 brand microprocessors. They were introduced in May 2017 for LGA 2066 chips, also known as Intel Core X-series processors. With their high number of cores, high power draw, high thermal output, and high performance, they are intended to be used by enthusiasts. A mobile version based on the standard BGA1440 socket was released in 2018, featuring six hyperthreaded cores and 12 MB of cache. It has been proven to be able to attain 5 GHz under ideal conditions.
The Core i9 brand was expanded to incorporate mainstream processors in October 2018, following the release of the Core i9-9900K processor, which uses Intel's mainstream consumer platform.


Compressed Volume File


NETPLUS.SYS


Vadem VG330


Apocalypse (video game)

Apocalypse is a third-person shooter video game released for the PlayStation, developed by Neversoft and published by Activision. It features actor Bruce Willis, who provides the main character's likeness and voice.
Plot.
A brilliant evil scientist named "The Reverend" has created a powerful theocracy based on the idea of a rapidly approaching apocalypse. He uses his expertise to create four powerful "Horsemen of the Apocalypse", War, Plague, Beast and Death, in order to ensure this comes to pass. His former colleague, Trey Kincaid (voiced by Bruce Willis), is the only man with the know-how to stop the Reverend, but is locked up in jail and must escape in order to save the world.
Gameplay.
"Apocalypse" is a 3D multidirectional shooter. The character is moved using the DualShock controller's left analog stick, and shooting is handled independently by pressing the right stick in a given direction, which automatically fires the current weapon in said direction. Alternately, movement may be controlled through the directional pad and shooting performed by using the four face buttons on a typical PlayStation controller (which lack analog sticks), where the buttons' placement on the controller correspond with the fire direction. Using the shoulder buttons it is also possible to duck or jump, and a selection of different weapons are available.
Development.
The game engine for "Apocalypse" was completed in January 1996. Initially, the player character was a mercenary accompanied by an AI-controlled partner, Trey Kincaid, in an effort to create the video game equivalent of a buddy film. Activision later signed a multi-million-dollar deal for Bruce Willis to provide Trey Kincaid's voice and likeness, using "cyber-scanning" and motion capture. Trey Kincaid's role was eventually changed to that of the main playable character, thus reducing the necessity for him to have as much spoken dialogue as was originally intended as the scope of Bruce Willis' involvement decreased as development went on. In the finished game, Willis' vocal contributions are limited mostly to the occasional one-liner and a few brief lines of dialogue in story sequences. Willis' face was photo-mapped onto Trey Kincaid's character model. His motion capture performance was recorded at House of Moves, a film studio in Venice, CA. The sessions were held in mid-January 1997 and took two days. During voice recording, Willis made a number of suggestions of changes to the dialogue, which the developers agreed to.
Poe was cast as the character Plague using the same combination of cyber-scanning, motion capture, and voice recording as done with Willis. "Apocalypse" features several songs from various artists, including Poe and System of a Down. Technology developed for the game allowed live-action music videos from these artists to be projected on large screens within the game's environments.
A three-level "buddy AI" was developed for Kincaid, enabling Kincaid to take up aggressive or defensive approaches and attempt to get power-ups before the player character.
The game was demonstrated at the June 1997 Electronic Entertainment Expo, with Willis present to help promote it. At this time the AI-controlled partner mechanic was still in place, and the game was set to release in September, but the game had been delayed to a later release date of November 17, 1998.
The "Apocalypse" game engine was reworked for use on Neversoft's next title, the seminal "Tony Hawk's Pro Skater". Already having in mind that they were going to begin work on "Tony Hawk" following completion of "Apocalypse", the team said they had developed rough in-house playable demos of Trey Kincaid skateboarding around "Apocalypse"s game environments in order to experiment with the way they wanted "Tony Hawk" to feel. Even though Neversoft continued to develop and evolve the engine primarily to suit the needs of the "Tony Hawk" series, it was also put to use in another action title by the team, the popular "Spider-Man" game they released in 2000. The aspect of the engine that allowed for the live-action music videos to be displayed within "Apocalypse"s game world was also utilized in "Tony Hawk's Pro Skater" as well as other subsequent Neversoft titles.
Reception.
The game received "average" reviews according to the review aggregation website GameRankings
Jeff Gerstmann of "GameSpot" praised the game's gameplay as a shooter while criticising the voice acting for lacking any feeling and variety. "Next Generation" called it "an action title that is average at best. There really is nothing new or innovative here. And in this fourth generation of PlayStation games, this is simply not acceptable". In Japan, where the game was ported and published by Success on September 22, 1999, "Famitsu" gave it a score of 22 out of 40.


Fixstars Solutions

Fixstars Solutions, Inc. is a software and services company specializing in multi-core processors, particularly in Nvidia's GPU and CUDA environment, IBM Power7, and Cell. They also specialize in solid-state drives and currently manufacture the world's largest SATA drives.
During the early part of 2010, Fixstars developed a strong relationship with Nvidia and focused its linux distribution for GPU computing. Yellow Dog Enterprise Linux for CUDA is the first enterprise Linux OS optimized for GPU computing. It offers end users, developers and integrators a faster, more reliable, and less complex GPU computing experience.
Terra Soft acquisition.
On November 11, 2008, Japanese company Fixstars announced that it had acquired essentially all of Terra Soft's assets. Terra Soft's former founder and CEO Kai Staats was appointed as COO of Fixstars's new American subsidiary, Fixstars Solutions, which is based in Irvine, California. Fixstars Solutions retained Terra Soft's product line, staff and regional offices in Loveland, Colorado.
Terra Soft provided software and services for the PowerPC/Power ISA and Linux OS platform. Former Terra Soft Solutions produced Yellow Dog Linux (YDL) and Yellow Dog Enterprise Linux which included cluster construction tools. Customers included Argonne, Sandia, Lawrence Livermore, and Los Alamos National Labs, several Department of Defense contractors including Boeing, Lockheed Martin, and SAIC; the U.S. Air Force, Navy, Army, and NASA; and many of the top universities around the world including California Institute of Technology, MIT, and Stanford University.
As an Apple value-added reseller and IBM Business Partner, Terra Soft Solutions provided turnkey and build-to-order desktop workstations, servers, and High Performance Computing clusters. Terra Soft made their Yellow Dog Linux distribution solely for PowerPC/Power ISA, optimizing the distributions for AltiVec and the Cell.
Terra Soft was the first to support a variety of Apple computers with Linux pre-installed (under a unique license with Apple). When Apple abandoned PowerPC CPUs in favor of the Intel Core chips, Terra Soft was able to concentrate on high-performance computing and the Cell Broadband Engine, working closely with IBM and Sony for the PlayStation 3 products.
In 2006, Terra Soft was contracted by Sony to provide a Linux operating system for the PlayStation 3, used by several University researchers as an inexpensive, powerful cluster compute node.
Today, Fixstars of Tokyo, Japan carries forward the Yellow Dog Linux and Yellow Dog Enterprise Linux product line with primary focus on heterogeneous, multi-core CPUs such as the Cell Broadband Engine and Nvidia GPU.
Hardware.
YDL PowerStation.
Terra Soft launched the YDL PowerStation also known as the Yellow Dog Linux (YDL) PowerStation on June 10, 2008 with a base price of $1,895.
The YDL PowerStation offers:
Fixstars GigaAccel 180 (IBM PXCAB).
Fixstars GigaAccel 180 (IBM PXCAB) is an accelerator board based on IBM's PowerXCell 8i processor.


Unisys 2200 Series system architecture

The figure shows a high-level architecture of the OS 2200 system identifying major hardware and software components. The majority of the Unisys software is included in the subsystems and applications area of the model. For example, the database managers are subsystems and the compilers are applications.
System Basics.
The details of the system architecture are covered in Unisys publication 3850 7802 Instruction Processor Programming Reference Manual. Also see UNIVAC 1100/2200 series.
The 1100 Series has used a 36-bit word with 6-bit characters since 1962. This word and character size was a Department of Defense (DoD) requirement. Since the military needed to be able to calculate accurate trajectories, design bridges, and perform other engineering and scientific calculations, they needed more than 32 bits of precision. A 32-bit floating point number only provided about 6 digits of accuracy while a 36 bit number provided the 8 digits of accuracy that were accepted as the minimum requirement. Since memory and storage space and costs drove the system, going to 64 bits was simply not acceptable in general. These systems use ones' complement arithmetic, which was not unusual at the time. Almost all computer manufacturers of the time delivered 36-bit systems with 6-bit characters including IBM, DEC, General Electric, and Sylvania.
The 6-bit character set used by the 1100 Series is also a DoD mandated set. It was defined by the Army Signal Corps and called Fieldata (data returned from the field). The 1108 provided a 9-bit character format in order to support ASCII and later the ISO 8-bit sets, but they were not extensively used until the 1980s again because of space constraints.
The 2200 Series architecture provides many registers. Base registers logically contain a virtual address that points to a word in a code or data bank (segment). They may point to the beginning of the bank or to any word within the bank. Index registers are used by instructions to modify the offset of the specified or assumed base register. Simple arithmetic (add, subtract) may be performed on all index registers. In addition, index registers consist of a lower offset portion and an upper increment portion. An instruction may both use the offset value in an index register as part of an address and specify that the increment is to be added to the offset. This allows loops to be accomplished with fewer instructions as incrementing the index by the step size can be accomplished without a separate instruction. Arithmetic registers allow the full set of computational instructions including all floating point operations. Some of those instructions work on adjacent pairs of registers to perform double-precision operations. There are no even-odd constraints. Any two registers may be used as a double-precision value. Four of the arithmetic registers are also index registers (the sets overlap – index register X12 is arithmetic register A0). This allows the full range of calculations to be performed on indexes without having to move the results. The rest of the registers, known as R registers, are used as fast temporary storage and for certain special functions. R1 holds the repeat count for those instructions that may be repeated (block transfer, execute repeated, etc.). R2 holds a bit mask for a few instructions that perform a bitwise logical operation in addition to some other functions (e.g., masked load upper)
There are two full sets of registers (A, X, R, and B). One set, the user registers, is used by all applications and most portions of the operating system. It is saved and restored as part of activity (thread) state. The other set, the Exec registers, is used by interrupt processing routines and some other portions of the operating system that want to avoid having to save and restore user registers. The Exec registers are not writable by user applications although some user code can read them. As a result, the Exec is carefully designed never to leave private, secure, or confidential information in registers. Instruction interpretation chooses the appropriate register set to use based on a bit in the Processor State Register. This bit is always set (changed to privileged) on an interrupt. All registers are also visible in the address space, but the Exec portion is protected and a reference by non-privileged code will result in a fault interrupt.
The 2200 Series uses a 36-bit segmented virtual address space. We’ll look later at the addressing architecture.
The 2200 Series is a CISC architecture system. Not only are there a large number of instructions (current count is about 245) but many of them have addressing variants. Some of the variants are encoded directly in the instruction format (partial word references) and some are dependent on Processor State Register settings. Many instructions also perform very complex functions such as one that implements a large part of the COBOL EDIT verb.
The above figure shows some of the building blocks of the architecture. "Data" and "COMM" are two of the primary examples of software subsystems that live in a protection ring between that of a user application and the Exec. There are many other such subsystems and users write their own.
Memory and Addressing.
Level.
As was mentioned earlier the 2200 Series uses a 36-bit segmented virtual address. The original notion of a segmented space came from the earliest implementation that emphasized code and data separation for performance and the use of shared code banks. Over the years this expanded to provide greater flexibility of levels of sharing and far greater protection for security and reliability. Controlled access to shared data was also introduced.
A virtual address consists of three parts. The high-order 3 bits define the sharing level. This is the heart of the entire addressing and protection scheme. Every thread has eight Bank Descriptor Tables (Segment Descriptor Tables in the industry) based on B16-B23. The tables are indexed by level – level 0 refers to the Bank Descriptor Table (BDT) based on B16, level 2 the BDT based on B18, etc. The level 0 and level 2 BDTs are common to all threads in the system. Every run (process) has its own level 4 BDT, and that BDT is common to all threads in the run. Every user thread has its own unshared level 6 BDT.
Activity.
Each extended-mode activity (thread) always has six banks, segments, which are totally unique to it. One is the Return Control Stack which holds information about the calling structure including any security relevant privilege and state changes. It is not accessible by the thread except through the use of the CALL, RETURN, and similar instructions. This is a major part of the protection and reliability mechanism. Applications cannot cause bad effects by changing the return addresses or overwriting the return control stack.
Another unique bank is the automatic storage bank (Activity Local Store stack). This is used by the compilers to hold local variables created within a block. It is also used to hold all parameter lists passed on a call. One of the checks made by the operating system both on its own behalf and when a call is made to a protected subsystem is to ensure that the operands are on the thread-local stack and that the thread has the right to access the memory region referenced by any parameters. Because the parameters are kept in thread-local space, there is no chance that some other thread may change them during or after validation. It is the responsibility of the called procedure to perform similar checks on any secondary parameters that may exist in shared space (i.e., the primary parameter points to a structure that contains pointers). The procedure is expected to copy any such pointers to its own local space before validating them and then to use only that internally held validated pointer.
Activities may create additional segments up to the limit of the available address space (233 words = 8GW or about 36GB). This is a convenient way for multi-threaded applications to get large amounts of memory space knowing that it is totally thread-safe and that they are not taking any space away from the rest of what is available to the program. Each activity in a program has its own independent space meaning an application with say 100 activities is able to use over 800GW (>3TB) of virtual space.
Basic-mode activities do not start out with any such banks as basic-mode programs are not aware of the virtual address space, but any calls to extended-mode subsystems will cause those banks to be created.
Programs.
OS 2200 does not implement programs in exactly the same way that UNIX, Linux, and Windows implement processes, but that is the closest analogy. The most obvious difference is that OS 2200 only permits a single program per Run (Job, Session) to be executing at a time. A program may have hundreds of threads, but cannot spawn other programs to run concurrently.
There are several banks at the Program level that contain a mixture of Run (job, session) information and program information. These are control structures for the operating system. They have no access or read-only access for the program. Programs may retrieve information from some of these structures for debugging purposes or to retrieve things like the user-id and terminal-id without the overhead of a system call. They cannot be written by the program. They contain things like the thread state save areas, file control blocks, and accounting information.
The rest of the banks are used by the program. When a program object file is executed, the operating system obtains the bank information from the file and creates banks as needed and loads the bank initial state from the file. The simplest program has a single bank containing code and data. This is considered very bad form, but is permitted for compatibility with old applications. You can only create such an application with assembly language. The standard compilers create one or more code banks and one or more data banks. Normally the code banks are marked as read-only as a debugging and reliability aid. There are no security concerns either way. The program can only affect itself.
Each program thus has its own address space distinct from all other programs in the system. Nothing a program can do can change the contents of any other program’s memory. The OS and shared subsystems are protected by other mechanisms which will be discussed later. Even read access is prohibited to OS and subsystem memory in almost all cases from code in a program. It is possible to create a shared subsystem which is generally readable, or even writable, by multiple programs, but it must be explicitly installed that way by a privileged system administrator.
Programs are initially created with just the banks specified in the object file and with a single activity. They may use system calls to create additional banks within their own program level and additional activities.
Subsystems.
The closest analogy to a shared subsystem is a .dll. A subsystem is much like a program in many respects except that it does not have any activities associated with it. Instead it is accessed by other programs and subsystems typically via a CALL instruction. In fact, a program is a subsystem plus one or more activities. Every activity belongs to a "home" subsystem which is the program that created it. This subsystem concept is important as an encapsulation of access rights and privilege. Within their home subsystem, activities typically share common access rights to code and data banks. Code banks in the home subsystem are usually read-only, or even execute-only if they contain no constant data, but all activities will have the right to execute them.
Subsystems are also combinations of banks and may contain data banks as well as code banks. All globally shared subsystems must be installed in the system by someone with appropriate administrator privileges. Subsystems may also open files. The Database manager is a subsystem which opens all the database files for its use typically with exclusive access rights. The operating system will attach its own banks to a subsystem to hold the file control tables.
OS.
The OS level contains the banks of the Exec. These banks are never directly accessible by either programs or global subsystems. Entry points to the OS are all handled in the same way as a protected subsystem. Calls made to the OS are always via "gates," instructions that exist for that purpose (ER = Executive Request), or via interrupts.
The Bank Descriptor Index (BDI).
The next part of the virtual address is the BDI or Bank Descriptor Index. The Level field selected a particular bank descriptor table base register (B16-B23). Base registers B16-B23 are part of the activity state and are maintained by the Exec with no direct access by the activity. The Bank Descriptor tables for the program and activity levels exist within the program-level banks that belong to the operating system.
The BDI is simply an index into a Bank Descriptor Table. Each entry in the table contains information about a bank. Each such entry describes up to 1MB (256KW) of virtual address space. When a larger contiguous space is needed, consecutive entries are logically combined to create a larger bank up to the maximum of 230 words.
The Bank Descriptor Table Entry (Bank Descriptor – BD) gives the size of the bank (small = up to 256KW, large = up to 16MW, very large = up to 1GW). A small bank is always represented by a single BD. Large banks are represented by up to 64 consecutive BDs and a very large bank by up to 4096 BDs. Large and very large banks need not use all 64 or 4096 consecutive BDs. They only use as many as needed to provide the virtual address space required. The entry also contains upper and lower limits of allowable offsets within the bank. Virtual addresses that are outside the limits generate a fault interrupt. This allows small banks, for example containing a message, to have only the virtual space reserved for it that it actually needs and provides a debugging check against bad pointers and indices.
The BD also contains a key value and access control fields. The fields indicate whether read, write, or execute permission is granted to the instruction processor (3 bits). The Special Access Permissions (SAP) applies only to activities executing within the owning subsystem (really only those with a matching key value). The General Access Permissions (GAP) applies to everyone else and is usually zero (no access). The Exec sets a key value in the state of each activity which may be changed by gate and interrupt transitions.
Protection Mechanisms.
The 2200 Series protection architecture uses three pieces of activity state that are reflected in the hardware state. They are Processor Privilege (PP), Ring, and Domain.
Processor Privilege controls the ability to execute privileged instructions and access protected registers and other state. PP=0 is used by the Exec and gives full access to all instructions and privileged state. Exec activities and user activities that have used a gate to access an Exec API run at PP=0.
PP=1 restricts most privileged instructions but does allow reading of the day clocks and reading the contents of some of the privileged registers. None of the privileged registers contain any truly sensitive information, but allowing general read access could easily lead to undetected errors in user programs. Basically at PP=1, instructions that can change the addressing environment, change the clocks, change instrumentation state, or perform I/O are all restricted. PP=1 is rarely used.
PP=2 is the normal user mode and is state in which all other code executes. It is a further restriction of PP=1.
There is also a PP=3 which further restricts the instructions a user program can execute, but it is not currently in use as too many existing programs were using some of those instructions. The intent was to restrict access to instructions that may be system model dependent.
The Domain mechanism is the heart of the protection mechanism. Each BD (bank descriptor) has a lock field consisting of a ring number and domain number. There is also a key field in the state of each activity. If the key matches the lock or the ring in the key is less than the ring in the lock, the activity has Special Access Permission. Otherwise, the activity has General Access Permission.
Ring allows overriding the Domain protection mechanism. User applications run at Ring=3. Protected subsystems run at Ring=2. This gives them access to their own data while still allowing them to access parameters and data in the calling user’s space. Note that it is still not possible for a thread to cause the protected subsystem to access some other user’s space as only this thread’s Bank Descriptor Tables are in use. Ring=0 is used by the OS and allows it to access its own data while still being able to access parameters passed from either user programs or protected subsystems.
Gates are another part of the protection mechanism. A gate is a data structure that controls transitions between domains. A gate lives in a gate bank and the hardware enforces that all references to gates must be to addresses at a proper offset (multiple of a gate size) within a gate bank. A gate contains the target address, new values for PP, Ring, and Domain, and may contain a hidden parameter to be passed to the target. Protected subsystems are not directly accessible to other subsystems. Instead a subsystem must request that a gate be built in its gate bank for access to that subsystem. This permits the operating system to perform any access control checks. The linking system will then find the gate address associated with an entry point. In fact, the whole mechanism is usually transparently handled within the linking system. The hidden parameter permits, for example, a file I/O gate to contain the address or handle of the file control block. Since this is guaranteed to be correct as it was created by the OS when the user opened the file, many error checks can be eliminated from the path length to do I/O.
Instruction Processors.
OS 2200 is designed to handle up to 32 instruction processors (or CPUs). A great deal of design has been done over the years optimize for this environment. For example, OS 2200 makes almost no use of critical sections in its design. There’s too high a probability of multiple processors executing the same code. Instead it uses data locking on the finest granularity data possible. Generally locks deal with a single instance of a data object (e.g., activity control structure or file control block) and are contained within the data structure of the object. This minimizes the likelihood of conflicts. When more global locks have to be set as when updating a list of objects, the lock is set only as long as it takes to update the links in the list. Even dispatching is done with separate locks for different priority levels. A check can be made for an empty priority level without setting a lock. The lock need only be set when adding or removing an item from the queue.
The register set is in the visible address space. Registers appear to exist in the first 128 words (2008) of the current instruction bank (B0) when referenced as a data item. This does impose a restriction on compilers to not place any data constants in the first 128 words of a code bank. The result of this is an expansion of the instruction set without requiring additional operation codes. Register-to-register operations are accomplished with the register-storage operation codes.
Typical instructions contain a function code, the target (or source) register, an index register, a base register and a displacement field. When the function code with its qualifier indicates immediate data, the displacement, base, i, and h fields combine to form a single 18-bit immediate value. This allows loading, adding, multiplying, etc. by small constants to eliminate a memory reference and the associated storage.
Processor state as captured on a stack at an interrupt contains the information needed to both return control to the interrupted activity and to determine the type of the interrupt. Interrupts may occur in the middle of long instructions and the state deals with that possibility.
Basic mode is another whole form of instruction formats and addressing. Basic mode provides compatibility with previous systems back to the 1108. For all practical purposes, the hardware architecture defines the rules by which addresses and instructions are converted to the above forms. The most obvious difference in basic mode is the lack of explicit B registers in instructions. Instead there are four implicitly used B registers (B12-B15). There is a complex algorithm using the limits of the banks represented by those B registers, the operand address and the B register within which the current instruction is found.
The most interesting instructions in the 2200 repertoire are the locking and synchronization instructions. Conditional replace is familiar and quite similar to Compare and Swap in the Intel architecture. These instructions always gain exclusive use of the memory/cache-line holding the referenced word. TS and TSS check a bit in the referenced word. If the bit is clear, they set it and continue (TS) or skip (TSS). If the bit is set, they either interrupt (TS) or fall through to the next instruction(TSS). On a TS interrupt the OS takes one of several actions depending on the instruction sequence and activity priority. Real time and Exec activities simply get control back to allow retry unless there is an even higher-priority activity waiting. The presumption is that the lock is set on another processor and will soon be cleared. If it is a user activity not running at real time priority, it may have its priority temporarily reduced and be placed back in the dispatching queues.
Alternatively, the code sequence may indicate that Test & Set Queuing is being used. In this case, the OS places the activity in a wait state and chains it to the end of the list of activities waiting for that particular lock. Activities clearing such a lock check to see if any are waiting and if so notify the OS to allow one of more to try again. Test & Set Queuing is typically used for synchronization within subsystems such as the database manager where activities from many programs may be executing.
The result of these mechanisms is very efficient, low overhead, synchronization among activities.
The queuing architecture is another interesting special case. It was specifically designed to allow very efficient handling of messaging where the number of messages waiting for processing could be almost unlimited. It is also aimed at reducing one of the primary costs of messaging, namely having to constantly move messages around in memory. Even moving them from the communication manager to the message queue subsystem to the processing program is eliminated. Instead each message is placed in a small bank of its own. Instructions allow placing the bank descriptors of these banks in a queue and removing them from a queue. When a message is placed in a queue, the sending program or subsystem no longer has any access to it. That bank is removed from its address space. When a message is retrieved from a queue, the bank becomes part of the receiver's address space. The queuing instructions also provide activity synchronization functions (e.g., wait for a message).
Only "pointers" are moved and they are moved in a way that ensures security and integrity. Once moved, the data in the message is only visible to the recipient.
I/O Processors.
All I/O on 2200 Series systems is handled by I/O processors. These processors offload large portions of the I/O path length and recovery, and by fully isolating the main system from I/O faults, interrupts, bus errors, etc. greatly improve reliability and availability. The I/O processors come in three different types (Storage, Communications, Clustering) but the only real difference is the firmware load.
All I/O processors are controlled by the operating system. OS 2200 does provide a raw mode for I/O called "arbitrary device I/O," but even there the OS validates that the program is accessing an allowed device and handles all interrupts and faults before passing appropriate status on to the program. Programs must be granted privileges by the security officer to access devices in arbitrary mode and that may be limited by both the security officer and the system operator to specific devices. Arbitrary I/O is not allowed to a device that is also in use by any other program or the system. The device must be exclusively allocated to the program.
The OS takes very general calls from programs and generates command packets with real memory and device addresses which are then passed to the I/O processor. Firmware in the I/O processor actually creates the device specific (e.g., SCSI) packets, sets up the DMA, issues the I/O, and services the interrupts.


JMP (x86 instruction)

In the x86 assembly language, the codice_1 instruction performs an unconditional jump. Such an instruction transfers the flow of execution by changing the instruction pointer register. There are a number of different opcodes that perform a jump; depending on whether the processor is in real mode or protected mode, and an override instruction is used, the instructions may take 16-bit, 32-bit, or segment:offset pointers.
There are many different forms of jumps: relative, conditional, absolute and register-indirect jumps.
The following examples illustrate:
Example one: Load IP with the new value codice_2, then load CS with codice_3 and IP with codice_4.
JMP 0x89AB
JMP 0xACDC:0x5578
Example two: Load EIP with the value codice_5, only in protected mode or unreal mode.
JMP 0x56789AB1
Example three: Jump to the value stored in the EAX register, only in protected mode.
JMP EAX


KEYB.COM


ALT Linux

ALT Linux is a set of Russian operating systems based on RPM Package Manager (RPM) and built on a Linux kernel and Sisyphus package repository. ALT Linux has been developed collectively by ALT Linux Team developers community and ALT Linux Ltd.
History.
ALT Linux Team arose from the merger of IPLabs Linux Team and the Linux community of the Institute of Logic, Cognitive Science and Development of Personality. The latter cooperated with Mandrake Linux and SUSE Linux teams to improve localization (specifically Cyrillic script), producing a Linux-Mandrake Russian Edition (RE).
Mandrake and Mandrake RE became different distributions and thus the decision was made to create a separate project. The name "ALT" was coined, which is a recursive acronym meaning "ALT Linux Team".
The split led to the creation of the Sisyphus package repository, which is an unstable branch of the ALT Linux development. In 2007, the Sisyphus repository won a prestigious CNews award in nomination for Information Security.
Releases.
Linux-Mandrake.
"Linux-Mandrake 7.0 Russian Edition", released in the beginning of 2000, was the first de facto independent distribution of IPLabs Linux Team. It kept the name "Mandrake" with permission from Mandrake developers.
"Spring 2001" was the second IPLabs Linux team release, released several months later.
ALT Linux 1.0.
Since the summer of 2001, ALT Linux Team has been formed and the ALT Linux name has been established.
The first ALT Linux release was "ALT Linux Junior 1.0", released in summer of 2001, followed by the updated "ALT Linux Junior 1.1" in autumn of 2001.
Junior distributions were 1CD releases.
ALT Linux 2.*.
"ALT Linux Master 2.0", released in May 2002, was the 4CD all-purpose Linux distribution targeted for software developers and system administrators.
"ALT Linux Junior 2.0" was released in summer of 2002, as a 1CD desktop/workstation-oriented release.
ALT Linux 3.0.
ALT Linux Compact 3.0 was released during autumn 2005, and consisted of 1CD/1DVD installable versions along with LiveCD (TravelCD 3.0). There were several subsequent OEM updates counting up to 3.0.5.
ALT Linux 4.0.
These series changed the official naming somewhat to be "ALT Linux 4.0 $flavour".
There was also a more conservative "school 4.0 branch" maintained for the Russian schools pilot project, and several distributions specifically tailored for schools released using that as a base.
ALT Linux 5.x.
The 5.0 branch was canceled mainly due to stormy X.org conditions (and subsequently archived); 5.1 community branch was created along with p5 "conservative" branch later in 2009. Somewhat confusingly, distributions based on the p5/branch were numbered as ALT Linux 5.0:
Lite.
A small single-CD distribution for older/low-memory computers, with Xfce as default desktop. Available in normal and Live CD versions. Rather superseded by LXDE-based New Lite.
Compact.
"Compact" is a series of ALT Linux distributions tailored for beginner users. It is mostly used on workstations, home computers, and notebooks. It includes additional means for easy configuration, many office and multimedia applications, and some games. "Compact" was also a popular choice for OEM whitelabeling, i.e., creating a specific edition for various hardware vendors to bundle with their hardware.
Server.
"ALT Linux Server" is a hardened server single CD distribution. It is certified by Federal department of technical and expert control of Russia in the following categories:
Terminal.
"ALT Linux Terminal" is a terminal server distribution based on ALT Linux Desktop and ALTSP5: a friendly/merging fork of Linux Terminal Server Project (LTSP) which is usable on older hardware acting as thin and diskless clients (16 MB RAM is enough, while stock LTSP5 usually requires ≥ 64 MB RAM). It was also adapted for Russian School Education National Project free software package.


Universe (Unix)

In some versions of the Unix operating system, the term universe was used to denote some variant of the working environment. During the late 1980s, most commercial Unix variants were derived from either System V or BSD. Most versions provided both BSD and System V universes and allowed the user to switch between them. Each universe, typically implemented by separate directory trees or separate filesystems, usually included different versions of commands, libraries, man pages, and header files. While such a facility offered the ability to develop applications portable across both System V and BSD variants, the requirements in disk space and maintenance (separate configuration files, twice the work in patching systems) gave them a problematic reputation. Systems that offered this facility included Harris/Concurrent's CX/UX, Convex's Convex/OS, Apollo's Domain/OS (version 10 only), Pyramid's DC/OSx (dropped in SVR4-based version 2), Concurrent's Masscomp/RTU, MIPS Computer Systems' RISC/os and Siemens' SINIX.
Some versions of System V Release 4 retain a system similar to Dual Universe concept, with BSD commands (which behave differently from classic System V commands) in , BSD header files in and library files in . can also be found in NeXTSTEP and OPENSTEP, as well as Solaris.


Scalar processor

Scalar processors represent a class of computer processors. A scalar processor processes only one data item at a time, with typical data items being integers or floating point numbers. A scalar processor is classified as a SISD processor ("single instruction, single data") in Flynn's taxonomy.
Other.
In contrast, in a vector processor a single instruction operates simultaneously on multiple data items (referred to as "SIMD"). The difference is analogous to the difference between scalar and vector arithmetic.
A superscalar processor, on the other hand, executes more than one instruction during a clock cycle by simultaneously dispatching multiple instructions to redundant functional units on the processor. Each functional unit is not a separate CPU core but an execution resource within a single CPU such as an arithmetic logic unit, a bit shifter, or a multiplier.


Scan-Line Interleave

Scan-Line Interleave (SLI) from 3dfx is a method for linking two (or more) video cards or chips together to produce a single output. It is an application of parallel processing for computer graphics, meant to increase the processing power available for graphics. SLI from 3dfx was introduced in 1998 and used in the Voodoo2 line of graphics accelerators. However, the original Voodoo Graphics card and the VSA-100 were also SLI-capable.
Nvidia Corporation reintroduced the SLI acronym in 2004 (though it now stands for Scalable Link Interface). NVIDIA's SLI, compared to 3dfx's SLI, is modernized to use graphics cards interfaced over the PCI Express bus.
Function.
3dfx's SLI design was the first attempt, in the consumer PC market, at combining the rendering power of two video cards. The two 3dfx cards were connected by a small ribbon cable inside the PC. This cable shared graphics and synchronization information between the cards. Each 3dfx card rendered alternating horizontal lines of pixels composing a frame.
Criticism.
3dfx incorporated the notion of adding an extra video card into its already (relatively) extensive advertising campaigns. Advertisements in various video gaming magazines had contained such quotes as "double the hardware, double the power", or "Twice as fast". Although many believed that adding another expensive card would double frame-rates, this proved not to be the case.
Aside from this, successfully running the SLI configuration often proved difficult. At the time (as the case with the Voodoo2), some motherboards would not function with three video cards installed (i.e. 2D card, Voodoo2 #1 and Voodoo2 #2). In other cases, there were issues with conflicts as system resources in normal ranges were already accounted for, partly because many features that are today integrated into motherboards (such as the network interface and sound playback facilities) were at that time provided by add-on cards, each requiring additional system resources. Some systems lacked enough open PCI slots to support the setup and additional add-on cards were sometimes sacrificed.
If the technical issues were surmounted, it was further discovered that some applications had problems operating under SLI. Furthermore, those programs that did function sometimes experienced tearing and other display artifacts resulting in a growing number of dissatisfied enthusiasts. Still, a number of fans touted SLI as the future of gaming and as such, SLI became more of a status symbol than a viable system upgrade.
By the time that the setup was cost-effective, there were single card solutions that rivaled the theoretical capabilities of the SLI configuration, for lower costs. As a result, SLI received little market presence, although many gamers still consider the 3dfx SLI setup to have been "the" setup to have for hardcore gaming. Although the performance benefit is not always obvious, it did allow higher resolution support of up to 1024x768 compared to 800x600 offered by a single card.


Hydra Engine

HYDRA Engine is a brand name for a multi-GPU solution developed by Lucid Logix. Similar to nVidia's SLI and ATI's Crossfire-technologies, Hydra allows linking several video cards together producing a single output and higher performance. Unlike SLI and CrossFire however, Hydra allows video cards from different chip manufactures to be linked together. Lucid claims it can do so with near to linear scaling of performance, i.e. two video cards equals twice the performance. The technology consists of both hardware on the motherboard and device drivers.
Currently there are two chips released under the Hydra Engine brand: Hydra 100 and Hydra 200. The basic concept behind the hardware is to intercept Microsoft DirectX or OpenGL sent to the video cards from the CPU and split these up to divide the calculation task fairly common amongst the present GPUs.
Reception.
SweClockers.com, when testing the MSI Big Bang Fusion which features Hydra 200, gave it very poor ratings citing the following: Poor drivers, poor game support, small if any performance gain over a single video card, graphical artifacts, unstable gameplay and a high price tag.


NTLDR

NTLDR (abbreviation of NT loader) is the boot loader for all releases of Windows NT operating system up to and including Windows XP and Windows Server 2003. NTLDR is typically run from the primary hard disk drive, but it can also run from portable storage devices such as a CD-ROM, USB flash drive, or floppy disk. NTLDR can also load a non NT-based operating system given the appropriate boot sector in a file.
NTLDR requires, at the minimum, the following two files to be on the system volume:
An additional important file is "boot.ini", which contains boot configuration (if missing, NTLDR will default to "\Windows" on the first partition of the first hard drive).
NTLDR is launched by the volume boot record of system partition, which is typically written to the disk by the Windows or command.
History.
Windows NT was originally designed for ARC-compatible platforms, relying on its boot manager support and providing only "osloader.exe", a loading program accepting ordinary command-line arguments specifying Windows directory partition, location or boot parameters, which is launched by ARC-compatible boot manager when a user chooses to start specific Windows NT operating system. However, because the x86 lacked any of the ARC support, the additional layer was added specifically for that platform: custom boot manager code presenting text menu allowing the user to choose from one or more operating system and its options configured in "boot.ini" configuration file, prepended by special StartUp module which is responsible for some preparations such as switching the CPU to the protected mode. When a user chooses an operating system from the boot menu, the following command-line arguments are then passed to the part of the "osloader.exe" common to all processor architectures:
In Windows releases starting from Windows Vista and Windows Server 2008, NTLDR has been split off back to its boot manager and system loader parts: the Windows Boot Manager and "winload.exe". The boot manager part has been completely rewritten; it no longer uses "boot.ini" as a configuration file, although the "bootcfg" utility for modifying boot.ini is still present for the case of multi-boot configurations with Windows versions up to Windows XP and Windows Server 2003.
Command-line interface.
The bootsect.exe utility program in the Windows PE tools has options /nt52 (NTLDR) and /nt60 (Vista and up) to store a NTLDR or Vista boot record in the first sector of a specified partition. The command can be used for FAT and NTFS based file systems. It replaces the FixFAT and FixNTFS tools.
Example.
The following example applies the NTLDR compatible master boot code to the D: volume:
C:\>bootsect /nt52 D:
Startup process.
When a PC is powered on its BIOS follows the configured boot order to find a bootable device. This can be a harddisk, floppy, CD/DVD, network connection, USB-device, etc. depending on the BIOS. In the case of a floppy the BIOS interprets its boot sector (first sector) as code, for NTLDR this could be a NTLDR boot sector looking for the codice_1 file on the floppy. For a harddisk the code in the Master Boot Record (first sector) determines the active partition. The code in the boot sector of the active partition could then be again a NTLDR boot sector looking for codice_1 in the root directory of this active partition. In a more convoluted scenario the active partition can contain a Vista boot sector for the newer Vista boot manager with an {ntldr} entry pointing to another partition with a NTLDR boot sector.
When booting, the loader portion of NTLDR does the following in order:
boot.ini.
NTLDR's first action is to read the Boot.ini file. NTLDR allows the user to choose which operating system to boot from at the menu. For NT and NT-based operating systems, it also allows the user to pass preconfigured options to the kernel. The menu options are stored in "boot.ini", which itself is located in the root of the same disk as NTLDR. Though NTLDR can boot DOS and non-NT versions of Windows, boot.ini cannot configure their boot options.
For NT-based OSs, the location of the operating system is written as an Advanced RISC Computing (ARC) path.
"boot.ini" is protected from user configuration by having the following file attributes: system, hidden, read-only. To manually edit it, the user would first have to remove these attributes.
A more secure fashion to edit the file is to use the "bootcfg" command from a console. "bootcfg" will also relock the file (setting the file back to system, hidden, and read-only). Additionally, the file can be edited within Windows using a text editor if the folder view option "Show hidden files and folders" is selected, the folder view option "Hide protected operating system files" is unchecked, and the "Read-only" option is unchecked under file properties.
"bootsect.dos" is the boot sector loaded by NTLDR to load DOS, or if there is no file specified when loading a non NT-based OS.
Example.
An example of a "boot.ini" file:
[boot loader]
timeout=40
default=multi(0)disk(0)rdisk(0)partition(1)\WINDOWS
[operating systems]
multi(0)disk(0)rdisk(0)partition(1)\WINDOWS="Microsoft Windows XP Professional" /fastdetect
If the boot loader timeout option in "boot.ini" is set to 0, the NTLDR boot menu does not appear.
Extreme caution should be taken when modifying the boot loader, as erroneous information can result in an OS that fails to boot.


ETen Chinese System

ETen Chinese System (倚天中文系統) was the most popular DOS-compatible traditional Chinese operating system before Chinese Windows 95.
DOS did not support Chinese characters, which are not in Extended ASCII. Many companies in Taiwan developed their own IBM PC compatible traditional Chinese operating system running on DOS, which were mutually incompatible between the OS, such as Kuo Chia (國喬) and Acer.
The developer of the Eten OS, E-TEN, earned their early profits from sales of their hardware based plug-in card based Chinese system products. Their software (only) Chinese systems were widely copied by many traditional Chinese users and software pirates, but this was difficult for E-TEN to control. Most traditional Chinese products were compatible with the Eten OS at that time.
When Microsoft developed the Chinese Windows 3.1 and Windows 95, traditional Chinese software developer and users shifted to Windows from DOS. The last version of the Eten OS was a Chinese Windows-compatible version. The Eten and other traditional Chinese OS are now used in a few DOS based POS systems.


Chrome 500 series

S3 Graphics Chrome 500 series is the successor of S3 Graphics Chrome S20 series, and is produced in parallel to the S3 Graphics Chrome 400.
Availability.
The 530 GT is sold from S3's store for a price of $54.95 USD. No other online stores are known to carry this model and it is out of stock as of November 6, 2009.
The 540GTX is sold from S3's Gstore for $69.95. It is similarly out of stock although a low profile version has been produced by Aopen Japan and is still on sale as of November 6, 2009.
Features.
The production model is with a 65 nm process, supports DirectX 10.1, OpenGL 3.0, and uses the PCI Express 2.0 interface. Chromotion engine now supports Variable length decoding, and dual-stream Blu-ray playback. Display unit includes 2 dual-link DVI transmitters with integrated HDMI (audio passthrough) and HDCP, an integrated dual channel LVDS transmitter, an integrated TV/HDTV encoder, and support for two analog CRTs. 530 GT runs at 625 MHz core speed, and has 512MB of 500 MHz GDDR2 memory on a 64 bit bus. The 540GTX added a DisplayPort in the full height version as well as increased clock and memory speeds of 800Mhz and 850Mhz GDDR3 respectively.
From Linux driver version 14.02.10 on, S3 Chrome 500 video cards support VDPAU.
Performance.
The 500 MHz GDDR2 memory clock, combined with the cards 64 bit memory bus, gives it a total memory bandwidth of 8GB/s, on par with budget cards from Nvidia and AMD. Performance information released by S3 indicates the cards performance in 3dMark 2006 is comparable to an AMD HD4350.


Visualize EG

The Visualize EG is a Hewlett-Packard 2D graphics card used in their Series 700 UNIX workstations.
The Visualize-EG (project name Graffiti) was the basic graphics card in the era of HP's older B, C and J class workstations (e.g., the B132). In those, EG was the integrated (on the motherboard) display device, although it was also available in GSC and later PCI card form. EG is a descendant of HP's CRX family of graphics devices.
Despite being entry level, and offering no hardware 3D features, EG had excellent 2D performance. Specifications (without optional memory upgrade) are:
Optional memory can be used to provide one or the other of these benefits:
16 of these become image planes with the other 8 used as moveable "overlay" planes. Another 2 hardware colormaps become available, providing 2 for the image planes and 2 for the overlay planes.
The EG features an accelerated 2D graphics engine that is capable of:
The programming interface of the EG (and other HP graphics devices) has been kept private to HP, although efforts to release them are underway. The documentation needs to be "scrubbed" to check and remove company confidential material.


Kwort Linux

Kwort is a Linux distribution, based on CRUX. Kwort's desktop environment is Openbox.
Installation.
The distribution is available for download as installation-only CD image suitable for x64-based computers. It does not provide installation program. Instead, text-based applications and scripts are used to install and configure the system. Contrary to CRUX Linux, the user doesn't need to compile a new kernel.
System requirements.
The system requirements of Kwort are:
Package manager.
Kwort Linux uses the kpkg package manager. kpkg can download and install packages from Kwort's or third party repositories and their mirrors.
Reception.
Tux Machines reviewed Kwort Linux in March 2006. The review included the following:
Jesse Smith wrote a review of Kwort 4.3 for DistroWatch Weekly:


FOLDER.SYS


List of VIA microprocessor cores

This page lists x86-compliant microprocessors sold by VIA Technologies, grouped by technical merits: cores within same group have much in common.


DECwindows


Uhuru Mobile

Uhuru Mobile is a secure Android-based operating system.
An operating system is the principal program allowing Smartphones, Tablets and PCs to run. This central tool connects and coordinates all the components such as kernel, computers programs, software or device drivers, letting users managing their devices.
Uhuru Mobile is a solution composed with its application encryption market, a modified Android-based OS, a virtual private network and a SMS encryption solution.
The purpose of Uhuru Mobile is to prevent physical attacks.
History.
The name Uhuru comes from the Swahili language and means "freedom" and "independence".
Uhuru Mobile is the result of a research and development project initiated in 2012 to promote digital sovereignty.
As an Android-based operating system, Uhuru Mobile focuses on security and privacy for end-users, individuals or businesses, on mobile devices.
The operating system is currently developed by a software Editor company called Teclib’.
Software Overview.
Additional Features.
To ensure the OS protection and security while using applications, a dedicated market has been installed (replacing the Google Play Store). Uhuru Mobile’s applications market only provides apps approved and certified by a team of security experts. Companies can also customize the Uhuru marketplace providing their in-house applications.
Uhuru mobile is provided with a deception system, sending fake GPS location coordinates to applications. This decoy geolocation tool allows users to fool some applications using geolocation. IT administrators can define the redirecting coordinates. For example in the demo version, the NSA headquarters coordinates were sent by the deception system.
A mobile device management tool for the administration of mobile devices is provided without any additional setup. IT administrators have access to a web-console in order to manage the Uhuru Mobile fleet and all linked applications (such as the remote apps installation/suppression or the set up of user accounts).


SSE2

SSE2 (Streaming SIMD Extensions 2) is one of the Intel SIMD (Single Instruction, Multiple Data) processor supplementary instruction sets first introduced by Intel with the initial version of the Pentium 4 in 2000. It extends the earlier SSE instruction set, and is intended to fully replace MMX. Intel extended SSE2 to create SSE3 in 2004. SSE2 added 144 new instructions to SSE, which has 70 instructions. Competing chip-maker AMD added support for SSE2 with the introduction of their Opteron and Athlon 64 ranges of AMD64 64-bit CPUs in 2003.
Features.
Most of the SSE2 instructions implement the integer vector operations also found in MMX. Instead of the MMX registers they use the XMM registers, which are wider and allow for significant performance improvements in specialized applications. Another advantage of replacing MMX with SSE2 is avoiding the mode switching penalty for issuing x87 instructions present in MMX because it is sharing register space with the x87 FPU. The SSE2 also complements the floating-point vector operations of the SSE instruction set by adding support for the double precision data type.
Other SSE2 extensions include a set of cache control instructions intended primarily to minimize cache pollution when processing infinite streams of information, and a sophisticated complement of numeric format conversion instructions.
AMD's implementation of SSE2 on the AMD64 (x86-64) platform includes an additional eight registers, doubling the total number to 16 (XMM0 through XMM15). These additional registers are only visible when running in 64-bit mode. Intel adopted these additional registers as part of their support for x86-64 architecture (or in Intel's parlance, "Intel 64") in 2004.
Differences between x87 FPU and SSE2.
FPU (x87) instructions provide higher precision by calculating intermediate results with 80 bits of precision, by default, to minimise roundoff error in numerically unstable algorithms (see IEEE 754 design rationale and references therein). However, the x87 FPU is a scalar unit only whereas SSE2 can process a small vector of operands in parallel.
If codes designed for x87 are ported to the lower precision double precision SSE2 floating point, certain combinations of math operations or input datasets can result in measurable numerical deviation, which can be an issue in reproducible scientific computations, e.g. if the calculation results must be compared against results generated from a different machine architecture. A related issue is that, historically, language standards and compilers had been inconsistent in their handling of the x87 80-bit registers implementing double extended precision variables, compared with the double and single precision formats implemented in SSE2: the rounding of extended precision intermediate values to double precision variables was not fully defined and was dependent on implementation details such as when registers were spilled to memory.
Differences between MMX and SSE2.
SSE2 extends MMX instructions to operate on XMM registers. Therefore, it is possible to convert all existing MMX code to an SSE2 equivalent. Since an SSE2 register is twice as long as an MMX register, loop counters and memory access may need to be changed to accommodate this. However, 8 byte loads and stores to XMM are available, so this is not strictly required.
Although one SSE2 instruction can operate on twice as much data as an MMX instruction, performance might not increase significantly. Two major reasons are: accessing SSE2 data in memory not aligned to a 16-byte boundary can incur significant penalty, and the throughput of SSE2 instructions in older x86 implementations was half that for MMX instructions. Intel addressed the first problem by adding an instruction in SSE3 to reduce the overhead of accessing unaligned data and improving the overall performance of misaligned loads, and the last problem by widening the execution engine in their Core microarchitecture in Core 2 Duo and later products.
Since MMX and x87 register files alias one another, using MMX will prevent x87 instructions from working as desired. Once MMX has been used, the programmer must use the emms instruction (C: _mm_empty()) to restore operation to the x87 register file. On some operating systems, x87 is not used very much, but may still be used in some critical areas like pow() where the extra precision is needed. In such cases, the corrupt floating-point state caused by failure to emit emms may go undetected for millions of instructions before ultimately causing the floating-point routine to fail, returning NaN. Since the problem is not locally apparent in the MMX code, finding and correcting the bug can be very time consuming. As SSE2 does not have this problem, usually provides much better throughput and provides more registers in 64-bit code, it should be preferred for nearly all vectorization work.
Compiler usage.
When first introduced in 2000, SSE2 was not supported by software development tools. For example, to use SSE2 in a Microsoft Visual Studio project, the programmer had to either manually write inline-assembly or import object-code from an external source. Later the Visual C++ Processor Pack added SSE2 support to Visual C++ and MASM.
The Intel C++ Compiler can automatically generate SSE4, SSSE3, SSE3, SSE2, and SSE code without the use of hand-coded assembly.
Since GCC 3, GCC can automatically generate SSE/SSE2 scalar code when the target supports those instructions. Automatic vectorization for SSE/SSE2 has been added since GCC 4.
The Sun Studio Compiler Suite can also generate SSE2 instructions when the compiler flag -xvector=simd is used.
Since Microsoft Visual C++ 2012, the compiler option to generate SSE2 instructions is turned on by default.
CPU support.
SSE2 is an extension of the IA-32 architecture, based on the x86 instruction set. Therefore, only x86 processors can include SSE2. The AMD64 architecture supports the IA-32 as a compatibility mode and includes the SSE2 in its specification. It also doubles the number of XMM registers, allowing for better performance. SSE2 is also a requirement for installing Windows 8 (and later) or Microsoft Office 2013 (and later) "to enhance the reliability of third-party apps and drivers running in Windows 8".
The following IA-32 CPUs support SSE2:
The following IA-32 CPUs were released after SSE2 was developed, but did not implement it:


Mail (Unix)

mail is a command-line email client for Unix and Unix-like operating systems.
History.
"Electronic mail was there from the start", Douglas McIlroy writes in his article "A Research UNIX Reader: Annotated Excerpts from the Programmer’s Manual, 1971-1986", and so a command was included in the first released version of research Unix, First Edition Unix.
This version of mail was capable to send (append) messages to the mailboxes of other users on the Unix system, and it helped managing (reading) the mailbox of the current user.
In 1978 Kurt Shoens wrote a completely new version of mail for BSD2, referred to as Berkeley Mail. Although initially installed at , (with the earlier Unix mail still available at ), on most modern Unix and Linux systems the commands , and/or all invoke a descendant of this Berkeley Mail, which much later was the base for the standardization of a mail program by the OpenGroup, the POSIX standardized variant mailx.


OliveBSD


MBASIC.COM


Floppyfw

floppyfw was a Linux distribution running BusyBox to provide a firewall/gateway/router on a single bootable floppy disk, but was later available in CD format.
Reviews concluded that it was a very simple and reliable gateway/firewall that could be established on small to medium-sized networks at low cost and with ease. One independent study concluded that it was " best possible security provided by a floppy-based firewall" for the repurposing of old, redundant hardware into Linux-based firewalls or routers.
Features.
Floppyfw's features include:


IBMBIO.DOS


OS X Mavericks

OS X Mavericks (version 10.9) is the tenth major release of macOS, Apple Inc.'s desktop and server operating system for Macintosh computers. OS X Mavericks was announced on June 10, 2013, at WWDC 2013, and was released on October 22, 2013 worldwide.
The update emphasized battery life, Finder improvements, other improvements for power users, and continued iCloud integration, as well as bringing more of Apple's iOS apps to OS X. Mavericks, which was named after the surfing location in Northern California, was the first in the series of OS X releases named for places in Apple's home state; earlier releases used the names of big cats.
OS X Mavericks was the first OS X major release to be a free upgrade and the second overall since Mac OS X 10.1 "Puma".
History.
Apple announced OS X Mavericks on June 10, 2013, during the company's Apple Worldwide Developers Conference (WWDC) keynote (which also introduced iOS 7, a revised MacBook Air, the sixth-generation AirPort Extreme, the fifth-generation AirPort Time Capsule, and a redesigned Mac Pro). During a keynote on October 22, 2013, Apple announced that the official release of 10.9 on the Mac App Store would be available immediately, and that unlike previous versions of OS X, 10.9 would be available at no charge to all users running Snow Leopard (10.6.8) or later.
On October 22, 2013, Apple offered free upgrades for life on OS X and iWork.
System requirements.
OS X Mavericks can run on any Mac that can run OS X Mountain Lion; as with Mountain Lion, 2 GB of RAM, 8 GB of available storage, and OS X 10.6.8 (Snow Leopard) or later are required. Mavericks and later versions are all available for free.
The full list of compatible models:
System features.
The menu bar and the Dock are available on each display. Additionally, AirPlay compatible displays such as the Apple TV can be used as an external display. Mission Control has been updated to organize and switch between Desktop workspaces independently between multiple displays.
OS X Mavericks introduced App Nap, which sleeps apps that are not currently visible. Any app running on Mavericks can be eligible for this feature by default.
Compressed Memory is a virtual memory compression system which automatically compresses data from inactive apps when approaching maximum memory capacity.
Timer coalescing is a feature that enhances energy efficiency by reducing CPU usage by up to 72 percent. This allows MacBooks to run for longer periods of time and desktop Macs to run cooler.
Apple now supports OpenGL 4.1 Core Profile and OpenCL 1.2. Server Message Block version 2 (SMB2) is now the default protocol for sharing files, rather than AFP. This is to increase performance and cross-platform compatibility.
Some skeuomorphs, such as the leather texture in Calendar, the legal pad theme of Notes, and the book-like appearance of Contacts, have been removed from the UI.
iCloud Keychain stores a user's usernames, passwords and Wi-Fi passwords to allow the user to fill this information into forms when needed.
The system has native LinkedIn sharing integration.
IPoTB (Internet Protocol over Thunderbolt Bridge) Thunderbolt networking is supported in Mavericks. This feature allows the user to quickly transfer a large amount of data between two Macs.
Notification Center allows the user to reply to notifications instantly, allows websites to send notifications, and, when the user wakes up a Mac that was in a sleep state, displays a summary of missed notifications before the machine is unlocked. Some system alerts, such as low battery, removal of drives without ejecting, and a failed Time Machine backup have been moved to Notification Center.
The "traffic light" close, minimize, and maximize window buttons have appeared somewhat brighter than Mac OS X Lion and OS X Mountain Lion.
App features.
Finder gets enhancements such as tabs, full-screen support, and document tags. Pinch-to-zoom and swipe-to-navigate-history gestures have been removed, although both are supported anywhere else.
The new iBooks application allows the user to read books purchased through the iBooks Store. The app also allows the user to purchase new content from the iBooks Store, and a night mode to make it easier to read in dark environments.
The new Maps application allows the user the same functionality as in iOS Maps.
The Calendar app has enhancements such as being able to add Facebook events, and an estimate for the travel time to an event.
The Safari browser has a significantly enhanced JavaScript performance which Apple claims is faster than Chrome and Firefox. A Top Sites view allows the user to quickly access the most viewed sites by default. However, the user can pin or remove websites from the view. The sidebar now allows the user to view their bookmarks, reading list and shared links. Safari can also auto-generate random passwords and remember them through iCloud Keychain.
Removed functionality.
The Open Transport API has been removed. USB syncing of calendar, contacts and other information to iOS devices has been removed, instead requiring the use of iCloud. QuickTime 10 no longer supports many older video codecs and converts them to the ProRes format when opened. Older video codecs cannot be viewed in Quick Look. Apple also removed the ability to sync mobile iCloud Notes if iOS devices were upgraded from iOS 8 to iOS 9, effectively forcing all Mavericks users to update or upgrade their computers.
Reception.
OS X Mavericks has received mixed reviews.
One complaint is that Apple removed the local sync services, which forces users to get iCloud to sync iOS devices with the desktop OS. However, this feature has since returned in the 10.9.3 and iTunes 11.2 updates.
The Verge stated that OS X Mavericks was “a gentle evolution of the Mac operating system”.
References.


XMSMMGR.EXE


XBurst


HLT (x86 instruction)

In the x86 computer architecture, codice_1 (halt) is an assembly language instruction which halts the central processing unit (CPU) until the next external interrupt is fired. Interrupts are signals sent by hardware devices to the CPU alerting it that an event occurred to which it should react. For example, hardware timers send interrupts to the CPU at regular intervals.
The codice_1 instruction is executed by the operating system when there is no immediate work to be done, and the system enters its idle state. In Windows NT, for example, this instruction is run in the "System Idle Process". On x86 processors, the opcode of codice_1 is codice_4.
History on x86.
All x86 processors from the 8086 onwards had the codice_1 instruction, but it was not used by MS-DOS prior to 6.0 and was not specifically designed to reduce power consumption until the release of the Intel DX4 processor in 1994. MS-DOS 6.0 provided a POWER.EXE that could be installed in CONFIG.SYS and in Microsoft's tests it saved 5%. Some of the first 100 MHz DX chips had a buggy HLT state, prompting the developers of Linux to implement a "no-hlt" option for use when running on those chips, but this was fixed in later chips.
Intel has since introduced additional processor-yielding instructions. These include:
Process.
Almost every modern processor instruction set includes an instruction or sleep mode which halts the processor until more work needs to be done. In interrupt-driven processors, this instruction halts the CPU until an external interrupt is received. On most architectures, executing such an instruction allows the processor to significantly reduce its power usage and heat output, which is why it is commonly used instead of busy waiting for sleeping and idling.
Use in operating systems.
Since issuing the codice_1 instruction requires ring 0 access, it can only be run by privileged system software such as the kernel. Because of this, it is often best practice in application programming to use the application programming interface (API) provided for that purpose by the operating system when no more work can be done, such as Linux's codice_7. This is referred to as "yielding" the processor. This allows the operating system's scheduler to decide if other processes are runnable; if not, it will normally issue the HLT instruction to cut power usage.


Earnest Evans

Earnest Evans (アーネスト・エバンス "Ānesuto Ebansu") is a 1991 action platform game which was released in Japan for the Sega Mega-CD, and in North America for the Sega Genesis. The game was developed and published by Wolf Team in Japan, and was published in North America by Renovation. As with "Sol-Feace", the Mega-CD release has a Mixed Mode CD soundtrack along with animated cutscenes created by Madhouse. It is the second story in a trilogy of games which include "El Viento" and "Anett Futatabi".
Gameplay.
As a 2D side-scrolling game in which the hero uses a whip, the gameplay and design are often compared to the "Castlevania" series. In addition to the whip, there are three other weapons to be found; however, they are only used once in certain areas. The three additional weapons are exploding rocks, a morning star, and a hammerlike weapon. The adventure takes Earnest to destinations which include raiding tombs in Mexico, Peru, moving trains, a forest, and the Grand Canyons, while attempting to save the world. Unlike most platform games on the Genesis/Mega Drive, the character Earnest Evans is made up of several sprites to give him a fluid ragdoll-like movement.
Plot.
In the 1930s, a man known as Earnest Evans had learned of three ancient idols which hold enough power to destroy the Earth. Evans had decided to search the world to find the scattered idols, but was injured before he could find all three. Now, many years later, his grandson, Earnest Evans III, continues his grandfather's quest to save humanity from total annihilation. However, a rival treasure hunter named Brady Tresidder also seeks the idols to bring the world's destruction. Evans must find the treasures before Tresidder does. During his journey, Evans stumbles upon the beautiful young green-haired girl Annet Myer lying in some ruins in Peru who decides to accompany him for the rest of his adventures. The two encounter a mysterious figure by the name of Sigfried, who has unknown motives, but seems to know a lot about Hastur and his cult.


DELWATCH file last modification date


MDOS.COM


Greg Papadopoulos

Gregory Michael Papadopoulos (born 1958) is an American engineer, executive, and venture capitalist.
He is the creator and lead proponent for Redshift, a theory on whether technology markets are over or under-served by Moore's Law.
Biography.
Papadopoulos achieved a B.A. in systems science from the University of California, San Diego in 1979, and was the recipient of both S.M. and Ph.D. degrees in electrical engineering and computer science from the Massachusetts Institute of Technology (MIT) in 1983 and 1988 respectively. At some time he held positions at Hewlett-Packard and Honeywell.
While a graduate student, he worked at MIT spinoff PictureTel in its early days.
His dissertation was on a dataflow architecture microprocessor, under advisor Professor Arvind. Along with David E. Culler, he developed a simplified approach to dataflow execution in a project named Monsoon.
Papadopoulos became assistant professor at MIT in 1988 and associate professor in May 1993, where he helped start Ergo Computing in 1988, and Exa Corporation in 1991.
He was chief architect at Thinking Machines Corporation while on the MIT faculty starting in 1992.
His research applied massively parallel techniques to high-performance computing.
He joined Sun Microsystems in September 1994. After serving as chief scientist for the server division, in December 1995 he became chief technical officer (CTO) of SMCC (Sun's hardware division), and CTO of the entire company in April 1998.
He left Sun in February 2010.
Papadopoulos co-authored (with David Douglas and John Boutelle) the book on "Citizen Engineer: A Handbook for Socially Responsible Engineering", published in 2009.
At the time he lived in Los Gatos, California.
In 2010 Papadopoulos joined venture capital firm New Enterprise Associates (NEA) as an executive in residence and the Computer History Museum as a director. In April, 2011, Papadopoulos became a partner at NEA.
At some time he was chairman of the board of trustees for the SETI Institute.


CPCDOS.SYS


UPX

UPX (Ultimate Packer for Executables) is an open source executable packer supporting a number of file formats from different operating systems.
Compression.
UPX uses a data compression algorithm called UCL, which is an open-source implementation of portions of the proprietary NRV ("Not Really Vanished") algorithm.
UCL has been designed to be simple enough that a decompressor can be implemented in just a few hundred bytes of code. UCL requires no additional memory to be allocated for decompression, a considerable advantage that means that a UPX packed executable usually requires no additional memory.
UPX (since 2.90 beta) can use LZMA on most platforms; however, this is disabled by default for 16-bit due to slow decompression speed on older computers (use codice_1 to force it on).
Starting with version 3.91, UPX also supports 64-Bit (x64) executable files on the Windows platform. This feature is currently declared as "experimental".
Decompression.
UPX supports two mechanisms for decompression: an in-place technique and extraction to temporary file.
The in-place technique, which decompresses the executable into memory, is not possible on all supported platforms. It has the advantage of being more efficient in terms of memory, and that the environment set up by the OS remains correct.
The rest uses extraction to temporary file. This procedure involves additional overhead and other disadvantages; however, it allows any executable file format to be packed. The extraction to temporary file method has several disadvantages:
Unmodified UPX packing is often detected and unpacked by antivirus software scanners. UPX also has a built-in feature for unpacking unmodified executables packed with itself.
Supported formats.
UPX supports the following formats:
UPX does not currently support PE files containing CIL code intended to run on the .NET Framework.


Movidius

Movidius is a company based in San Mateo, California that designs specialised low-power processor chips for computer vision. The company was acquired by Intel in September 2016.
Company history.
Movidius was co-founded in Dublin in 2005 by Sean Mitchell and David Moloney. Between 2006 and 2016, it raised nearly $90 million in capital funding. In May, 2013 the company appointed Remi El-Ouazzane as CEO. In January, 2016 the company announced a partnership with Google. Movidius has been active in the Google Project Tango project. Movidius announced a planned acquisition by Intel in September 2016.
Products.
Myriad 2.
The company's Myriad 2 chip is an always-on manycore vision processing unit that can function on power-constrained devices. The "Fathom" is a USB stick containing a Myriad 2 processor, allowing a vision accelerator to be added to devices using ARM processors including PCs, drones, robots, IoT devices and video surveillance for tasks such as identifying people or objects. It can run at between 80 and 150 GFLOPS on little more than 1W of power.
Myriad X.
Intel's Myriad X VPU (vision processing unit) is the third generation and most advanced VPU from Movidius, an Intel company. Intel's Myriad X VPU is the first of its class to feature the Neural Compute Engine—a dedicated hardware accelerator for deep neural network deep-learning inferences. The Neural Compute Engine in conjunction with the 16 SHAVE cores and an ultra-high throughput intelligent memory fabric makes Myriad X a strong option for on-device deep neural networks and computer vision applications. Intel's Myriad X VPU has received additional upgrades to imaging and vision engines including additional programmable SHAVE cores, upgraded and expanded vision accelerators, and a new native 4K image processor pipeline with support for up to 8 HD sensors connecting directly to the VPU. As with Myriad 2, the Myriad X VPU is programmable via the Myriad Development Kit (MDK) which includes all necessary development tools, frameworks and APIs to implement custom vision, imaging and deep neural network workloads on the chip.
Neural Compute Stick.
The Intel Movidius Neural Compute Stick (NCS) is a tiny fanless deep-learning device that can be used to learn AI programming at the edge. NCS is powered by the same low-power, high-performance Intel Movidius Vision Processing Unit that can be found in millions of smart security cameras, gesture-controlled drones, industrial machine vision equipment, and more. Supported frameworks are TensorFlow and Caffe.
On 14 November 2018, the company announced the latest version of NCS, marketed as "Neural Compute Stick 2" at the AI DevCon event in Beijing.


Michael J. Karels

Michael J. (Mike) Karels is an American Software Engineer and one of the key people in history of BSD UNIX.
A graduate of University of Notre Dame with a Bachelor of Science in Microbiology. Mike went on to University of California, Berkeley for his advanced degree in Microbiology.
Mike had access to the department's computer and since the administrator of that PDP-11 did not have enough time, Mike started helping him and then making changes to the system.
Mike started his contribution to Unix with the 2.9BSD release, distributed for the PDP-11.
When Mike saw a job posting with the Computer Systems Research Group in the BSD project, he decided to jump in.
In 1982, Mike took over Bill Joy's responsibilities when Mr. Joy left CSRG, and was the system architect for 4.3BSD, the most important BSD release and the base of the development for a number of commercial Unix flavors available today, including Solaris. This release was introduced to the world in deep detail through the all-time famous book, The Design and Implementation of the 4.3BSD UNIX Operating System, with black cover and smiling beastie. Mike was a CSRG principal programmer for 8 years.
Mike worked closely with Van Jacobson on a number of widely accepted algorithms
in TCP implementation. Including the Jacobson/Karels algorithm TCP slow start and the routing radix tree are probably the most famous ones.
Mike spends little time taking credit for this work, and on the other hand, uses every opportunity to mention the names of people who had in one way or other some role or contribution to the TCP/IP implementation in Unix.
In 1993, the USENIX Association gave a Lifetime Achievement Award ("Flame") to the Computer Systems Research Group at University of California, Berkeley, honoring 180 individuals, including Karels, who contributed to the CSRG's 4.4BSD-Lite release.
Later, Mike moved to BSDi (Berkeley Software Design) and designed BSD/OS, which was, for years, the only commercially available BSD style Unix on Intel platform. BSD/OS is a very reliable OS platform designed for Internet services. BSDi software asset was bought by Wind River in April 2001, and Mike joined Wind River as the Principal Technologist for the BSD/OS platform.
In 2009, Mike was Sr Principal Engineer at McAfee. In 2015 he worked for Intel and later for Forcepoint LLC.


List of Intel Pentium II microprocessors

The Pentium II from Intel is a sixth-generation CPU targeted at the consumer market.