Main article: Parallel computing

Model of a subscalar CPU. Notice that it takes fifteen cycles to complete three instructions.

The description of the basic operation of a CPU offered in the previous section describes the simplest form that a CPU can take. This type of CPU, usually referred to as subscalar, operates on and executes one instruction on one or two pieces of data at a time.

This process gives rise to an inherent inefficiency in subscalar CPUs. Since only one instruction is executed at a time, the entire CPU must wait for that instruction to complete before proceeding to the next instruction. As a result the subscalar CPU gets "hung up" on instructions which take more than one clock cycle to complete execution. Even adding a second execution unit (see below) does not improve performance much; rather than one pathway being hung up, now two pathways are hung up and the number of unused transistors is increased. This design, wherein the CPU's execution resources can operate on only one instruction at a time, can only possibly reach scalar performance (one instruction per clock). However, the performance is nearly always subscalar (less than one instruction per cycle).

Attempts to achieve scalar and better performance have resulted in a variety of design methodologies that cause the CPU to behave less linearly and more in parallel. When referring to parallelism in CPUs, two terms are generally used to classify these design techniques. Instruction level parallelism (ILP) seeks to increase the rate at which instructions are executed within a CPU (that is, to increase the utilization of on-die execution resources), and thread level parallelism (TLP) purposes to increase the number of threads (effectively individual programs) that a CPU can execute simultaneously. Each methodology differs both in the ways in which they are implemented, as well as the relative effectiveness they afford in increasing the CPU's performance for an application.^[10]

[edit] Instruction level parallelism

Main articles: Instruction pipelining and Superscalar

Basic five-stage pipeline. In the best case scenario, this pipeline can sustain a completion rate of one instruction per cycle.

One of the simplest methods used to accomplish increased parallelism is to begin the first steps of instruction fetching and decoding before the prior instruction finishes executing. This is the simplest form of a technique known as instruction pipelining, and is utilized in almost all modern general-purpose CPUs. Pipelining allows more than one instruction to be executed at any given time by breaking down the execution pathway into discrete stages. This separation can be compared to an assembly line, in which an instruction is made more complete at each stage until it exits the execution pipeline and is retired.

Pipelining does, however, introduce the possibility for a situation where the result of the previous operation is needed to complete the next operation; a condition often termed data dependency conflict. To cope with this, additional care must be taken to check for these sorts of conditions and delay a portion of the instruction pipeline if this occurs. Naturally, accomplishing this requires additional circuitry, so pipelined processors are more complex than subscalar ones (though not very significantly so). A pipelined processor can become very nearly scalar, inhibited only by pipeline stalls (an instruction spending more than one clock cycle in a stage).

Simple superscalar pipeline. By fetching and dispatching two instructions at a time, a maximum of two instructions per cycle can be completed.

Further improvement upon the idea of instruction pipelining led to the development of a method that decreases the idle time of CPU components even further. Designs that are said to be superscalar include a long instruction pipeline and multiple identical execution units. ^{[Huynh 2003]} In a superscalar pipeline, multiple instructions are read and passed to a dispatcher, which decides whether or not the instructions can be executed in parallel (simultaneously). If so they are dispatched to available execution units, resulting in the ability for several instructions to be executed simultaneously. In general, the more instructions a superscalar CPU is able to dispatch simultaneously to waiting execution units, the more instructions will be completed in a given cycle.

Most of the difficulty in the design of a superscalar CPU architecture lies in creating an effective dispatcher. The dispatcher needs to be able to quickly and correctly determine whether instructions can be executed in parallel, as well as dispatch them in such a way as to keep as many execution units busy as possible. This requires that the instruction pipeline is filled as often as possible and gives rise to the need in superscalar architectures for significant amounts of CPU cache. It also makes hazard-avoiding techniques like branch prediction, speculative execution, and out-of-order execution crucial to maintaining high levels of performance. By attempting to predict which branch (or path) a conditional instruction will take, the CPU can minimize the number of times that the entire pipeline must wait until a conditional instruction is completed. Speculative execution often provides modest performance increases by executing portions of code that may or may not be needed after a conditional operation completes. Out-of-order execution somewhat rearranges the order in which instructions are executed to reduce delays due to data dependencies.

In the case where a portion of the CPU is superscalar and part is not, the part which is not suffers a performance penalty due to scheduling stalls. The original Intel Pentium (P5) had two superscalar ALUs which could accept one instruction per clock each, but its FPU could not accept one instruction per clock. Thus the P5 was integer superscalar but not floating point superscalar. Intel's successor to the Pentium architecture, P6, added superscalar capabilities to its floating point features, and therefore afforded a significant increase in floating point instruction performance.

Both simple pipelining and superscalar design increase a CPU's ILP by allowing a single processor to complete execution of instructions at rates surpassing one instruction per cycle (IPC).^[11] Most modern CPU designs are at least somewhat superscalar, and nearly all general purpose CPUs designed in the last decade are superscalar. In later years some of the emphasis in designing high-ILP computers has been moved out of the CPU's hardware and into its software interface, or ISA. The strategy of the very long instruction word (VLIW) causes some ILP to become implied directly by the software, reducing the amount of work the CPU must perform to boost ILP and thereby reducing the design's complexity.

[edit] Thread level parallelism

Another strategey of achieving performance is to execute multiple programs or threads in parallel. This area of research is known as parallel computing. In Flynn's taxonomy, this strategy is known as Multiple Instructions-Multiple Data or MIMD.

One technology used for this purpose was multiprocessing (MP). The initial flavor of this technology is known as symmetric multiprocessing (SMP), where a small number of CPUs share a coherent view of their memory system. In this scheme, each CPU has additional hardware to maintain a constantly up-to-date view of memory. By avoiding stale views of memory, the CPUs can cooperate on the same program and programs can migrate from one CPU to another. To increase the number of cooperating CPUs beyond a handful, schemes such as non-uniform memory access (NUMA) and directory-based coherence protocols were introduced in the 1990s. SMP systems are limited to a small number of CPUs while NUMA systems have been built with thousands of processors. Initially, multiprocessing was built using multiple discrete CPUs and boards to implement the interconnect between the processors. When the processors and their interconnect are all implemented on a single silicon chip, the technology is known as a multi-core microprocessor.

