The transfer of data within the microprocessor and between the microprocessor and memory must be synchronized to ensure that the data needed to execute each instruction is available when the flow of execution has reached an appro- priate point. This synchronization is accomplished by mov- ing data in intervals that correspond to the pulses of the system clock (a quartz crystal). This is done by sending control signals that tell the components of the processor and memory when to send or wait for data. Thus, if the microprocessor is the heart of the computer, the clock is the heart’s pacemaker. Because most devices cannot run at the same pace as the processor, circuits in various parts of the motherboard create secondary control signals that run at various ratios of the actual system clock speed.
The following table shows the speed of various system components in relation to the system clock rate. Although the example uses a 600-mHz clock, the ratios will generally hold for faster processors.
d
evices
peedr
elatioNshipProcessor 600 System bus * 4.5 System
(Memory) Bus 133 (depends on multiplier) Level 2 Cache 300 Processor / 2
AGP 66 System bus / 2 PCI bus 33 System bus / 4
microprocessors are rated according to the frequency (that is, number of pulses per second) of their associated clock. For example, a 1.2-gHz Pentium IV processor has 1.2 billion (giga-) pulses per second. It follows that all other things being equal, the higher a processor’s clock frequency, the more instructions it can process per second. An alterna- tive way to rate processors is according to the number of a standard type of instruction that it can process per second, hence mIPS (millions of instructions per second).
The relationship between clock speed and processor performance is not as simple as the preceding might imply, however. Each processor is designed with circuits that can move data at a certain rate. In some cases a processor can be run at a higher clock rate than specified (this is called overclocking), but then reliability comes into question. Also, the actual processing power of a processor depends on many other factors. If a processor implements instruc- tions in its microcode that are more efficient for handling certain operations (such as floating point math or graphics rendering), applications that depend on these operations may run faster on one processor than on another, even if the two processors run at the same clock speed. The speed of the system bus (which connects the processor to the RAm memory) also affects the speed at which data can be fetched, processed, and stored. A processor with a clock speed of 733 mHz should perform better on a motherboard
with a bus speed of 133 mHz than on one with a bus speed of only 100 mHz.
Speed is “sexy” in marketing terms, so the major chip manufacturers always tout their fastest chips. However, the difference in speed between, for example, a 2.2-gHz version of a processor and a 2.0-gHz version may be unnoticeable to the user of all but the most processor-intensive applica- tions (such as image processing). Indeed, if the system with the slower chip has a faster bus, faster memory (such as RDRAm), or a larger processor cache (see cache) it may well outperform the one with a faster chip.
Another reason for caution in interpreting clock speed is that many recent PCs have two or even four proces- sors (see multipRocessing). Performance in such systems is likely to depend at least as much on optimization of the operating system and applications as on any multiple of raw clock speed. This trend to multicore CPUs is also seen as an alternative to any substantial increase in processor speed, because higher speeds bring increasing concerns about heat and power usage.
In PCs the term “clock” can also refer to the battery-pow- ered “real-time” clock that provides a timing interval that can be accessed by the operating system and applications. Further Reading
Clock speed resources. TechRepublic. Available online. URL: http://search.techrepublic.com.com/search/clock+speed. html?t=11& s=0&o=0. Accessed June 6, 2007.
“Understanding System memory and CPU Speeds.” Available online. URL: http://www.directron.com/fsbguide.html. Accessed June 6, 2007.
“What Is CPU Overclocking?” Available online. URL: http://www. webopedia.com/DidYouKnow/Computer_Science/2005/over clocking.asp. Accessed June 6, 2007.
COBOL
Common Business-Oriented Language was developed under the impetus of a 1959 Department of Defense initiative to create a common language for developing business applica- tions that centered on the processing of data from files. (The military, after all, was a “business” whose inventory control and accounting needs dwarfed those of all but the largest corporations.) At the time, the principal business-oriented language for mainframe computers was FLOW-mATIC, a language developed by grace Hopper’s team at Remington- Rand UNIVAC and limited to that company’s computers (see hoppeR, gRace muRRay). The first COBOL compil- ers became available in 1960, and the American National Standards Institute (ANSI) issued a standard specification for the language in 1968. Expanded standards were issued in 1974 and 1985 (COBOL-74 and COBOL-85) with a new standard issued in 2002.
The committee that outlined the language that would become COBOL focused on making program statements resemble declarative English sentences rather than the mathematical expressions used by FORTRAN for scientific programming. COBOL’s designers hoped that accountants, managers, and other business professionals could quickly master the language, reducing if not removing the need for 0 clock speed
professional programmers. (This theme of “programming without programmers” would recur with regard to other languages such as RPg, BASIC, and various database sys- tems, always with limited success.)
P
rograms
tructureA COBOL program as a whole resembles a business form in that it is divided into specific sections called divisions, each with required and optional items.
The Identification division simply identifies the pro- grammer and gives some information about the program:
IDENTIFICATION DIVISION. PROGRAM-ID WEEKLY REPORT. AUTHOR JAMES BRADLEY.
DATE-WRITTEN DECEMBER 10, 2000. DATE-COMPILED DECEMBER 12, 2000. REMARKS THIS IS AN EXAMPLE PROGRAM.
The Environment division contains specifications about the environment (hardware) for which the program will be compiled. In some cases (for example, microcomputer versions of COBOL) it may not be needed. In other cases, it might simply have a Configuration section that specifies the machine to be used:
ENVIRONMENT DIVISION. CONFIGURATION SECTION. SOURCE-COMPUTER IBM-370. OBJECT-COMPUTER IBM-370.
(The reason for the separate source and object computers is that programs were sometimes compiled on one computer for use on another, often smaller, one.)
In some cases, the Environment Division must also include an Input-Output section that specifies devices and files that will be used by the program. For example:
INPUT-OUTPUT SECTION. FILE-CONTROL.
SELECT STUDENT-FILE ASSIGN TO READER SELECT STUDENT-LISTING ASSIGN TO LOCAL- PRINTER
The Data division gives a description of the data records and other items that will be processed by the program. It is roughly comparable to the declarations of variables in languages such as Pascal, C, or BASIC. Since COBOL focuses on the processing of file records and the format- ting of reports, it tends to have fewer data types than many other languages, but it makes it easier to describe the kinds of data structures commonly used in business applications. For example, it is easy to describe records that have fields and subfields by using level numbers to indicate the rela- tionship:
DATA DIVISION. FILE SECTION. FD INFILE
LABEL RECORDS ARE OMITTED.
01 STUDENT-DATA. 02 STUDENT-ID PIC 999999. 02 STUDENT-NAME. 03 LAST-NAME PIC X(15). 03 INITIAL PIC X. 03 FIRST-NAME PIC X(10). 02 GPA PIC 9.99
The “PIC” or picture clause specifies the type of data (using 9’s and a decimal point for numbers and x for text) and the length. In addition to specifying the input records, the Data division often includes items that specify the for- mat of the lines of output that are to be printed.
The Procedure division provides the statements that perform the actual data manipulation. Procedures can be organized as subroutines (roughly equivalent to procedures or functions on other languages). Some sample procedure statements are:
READ STUDENT-DATA INTO STUDENT-WORK-RECORD AT END MOVE ‘E’ TO PROC-FLAG-ST
GO TO EXIT-PRINT
ADD 1 TO TOTAL-STUDENT-RECORDS
mathematical expressions can be computed using a Compute statement:
COMPUTE GPA = TOTAL-GRADES / CLASSES
Branching (if) statements are available, and looping is provided by the Perform statement, for example:
PERFORM 100-PRINT-LINE
UNTIL LINES-FL IS EQUAL TO ‘E’
(As with older versions of BASIC, subroutines are numbered.)
i
mPactandP
rosPectsFrom the 1960s through the 1980s, COBOL became the workhorse language for business applications for main- frame and mid-size computers, and it is still widely used today. (The concerns about possible problems at the end of the century often involved older programs written in COBOL, see y2kpRoblem.) The main line of programming language evolution bypassed COBOL and went through Algol (a contemporary of COBOL) and on into Pascal, C, and other block-structured languages (see also stRuctuRed pRogRamming).
Some modern versions of COBOL have incorporated later developments in structured programming (such as modularization) and even object-oriented design. COBOL has also shown considerable versatility in accommodating modern development frameworks, including microsoft.NET as well as processing now-ubiquitous xmL data. Neverthe- less, usage of COBOL continues to decline slowly as devel- opers increasingly turn to languages such as C++, scripting languages, or database development systems.
Further Reading
Bivar de Oliveria, Rui. The Power of COBOL: For Systems Developers of the 21st Century. Charleston, S.C.: BookSurge, 2006. COBOL Portal. Available online. URL: http://www.cobolportal.
com. Accessed June 8, 2007.
murcah, mike, Anne Prince, and Raul menendez. Murach’s Main- frame COBOL. Fresno, Calif.: murach and Associates, 2004. Sammet, J. E. “The Early History of COBOL,” in History of Pro-
gramming Languages. Wexelblat, R. L., ed., 199–276. New York: Academic Press, 1985.
codec
Short for “coder/decoder,” a codec is essentially an algo- rithm for encoding (and compressing) a stream of data for transmission, and then decoding and decompressing it at the receiving end. Usually the data involved represents audio or video content (see stReaming). Typically the data is being downloaded from a Web site to be played on a personal computer or portable player (see multimedia and
musicandvideoplayeRs, digital).
A codec is described as “lossy” if some of the origi- nal information is lost in the compression process. It then becomes a question of whether the loss in quality is per- ceived by the user as significant. A codec that preserves all the information needed to re-create the original file is “loss- less.” For most purposes, the much greater size of the loss- less version of a file is not worth the (often imperceptible) increase in quality or fidelity.
A codec is usually used in connection with a “container format” that specifies how the encoded data is to be stored
in a file. Often a container can hold more than one data stream and even more than one kind of media (such as video and audio). When one refers to a Windows WAV file, for example, one is actually referring to a container.
most of the popular codecs and file formats are propri- etary, which creates something of a dilemma for users who prefer open-source solutions. However, while most Linux distributions do not include support for formats such as mP3 out of the box, distributions such as Ubuntu are now making it easier for users to choose nonsupported propri- etary codecs if desired.
The preceding table lists some codecs likely to be encountered by program developers and consumers. Further Reading
Audio Files. Available online. URL: http://www.fileinfo.net/ filetypes/audio. Accessed September 3, 2007.
Harte, Lawrence. Introduction to MPEG. Fuquay Varina, N.C.: Althos Publishing, 2006.
Rathbone, Andy. MP3 for Dummies. 2nd ed. New York: Hungry minds, 2001.
Richardson, Iain E. g. Video Codec Design: Developing Image and Video Compression Systems. New York: Wiley, 2002.
Roberts-Breslin, Jan. Making Media: Foundations of Sound and Image Production. Boston: Focal Press, 2003.
Thurott, Paul. PC Magazine Windows XP Digital Media Solutions.
Indianapolis: Wiley, 2005.
Video Files. Available online. URL: http://www.fileinfo.net/ filetypes/video. Accessed September 3. 2007.