It was later recognized that finer-grain parallelism existed with a single program. A single program might have several threads (or functions) that could be executed separately or in parallel. Some of earliest examples of this technology implemented input/output processing such as direct memory access as a separate thread from the computation thread. A more general approach to this technology was introduced in the 1970s when systems were designed to run multiple computation threads in parallel. This technology is known as multi-threading (MT). This approach is considered more cost-effective than multiprocessing, as only a small number of components within a CPU is replicated in order to support MT as opposed to the entire CPU in the case of MP. In MT, the execution units and the memory system including the caches are shared among multiple threads. The downside of MT is that the hardware support for multithreading is more visible to software than that of MP and thus supervisor software like operating systems have to undergo larger changes to support MT. One type of MT that was implemented is known as block multithreading, where one thread is executed until it is stalled waiting for data to return from external memory. In this scheme, the CPU would then quickly switch to another thread which is ready to run, the switch often done in one CPU clock cycle. Another type of MT is known as simultaneous multithreading, where instructions of multiple threads are executed in parallel within one CPU clock cycle.

For several decades from the 1970s to early 2000s, the focus in designing high performance general purpose CPUs was largely on achieving high ILP through technologies such as pipelining, caches, superscalar execution, Out-of-order execution, etc. This trend culminated in large, power-hungry CPUs such as the Intel Pentium 4. By the early 2000s, CPU designers were thwarted from achieving higher performance from ILP techniques due to the growing disparity between CPU operating frequencies and main memory operating frequencies as well as escalating CPU power dissipation owing to more esoteric ILP techniques.

CPU designers then borrowed ideas from commercial computing markets such as transaction processing, where the aggregate performance of multiple programs, also known as throughput computing, was more important than the performance of a single thread or program.

This reversal of emphasis is evidenced by the proliferation of dual and multiple core CMP (chip-level multiprocessing) designs and notably, Intel's newer designs resembling its less superscalar P6 architecture. Late designs in several processor families exhibit CMP, including the x86-64 Opteron and Athlon 64 X2, the SPARC UltraSPARC T1, IBM POWER4 and POWER5, as well as several video game console CPUs like the Xbox 360's triple-core PowerPC design, and the PS3's 8-core Cell microprocessor.

[edit] Data parallelism

Main articles: Vector processor and SIMD

A less common but increasingly important paradigm of CPUs (and indeed, computing in general) deals with data parallelism. The processors discussed earlier are all referred to as some type of scalar device.^[12] As the name implies, vector processors deal with multiple pieces of data in the context of one instruction. This contrasts with scalar processors, which deal with one piece of data for every instruction. Using Flynn's taxonomy, these two schemes of dealing with data are generally referred to as SISD (single instruction, single data) and SIMD (single instruction, multiple data), respectively. The great utility in creating CPUs that deal with vectors of data lies in optimizing tasks that tend to require the same operation (for example, a sum or a dot product) to be performed on a large set of data. Some classic examples of these types of tasks are multimedia applications (images, video, and sound), as well as many types of scientific and engineering tasks. Whereas a scalar CPU must complete the entire process of fetching, decoding, and executing each instruction and value in a set of data, a vector CPU can perform a single operation on a comparatively large set of data with one instruction. Of course, this is only possible when the application tends to require many steps which apply one operation to a large set of data.

Most early vector CPUs, such as the Cray-1, were associated almost exclusively with scientific research and cryptography applications. However, as multimedia has largely shifted to digital media, the need for some form of SIMD in general-purpose CPUs has become significant. Shortly after floating point execution units started to become commonplace to include in general-purpose processors, specifications for and implementations of SIMD execution units also began to appear for general-purpose CPUs. Some of these early SIMD specifications like Intel's MMX were integer-only. This proved to be a significant impediment for some software developers, since many of the applications that benefit from SIMD primarily deal with floating point numbers. Progressively, these early designs were refined and remade into some of the common, modern SIMD specifications, which are usually associated with one ISA. Some notable modern examples are Intel's SSE and the PowerPC-related AltiVec (also known as VMX).^[13]

The fundamental operation of most CPUs, regardless of the physical form they take, is to execute a sequence of stored instructions called a program.The program is represented by a series of numbers that are kept in some kind of computer memory. There are four steps that nearly all von Neumann CPUs use in their operation: fetch, decode, execute, and writeback.

The first step, fetch, involves retrieving an instruction (which is represented by a number or sequence of numbers) from program memory. The location in program memory is determined by a program counter (PC), which stores a number that identifies the current position in the program. In other words, the program counter keeps track of the CPU's place in the current program. After an instruction is fetched, the PC is incremented by the length of the instruction word in terms of memory units.^[3] Often the instruction to be fetched must be retrieved from relatively slow memory, causing the CPU to stall while waiting for the instruction to be returned. This issue is largely addressed in modern processors by caches and pipelinearchitectures (see below).

The instruction that the CPU fetches from memory is used to determine what the CPU is to do. In the decode step, the instruction is broken up into parts that have significance to other portions of the CPU. The way in which the numerical instruction value is interpreted is defined by the CPU's instruction set architecture(ISA).^[4] Often, one group of numbers in the instruction, called the opcode, indicates which operation to perform. The remaining parts of the number usually provide information required for that instruction, such as operands for an addition operation. Such operands may be given as a constant value (called an immediate value), or as a place to locate a value: a register or a memory address, as determined by some addressing mode. In older designs the portions of the CPU responsible for instruction decoding were unchangeable hardware devices. However, in more abstract and complicated CPUs and ISAs, a microprogram is often used to assist in translating instructions into various configuration signals for the CPU. This microprogram is sometimes rewritable so that it can be modified to change the way the CPU decodes instructions even after it has been manufactured.

After the fetch and decode steps, the execute step is performed. During this step, various portions of the CPU are connected so they can perform the desired operation. If, for instance, an addition operation was requested, an arithmetic logic unit (ALU) will be connected to a set of inputs and a set of outputs. The inputs provide the numbers to be added, and the outputs will contain the final sum. The ALU contains the circuitry to perform simple arithmetic and logical operations on the inputs (like addition and bitwise operations). If the addition operation produces a result too large for the CPU to handle, an arithmetic overflow flag in a flags register may also be set .

The final step, writeback, simply "writes back" the results of the execute step to some form of memory. Very often the results are written to some internal CPU register for quick access by subsequent instructions. In other cases results may be written to slower, but cheaper and larger, main memory. Some types of instructions manipulate the program counter rather than directly produce result data. These are generally called "jumps" and facilitate behavior like loops, conditional program execution (through the use of a conditional jump), and functions in programs.^[5] Many instructions will also change the state of digits in a "flags" register. These flags can be used to influence how a program behaves, since they often indicate the outcome of various operations. For example, one type of "compare" instruction considers two values and sets a number in the flags register according to which one is greater. This flag could then be used by a later jump instruction to determine program flow.

After the execution of the instruction and writeback of the resulting data, the entire process repeats, with the next instruction cycle normally fetching the next-in-sequence instruction because of the incremented value in the program counter. If the completed instruction was a jump, the program counter will be modified to contain the address of the instruction that was jumped to, and program execution continues normally. In more complex CPUs than the one described here, multiple instructions can be fetched, decoded, and executed simultaneously. This section describes what is generally referred to as the "Classic RISC pipeline," which in fact is quite common among the simple CPUs used in many electronic devices (often called microcontroller). It largely ignores the important role of CPU cache, and therefore the access stage of the pipeline.

[edit] Design and implementation

Main article: CPU design

[edit] Integer range

The way a CPU represents numbers is a design choice that affects the most basic ways in which the device functions. Some early digital computers used an electrical model of the common decimal (base ten) numeral system to represent numbers internally. A few other computers have used more exotic numeral systems like ternary (base three). Nearly all modern CPUs represent numbers in binary form, with each digit being represented by some two-valued physical quantity such as a "high" or "low" voltage.^[6]

MOS 6502 microprocessor in a dual in-line package, an extremely popular 8-bit design.

Related to number representation is the size and precision of numbers that a CPU can represent. In the case of a binary CPU, a bit refers to one significant place in the numbers a CPU deals with. The number of bits (or numeral places) a CPU uses to represent numbers is often called "word size", "bit width", "data path width", or "integer precision" when dealing with strictly integer numbers (as opposed to floating point). This number differs between architectures, and often within different parts of the very same CPU. For example, an 8-bit CPU deals with a range of numbers that can be represented by eight binary digits (each digit having two possible values), that is, 2⁸ or 256 discrete numbers. In effect, integer size sets a hardware limit on the range of integers the software run by the CPU can utilize.^[7]

Integer range can also affect the number of locations in memory the CPU can address (locate). For example, if a binary CPU uses 32 bits to represent a memory address, and each memory address represents one octet (8 bits), the maximum quantity of memory that CPU can address is 2³² octets, or 4 GiB. This is a very simple view of CPU address space, and many designs use more complex addressing methods like paging in order to locate more memory than their integer range would allow with a flat address space.

Higher levels of integer range require more structures to deal with the additional digits, and therefore more complexity, size, power usage, and general expense. It is not at all uncommon, therefore, to see 4- or 8-bit microcontrollers used in modern applications, even though CPUs with much higher range (such as 16, 32, 64, even 128-bit) are available. The simpler microcontrollers are usually cheaper, use less power, and therefore dissipate less heat, all of which can be major design considerations for electronic devices. However, in higher-end applications, the benefits afforded by the extra range (most often the additional address space) are more significant and often affect design choices. To gain some of the advantages afforded by both lower and higher bit lengths, many CPUs are designed with different bit widths for different portions of the device. For example, the IBM System/370 used a CPU that was primarily 32 bit, but it used 128-bit precision inside its floating point units to facilitate greater accuracy and range in floating point numbers (Amdahl et al. 1964). Many later CPU designs use similar mixed bit width, especially when the processor is meant for general-purpose usage where a reasonable balance of integer and floating point capability is required.

[edit] Clock rate

Main article: Clock rate

Most CPUs, and indeed most sequential logic devices, are synchronous in nature.^[8] That is, they are designed and operate on assumptions about a synchronization signal. This signal, known as a clock signal, usually takes the form of a periodic square wave. By calculating the maximum time that electrical signals can move in various branches of a CPU's many circuits, the designers can select an appropriate period for the clock signal.

This period must be longer than the amount of time it takes for a signal to move, or propagate, in the worst-case scenario. In setting the clock period to a value well above the worst-case propagation delay, it is possible to design the entire CPU and the way it moves data around the "edges" of the rising and falling clock signal. This has the advantage of simplifying the CPU significantly, both from a design perspective and a component-count perspective. However, it also carries the disadvantage that the entire CPU must wait on its slowest elements, even though some portions of it are much faster. This limitation has largely been compensated for by various methods of increasing CPU parallelism (see below).

However architectural improvements alone do not solve all of the drawbacks of globally synchronous CPUs. For example, a clock signal is subject to the delays of any other electrical signal. Higher clock rates in increasingly complex CPUs make it more difficult to keep the clock signal in phase (synchronized) throughout the entire unit. This has led many modern CPUs to require multiple identical clock signals to be provided in order to avoid delaying a single signal significantly enough to cause the CPU to malfunction. Another major issue as clock rates increase dramatically is the amount of heat that is dissipated by the CPU. The constantly changing clock causes many components to switch regardless of whether they are being used at that time. In general, a component that is switching uses more energy than an element in a static state. Therefore, as clock rate increases, so does heat dissipation, causing the CPU to require more effective cooling solutions.

One method of dealing with the switching of unneeded components is called clock gating, which involves turning off the clock signal to unneeded components (effectively disabling them). However, this is often regarded as difficult to implement and therefore does not see common usage outside of very low-power designs.^[9] Another method of addressing some of the problems with a global clock signal is the removal of the clock signal altogether. While removing the global clock signal makes the design process considerably more complex in many ways, asynchronous (or clockless) designs carry marked advantages in power consumption and heat dissipation in comparison with similar synchronous designs. While somewhat uncommon, entire CPUs have been built without utilizing a global clock signal. Two notable examples of this are the ARM compliant AMULET and the MIPS R3000 compatible MiniMIPS. Rather than totally removing the clock signal, some CPU designs allow certain portions of the device to be asynchronous, such as using asynchronous ALUs in conjunction with superscalar pipelining to achieve some arithmetic performance gains. While it is not altogether clear whether totally asynchronous designs can perform at a comparable or better level than their synchronous counterparts, it is evident that they do at least excel in simpler math operations. This, combined with their excellent power consumption and heat dissipation properties, makes them very suitable for embedded computers (Garside et al. 1999).

CPU, core memory, and external bus interface of a DEC PDP-8/I. made of medium-scale integrated circuits

The design complexity of CPUs increased as various technologies facilitated building smaller and more reliable electronic devices. The first such improvement came with the advent of the transistor. Transistorized CPUs during the 1950s and 1960s no longer had to be built out of bulky, unreliable, and fragile switching elements like vacuum tubes and electrical relays. With this improvement more complex and reliable CPUs were built onto one or several printed circuit boards containing discrete (individual) components.

During this period, a method of manufacturing many transistors in a compact space gained popularity.The integrated circuit (IC) allowed a large number of transistors to be manufactured on a single semiconductor-based die, or "chip." At first only very basic non-specialized digital circuits such as NOR gates were miniaturized into ICs. CPUs based upon these "building block" ICs are generally referred to as "small-scale integration" (SSI) devices. SSI ICs, such as the ones used in the Apollo guidance computer, usually contained transistor counts numbering in multiples of ten. To build an entire CPU out of SSI ICs required thousands of individual chips, but still consumed much less space and power than earlier discrete transistor designs. As microelectronic technology advanced, an increasing number of transistors were placed on ICs, thus decreasing the quantity of individual ICs needed for a complete CPU. MSI and LSI (medium- and large-scale integration) ICs increased transistor counts to hundreds, and then thousands.

In 1964 IBM introduced its System/360 computer architecture which was used in a series of computers that could run the same programs with different speed and performance. This was significant at a time when most electronic computers were incompatible with one another, even those made by the same manufacturer. To facilitate this improvement, IBM utilized the concept of a microprogram (often called "microcode"), which still sees widespread usage in modern CPUs (Amdahl et al. 1964). The System/360 architecture was so popular that it dominated the mainframe computer market for the decades and left a legacy that is still continued by similar modern computers like the IBM zSeries. In the same year (1964), Digital Equipment Corporation (DEC) introduced another influential computer aimed at the scientific and research markets, the PDP-8. DEC would later introduce the extremely popular PDP-11 line that originally was built with SSI ICs but was eventually implemented with LSI components once these became practical. In stark contrast with its SSI and MSI predecessors, the first LSI implementation of the PDP-11 contained a CPU composed of only four LSI integrated circuits (Digital Equipment Corporation 1975).

Transistor-based computers had several distinct advantages over their predecessors. Aside from facilitating increased reliability and lower power consumption, transistors also allowed CPUs to operate at much higher speeds because of the short switching time of a transistor in comparison to a tube or relay. Thanks to both the increased reliability as well as the dramatically increased speed of the switching elements (which were almost exclusively transistors by this time), CPU clock rates in the tens of megahertz were obtained during this period. Additionally, while discrete transistor and IC CPUs were in heavy usage, new high-performance designs like SIMD (Single Instruction Multiple Data) vector processors began to appear. These early experimental designs later gave rise to the era of specialized supercomputers like those made by Cray Inc.

[edit] Microprocessors

Main article: Microprocessor

The integrated circuit from an Intel 8742, an 8-bit microcontroller that includes a CPU running at 12 MHz, 128 bytes of RAM, 2048 bytes of EPROM, and I/O in the same chip.

Intel 80486DX2 microprocessor in a ceramic PGA package.

The introduction of the microprocessor in the 1970s significantly affected the design and implementation of CPUs. Since the introduction of the first microprocessor (the Intel 4004) in 1970 and the first widely used microprocessor (the Intel 8080) in 1974, this class of CPUs has almost completely overtaken all other central processing unit implementation methods. Mainframe and minicomputer manufacturers of the time launched proprietary IC development programs to upgrade their older computer architectures, and eventually produced instruction set compatible microprocessors that were backward-compatible with their older hardware and software. Combined with the advent and eventual vast success of the now ubiquitous personal computer, the term "CPU" is now applied almost exclusively to microprocessors.

Previous generations of CPUs were implemented as discrete components and numerous small integrated circuits (ICs) on one or more circuit boards. Microprocessors, on the other hand, are CPUs manufactured on a very small number of ICs; usually just one. The overall smaller CPU size as a result of being implemented on a single die means faster switching time because of physical factors like decreased gate parasitic capacitance. This has allowed synchronous microprocessors to have clock rates ranging from tens of megahertz to several gigahertz. Additionally, as the ability to construct exceedingly small transistors on an IC has increased, the complexity and number of transistors in a single CPU has increased dramatically. This widely observed trend is described by Moore's law, which has proven to be a fairly accurate predictor of the growth of CPU (and other IC) complexity to date.

While the complexity, size, construction, and general form of CPUs have changed drastically over the past sixty years, it is notable that the basic design and function has not changed much at all. Almost all common CPUs today can be very accurately described as von Neumann stored-program machines. As the aforementioned Moore's law continues to hold true, concerns have arisen about the limits of integrated circuit transistor technology. Extreme miniaturization of electronic gates is causing the effects of phenomena like electromigration and subthreshold leakage to become much more significant. These newer concerns are among the many factors causing researchers to investigate new methods of computing such as the quantum computer, as well as to expand the usage of parallelism and other methods that extend the usefulness of the classical von Neumann model.

Die of an Intel 80486DX2 microprocessor (actual size: 12×6.75 mm) in its packaging.

A Central Processing Unit (CPU), or sometimes just called processor, is a description of a class of logic machines that can execute computer programs. This broad definition can easily be applied to many early computers that existed long before the term "CPU" ever came into widespread usage. The term itself and its initialism have been in use in the computer industry at least since the early 1960s (Weik 1961). The form, design and implementation of CPUs have changed dramatically since the earliest examples, but their fundamental operation has remained much the same.

Early CPUs were custom-designed as a part of a larger, sometimes one-of-a-kind, computer. However, this costly method of designing custom CPUs for a particular application has largely given way to the development of mass-produced processors that are suited for one or many purposes. This standardization trend generally began in the era of discrete transistor mainframes and minicomputers and has rapidly accelerated with the popularization of the integrated circuit (IC). The IC has allowed increasingly complex CPUs to be designed and manufactured to tolerances on the order of nanometers. Both the miniaturization and standardization of CPUs have increased the presence of these digital devices in modern life far beyond the limited application of dedicated computing machines. Modern microprocessors appear in everything from automobiles to cell phones to children's toys.

History of CPUs

Main article: History of general purpose CPUs

EDVAC, one of the first electronic stored program computers.

Prior to the advent of machines that resemble today's CPUs, computers such as the ENIAC had to be physically rewired in order to perform different tasks. These machines are often referred to as "fixed-program computers," since they had to be physically reconfigured in order to run a different program. Since the term "CPU" is generally defined as a software (computer program) execution device, the earliest devices that could rightly be called CPUs came with the advent of the stored-program computer.

The idea of a stored-program computer was already present during ENIAC's design, but was initially omitted so the machine could be finished sooner. On June 30, 1945, before ENIAC was even completed, mathematician John von Neumann distributed the paper entitled "First Draft of a Report on the EDVAC." It outlined the design of a stored-program computer that would eventually be completed in August 1949 (von Neumann 1945). EDVAC was designed to perform a certain number of instructions (or operations) of various types. These instructions could be combined to create useful programs for the EDVAC to run. Significantly, the programs written for EDVAC were stored in high-speed computer memory rather than specified by the physical wiring of the computer. This overcame a severe limitation of ENIAC, which was the large amount of time and effort it took to reconfigure the computer to perform a new task. With von Neumann's design, the program, or software, that EDVAC ran could be changed simply by changing the contents of the computer's memory. ^[1]

While von Neumann is most often credited with the design of the stored-program computer because of his design of EDVAC, others before him such as Konrad Zuse had suggested similar ideas. Additionally, the so-called Harvard architecture of the Harvard Mark I, which was completed before EDVAC, also utilized a stored-program design using punched paper tape rather than electronic memory. The key difference between the von Neumann and Harvard architectures is that the latter separates the storage and treatment of CPU instructions and data, while the former uses the same memory space for both. Most modern CPUs are primarily von Neumann in design, but elements of the Harvard architecture are commonly seen as well.

Being digital devices, all CPUs deal with discrete states and therefore require some kind of switching elements to differentiate between and change these states. Prior to commercial acceptance of the transistor, electrical relays and vacuum tubes (thermionic valves) were commonly used as switching elements. Although these had distinct speed advantages over earlier, purely mechanical designs, they were unreliable for various reasons. For example, building direct current sequential logic circuits out of relays requires additional hardware to cope with the problem of contact bounce. While vacuum tubes do not suffer from contact bounce, they must heat up before becoming fully operational and eventually stop functioning altogether.^[2] Usually, when a tube failed, the CPU would have to be diagnosed to locate the failing component so it could be replaced. Therefore, early electronic (vacuum tube based) computers were generally faster but less reliable than electromechanical (relay based) computers.

Tube computers like EDVAC tended to average eight hours between failures, whereas relay computers like the (slower, but earlier) Harvard Mark I failed very rarely (Weik 1961:238). In the end, tube based CPUs became dominant because the significant speed advantages afforded generally outweighed the reliability problems. Most of these early synchronous CPUs ran at low clock rates compared to modern microelectronic designs (see below for a discussion of clock rate). Clock signal frequencies ranging from 100 kHz to 4 MHz were very common at this time, limited largely by the speed of the switching devices they were built with.

Heap Tuning Parameters

Maximum heap size depends on maximum address space per process. The following table shows the maximum per-process address values for various platforms:

Table 4–1 Maximum Address Space Per Process

Operating System	Maximum Address Space Per Process
Redhat Linux 32 bit	2 GB
Redhat Linux 64 bit	3 GB
Windows 98/2000/NT/Me/XP	2 GB
Solaris x86 (32 bit)	4 GB
Solaris 32 bit	4 GB
Solaris 64 bit	Terabytes

Maximum heap space is always smaller than maximum address space per process, because the process also needs space for stack, libraries, and so on. To determine the maximum heap space that can be allocated, use a profiling tool to examine the way memory is used. Gauge the maximum stack space the process uses and the amount of memory taken up libraries and other memory structures. The difference between the maximum address space and the total of those values is the amount of memory that can be allocated to the heap.

You can improve performance by increasing your heap size or using a different garbage collector. In general, for long-running server applications, use the J2SE throughput collector on machines with multiple processors (-XX:+AggressiveHeap) and as large a heap as you can fit in the free memory of your machine.

Heap Tuning Parameters

You can control the heap size with the following JVM parameters:

• -Xmsvalue

• -Xmxvalue

• -XX:MinHeapFreeRatio=minimum

• -XX:MaxHeapFreeRatio=maximum

• -XX:NewRatio=ratio

• -XX:NewSize=size

• -XX:MaxNewSize=size

• -XX:+AggressiveHeap

-Xms3584m
 -Xmx3584m
 -verbose:gc
 -Dsun.rmi.dgc.client.gcInterval=3600000

start.sh:

classpath=/export/home/wl92user/system_test/lib/common-axis.jar:/export/home/wl92user/system_test/lib/common-characteristics.jar:/export/home/wl92user/system_test/lib/common-executors.jar:/export/home/wl92user/system_test/lib/common-functiontest.jar:/export/home/wl92user/system_test/lib/common-handlers.jar:/export/home/wl92user/system_test/lib/common-messages.jar:/export/home/wl92user/system_test/lib/common-misc.jar:/export/home/wl92user/system_test/lib/common-misc.jar:/export/home/wl92user/system_test/lib/common-network.jar:/export/home/wl92user/system_test/lib/common-systemtest.jar:/export/home/wl92user/system_test/lib/common-xmlbeans.jar:/export/home/wl92user/system_test/lib/commons-codec-1.3.jar:/export/home/wl92user/system_test/lib/commons-httpclient-3.1.jar:/export/home/wl92user/system_test/lib/commons-io-1.4.jar:/export/home/wl92user/system_test/lib/mlp-all-plugin.jar:/export/home/wl92user/system_test/lib/ntt.jar:/export/home/wl92user/system_test/lib/mlp_system_mlp320.jar
java -cp "$classpath" se.ericsson.st.testcases.BATReciver > console.log & echo $! > system_test_receiver.pid

stop.sh:

#!/bin/sh

if [ -f system_test_receiver.pid ]; then
    kill -9 `cat system_test_receiver.pid`
    rm system_test_receiver.pid
else
    echo "Receiver not started (cant find system_test_receiver.pid)"
fi

    以前一直想给自己写的一些程序加上GUI，不过直接用J2SE的API做GUI遇到复杂的效果很麻烦，而且比较丑陋，一直都没有想到什么好点子。最近无意中跟网友聊到这个，有人推荐用RCP（Rich Client Platform），就是使用ECLIPSE的包，来开发GUI，ECLIPSE里面的所有GUI效果都可以直接调用，很爽，呵呵。 只可惜相关的资料不多，或者有很多我不知道。在网友的帮助下，尝试做了一个简单的，效果不错，以后等有时间了，再详细研究。我们现在用的是爱立信自己做的一套ntt的测试框架来测试，如果有专门的人员来用RCP来做一套GUI，再配上ntt框架，没准可以做一套JAVA版本的loadrunner哦！！！ Eclipse界面的loadrunner，真的很期待啊！！！！

    再一个收获就是关于APACHE的MINA开源项目。以前的短信网关客户端程序，我都是自己用标准J2SE API来实现的，效果也还不错。也是跟一些网友聊到一些问题的时候，有网友就说为什么不试一试mina? 其实mina我很早以前就看过，当时mina还是1.*版本，研究以后发现，跟自己的需求还是相差比较远。交流一下才知道，原来mina已经有2.*版本了，不过还在开发过程中，没有稳定版。我马上去下载下来研究，发现真是不错，然后用mina的框架写了一个短信网关客户端的demo，效果确实不错。

    我以前设计通信程序分为2层， 一层是数据控制层，一层是业务控制层。 数据控制层 用来控制socket的连接和关闭（数据层会始终保持socket的连接），以及数据流的读写，把数据包转换成业务控制层所需要的业务对象。业务控制层，通过数据层得到业务对象，进行业务逻辑处理。mina 2.* 分层很细，最底层是I/O Service层，类似我的数据控制层，控制socket的连接和关闭等；第二层是I/O Fliter Chain,可以根据需要添加fliter 或者 encoder/decoder 或者 其他东东，功能异常强大，而且还无限扩展，第三层是I/O Handler，其中包含一个I/O Session（这个类似SOCKET的句柄）的事件接口，通过底层出发各种事件，来实现复杂的业务逻辑。这样省去了我们不少麻烦，特别是对线程的控制，mina的底层都自动实现了，很好，很强大。APACHE的官方网站上面说，这个东东都快赶上C/C++做的socket程序了，我是强烈推荐大家使用的，同时也非常期待2.*的正式版出现。

   最近还发现一个好东东，就是jpcap。由于一直做电信行业，经常需要使用wireshark来抓包，总在想能不能用java实现类似功能呢？有人就告诉我，用jpcap!其实jpcap就是使用jni，来调用pcap的库，来实现这种功能的。我试了一下，还真不错， 唯一麻烦的就是要先安装PCAP的包。基本上通过jpcap能解决大部分的通信协议问题，不过使用jni会有1ms左右的延时，这一点还是要注意的。目前正在研究中，看具体能用jpcap做点什么有意思的东东（Java版本的wireshark? 貌似意义不大）。对了，jpcap里面不光有java代码，还有C的代码，幸好我早些时候复习了一下C，把C的内容基本上都拣起来了（总算大学没白读，唉），这时候正好看看。

   今天到此为止，现在去跑步，锻炼身体，就不在多写了。 咱们做程序的，每天都是坐N长时间，还要对着PC，平时还是要多运动，加强锻炼，走可持续发展的道路，呵呵。

    因为系统的功能测试基本上已经完成，现在主要做系统测试，也就是把那些功能测试的case合起来跑，多线程大压力的并发，然后挂几天，看看系统死不死。不用说大家都猜到了，不死才怪！出了问题，就要找问题，然后解决，接下来再发新版本，再测。。。 测试跟开发一样，是个迭代的过程。在测试爱立信项目和产品的同时， 我想到了自己以前做的一些程序，就想用类似的测试方法来测一下自己以前做的东西。尝试做了一下，发现了不少问题。比如，以前做的一个短信网关客户端程序， 短信包的包头是定长而包体是变长的，包体的大小，在包头内有描述，所以 我就在程序里面先读取包头，再动态去分配内存空间去存放包体。当压力小的时候还好，把压力加很大的时候，JVM来不及回收包体动态分配的heap内存，很快就会oom。 有人可能会说一开始把内存分配好，不过java 的nio好像没有提供从socket中读取指定大小字节的API，旧的IO有。或者 还有解决方法是，一次读取全部的数据包，然后进行分析，把多余的字节跟下一个数据包合并之类,等等。如果java有类似C语言的指针，这个问题就不是问题了，哈哈。这里就不详细讨论这个问题了，反正是解决了，呵呵。我这里要表达的意思是，测试还是很重要的，特别是大压力的并发测试，很容易发现一些代码的BUG。IBM 上有一篇文章，关于Java 基准测试，讲的不错：http://www.ibm.com/developerworks/cn/java/j-benchmark1.html?S_TACT=105AGX52&S_CMP=tec-csdn。 同样的代码，在不同环境下的运行效果也是千差万别。由此我想到去年做的SOA项目，运行环境很复杂，而且系统耦合环节很多，测试找BUG实在不容易。 我当时主要做的是持久层EJB3那一块，幸好当时leader要求的是分层测试，先针对所有ENTITY测试，然后放在容器内部测试基本的方法，最后再测业务层，即使是这样，还是有不少问题，但是这样的做法是相当好的，值得称赞。 有很多使用持久层框架的项目，直接生成DAO对象，然后就开始写，根本不对基本的DAO进行测试，而是直接测试业务层， 这未免对那些自动生成的代码太有信心了。往往都是业务层发现问题，再反过来找DAO有那些问题。其实自动生成的这些代码，还是有不少问题的，比如 最终生成的SQL有可能无法利用创建的数据库索引 之类的问题。

   再来说说测试的一些工具，loadrunner 之类的工具，想想很多人都很熟，基本上就是做好测试脚本挂着跑就OK。但是 难在根据生成的报表来看问题在哪里，就比较麻烦了。所以，我们有时候拿Jprofile之类的工具，来做一下内存和CPU的监控，看看问题具体在哪里。但是 这样也有一些问题，就是Jprofile这些工具往往对系统有影响，不能长时间监控，否则影响系统性能。还有，有些系统已经是on site的，都不会让你轻易操作的，一点办法都没有。有的时候，还真要动动脑筋才行。不过相对于WINDOWS系统，linux或者unix还相对容易调试一点，可以用jstack或者jmap/jstat/jps来看看。在linux或者unix下，程序挂了，还有core文件，可以看看，例如：/usr/lib/jvm/java-6-sun-1.6.0.03/bin/jstack /usr/lib/jvm/java-6-sun-1.6.0.03/bin/java core.5216  > jstack-5216.txt 和/usr/lib/jvm/java-6-sun-1.6.0.03/bin/jmap -histo /usr/lib/jvm/java-6-sun-1.6.0.03/bin/java core.5216  > jmap-histo-5216.txt。

   虽说测试很重要，但是在国内这种氛围，对测试并不是很重视。国内重视的是开发效率，越快干完越好，不求精。其实说白了，主要是一个成本问题，没人又没钱。开发都没人月，还要给你几倍于开发的人月去做测试？ 白日做梦。。。但是咱们还是要重视测试这个环节，有总比没有好。

   总而言之，今年做测试让我收获不小，学到不少东西，能够看到开发角度看不到的。我想再干2年基层工作也该转型了，我又不能喝酒又不能抽烟，吹水也不咋的，做市场是没机会了，看以后能不能往项目管理方向发展，希望通过做一段时间的测试工作，来积累一些经验。 下一步，估计 要学怎么做项目管理了，学习怎么做需求，怎么做概要设计，怎么计算人月等等，要走的路还很长啊！！！ 要是能参加相关培训就好了，可是我是不会自己掏钱去学的，公司要是愿意出钱就好了。不过目前我最想参加的培训是oracle数据库培训和linux系统开发和管理培训，可惜咱既没钱又没机会，惨。。。谁能比我惨啊。。。。

    现在写了不少了，还没写完，就新建一篇再写吧，下一篇写点最近技术上的收获，待续。。。。

1 首先创建一个简单的java类：

public class Hello
{
 static
 {
  try
  {
//此处即为本地方法所在链接库名
   System.loadLibrary("hello");
  }
  catch(UnsatisfiedLinkError e)
  {
   System.err.println( "Cannot load hello library:\n " +
                                e.toString() );
  }
 }
 public Hello()
 {
 }
//声明的本地方法
  public native void SayHello(String strName);
}

这里有个地方要注意，就是 这个类最好不要加包信息。因为类在某个包下面，使用javah命令生成*.h头文件的时候会不一样，比如在test包下，就会生成test_Hello.h，而且 在jni调用的时候，也有区别，为了方便起见，我们这里就不加包了，免得麻烦，：）

然后，编译得到Hello.class

2 生成 Hello.h

  使用命令：javah Hello

  这里有一点要注意，如果这个命令报错，有可能是因为你没有当前路径到设置环境变量classpath中，所以：

  javah -classpath"." Hello.class

  这样写就OK了， 后面也许还会碰到类似的环境变量问题。

3 在与Hello.h相同的路径下创建一个CPP文件Hello.cpp。内容如下：

#include "Hello.h"
JNIEXPORT void JNICALL Java_Hello_SayHello  (JNIEnv * env, jobject arg, jstring instring)
{
    const char *str = env->GetStringUTFChars( instring, JNI_FALSE );
    printf("Hello,%s\n",str);
    env->ReleaseStringUTFChars( instring, str );
    return;
}

这个Hello.cpp 的代码，跟IBM的例子略有不同，详细原因 大家自己去查查jni.h

4．编译生成共享库

a. 编译命令，生成Hello.o

g++ -I /usr/lib/jvm/java-6-sun-1.6.0.03/include -I /usr/lib/jvm/java-6-sun-1.6.0.03/include/linux -fPIC -c Hello.cpp

b.生成动态库文件，libhello.so.1.0

g++ -shared -Wl,-soname,libhello.so.1 -o libhello.so.1.0 Hello.o

这里的2个命令也跟IBM文章的例子有所不同。因为使用gcc编译得到动态库，在jni调用的时候，某些情况会有异常,所以这里改用g++。

接下来将生成的共享库拷贝为标准文件名
cp libhello.so.1.0 libhello.so 
最后通知动态链接程序此共享文件的路径。
export LD_LIBRARY_PATH='pwd':$LD_LIBRARY_PATH 
 
这里用export 加入共享文件的路径，有时候会有点问题，比如：环境变量不会马上更新等等。
还有一个办法，就是直接将libhello.so拷贝到 /usr/lib 或者/lib 等系统库目录下
 
 
5．编写一个简单的Java程序来测试我们的本地方法。
将如下源码存为ToSay.java：
import Hello;
import java.util.*;
public class ToSay
{
	public static void main(String argv[])
	{
		ToSay say = new ToSay();
	}
	public ToSay()
	{
		Hello h = new Hello();
		//调用本地方法向John问好
		h.SayHello("John");			
	}
}
用javac编译ToSay.java，生成ToSay.class 
向执行普通Java程序一样使用java ToSay，我们会看到在屏幕上出现Hello,John。
 
6 以下是IBM的文章中的建议：
应用中注意事项
1． 如果可以通过TCP/IP实现Java代码与本地C/C++代码的交互工作，那么最好不使用以上提到的JNI的方式，因为一次JNI调用非常耗时，大概要花0.5～1个毫秒。
2． 在一个Applet应用中，不要使用JNI。因为在 applet 中可能引发安全异常。
3． 将所有本地方法都封装在单个类中，这个类调用单个 DLL。对于每种目标操作系统，都可以用特定于适当平台的版本替换这个 DLL。这样就可以将本地代码的影响减至最小，并有助于将以后所需的移植问题包含在内。
4． 本地方法要简单。尽量将生成的DLL 对任何第三方运行时 DLL 的依赖减到最小。使本地方法尽量独立，以将加载DLL 和应用程序所需的开销减到最小。如果必须要运行时 DLL，则应随应用程序一起提供它们。
5． 本地代码运行时，没有有效地防数组越界错误、错误指针引用带来的间接错误等。所以必须保证保证本地代码的稳定性，因为，丝毫的错误都可能导致Java虚拟机崩溃。
 
 
7 思考的问题
我以前一直在想，如果我使用JNI来调用C/C++实现的socket通信库，会不会比java自己的nio性能要好？
貌似IBM的兄弟的回答是否定的。
 
也有人不同意这个意见，说因为Java代码与本地C/C++代码的交互工作不是那么频繁，即使浪费0.5～1个毫秒，也没什么关系。
貌似BEA的weblogic(weblogic 9以后的版本)就采用这个做法。
 
以后有机会我就来做个试验，测试一下，呵呵。
当然，有兄弟已经测试过了，来告诉我，就最好啦，哈哈！！！
 

java -verbose:class Main 显示调用的详细信息

classloader的两种载入方式:1)pre-loading预先载入,载入基础类 2)load-on-demand按需求载入
只有实例化一个类才会被classloader载入,仅仅申明并不会载入

java动态载入class的两种方式:
1)implicit隐式,即利用实例化才载入的特性来动态载入class
2)explicit显式方式,又分两种方式:
1)java.lang.Class的forName()方法
2)java.lang.ClassLoader的loadClass()方法

static块在什么时候执行?
1)当调用forName(String)载入class时执行,如果调用ClassLoader.loadClass并不会执行.forName(String,false,ClassLoader)时也不会执行.
2)如果载入Class时没有执行static块则在第一次实例化时执行.比如new ,Class.newInstance()操作
3)static块仅执行一次

Class类的实例.
>>Class类无法手工实例化,当载入任意类的时候自动创建一个该类对应的Class的实例,
>>某个类的所有实例内部都有一个栏位记录着该类对应的Class的实例的位置.,
>>每个java类对应的Class实例可以当作是类在内存中的代理人.所以当要获得类的信息(如有哪些类变量,有哪些方法)时,都可以让类对应的Class的实例代劳.java的Reflection机制就大量的使用这种方法来实现
>>每个java类都是由某个classLoader(ClassLoader的实例)来载入的,因此Class类别的实例中都会有栏位记录他的ClassLoader的实例,如果该栏位为null,则表示该类别是由bootstrap loader载入的(也称root laoder),bootstrap loader不是java所写成,所以没有实例.

原生方法:forName0()等方法,native修饰符

自定义ClassLoader:
如实例化一个URLClassLoader. URLClassLoader ucl = new URLClassLoader(new URL[]{new URL("file:/e:/bin/")}),URLClassLoader优先找当前目录,再在url中找.class加载.URL中别忘在最后加"/"表示目录

各个java类由哪些classLoader加载?
1)java类可以通过实例.getClass.getClassLoader()得知
2)接口由AppClassLoader(System ClassLoader,可以由ClassLoader.getSystemClassLoader()获得实例)载入
3)ClassLoader类由bootstrap loader载入

ClassLoader hierachy:
jvm建立->初始化动作->产生第一个ClassLoader,即bootstrap loader->bootstrap loader在sum.misc.Launcher类里面的ExtClassLoader,并设定其Parent为null->bootstrap loader载入sun.misc.Launcher$AppClassLoader,并设定其parent为ExtClassLoader(但是AppClassLoader也是由bootstrap loader所载入的)->AppClassLoader载入各个xx.class,xx.class也有可能被ExtclassLoader或者bootstrap loader载入.
>>自定义的ClassLoader的.getParent()是AppClassLoader.parent和他的加载器并没有关系
>>ExtClassLoader和AppClassLoader都是URLClassLoader的子类.AppClassLoader的URL是由系统参数java.class.path取出的字符串决定,而java.class.path由 运行java.exe时 的-cp或-classpath或CLASSPATH环境变量决定
>>ExtClassLoader查找的url是系统变量java.ext.dirs,java.ext.dirs默认为jdk\jre\lib\ext
>>Bootstrap loader的查找url是sun.boot.class.path
>>在程序运行后调用System.setProperty()来改变系统变量并不能改变以上加载的路径,因为classloader读取在System.setProperty之前.sun.boot.class.path是在程序中写死的,完全不能修改

委派模型
当classloader有类需要载入时先让其parent搜寻其搜寻路径帮忙载入,如果parent找不到,在由自己搜寻自己的搜寻路径载入,ClassLoader hierachy本来就有这种性质

NoClassDefFoundError和ClassNotFoundException
NoClassDefFoundError:当java源文件已编译成.class文件,但是ClassLoader在运行期间在其搜寻路径load某个类时,没有找到.class文件则报这个错
ClassNotFoundException:试图通过一个String变量来创建一个Class类时不成功则抛出这个异常