Concepts:This chapter begins with discussion of the system bus and several other buses that connect to it. In chapter 2, we discussed the system bus briefly: The system bus is usually a set of copper paths in a motherboard that allows data to flow from one device to another inside the computer. As the text should explain, we pass one bit at a time along each wire or path in the bus to and from the CPU, hard drives, memory, and other internal devices. The number of wires determines the width of the system bus, which determines how much data we can feed each device at once. This chapter introduces more buses, so we should look at some of their features:
The link above provides more information about the evolution of system buses over time. It mentions that the general design has changed from parallel data lines to serial data lines. The serial data line design sends only one bit at a time, but transmission speed has increased, making that design more efficient. As the text explains, data transmission rates have been increased in the past by increasing the number of data lines used in parallel. The increases in data transmission rates that we find on current serial data transmission systems can be credited to increases in the clock rate of the system. On page 199, the text discusses the set of rules used for transmitting bits along a but, the bus protocol. It mentions that there have been different protocols from different manufacturers. We are told that the traditional methods use the CPU as a bus master, the traffic coordinator for the transmission of data across the bus. These methods tie up the CPU when it is performing this function. A method that transfers some of this duty to other devices is the direct memory access (DMA) method. A DMA controller can take over some of the bus master duties with regard to the data that flows into and out of primary storage. The text also mentions a few other buses that can be found in more recent computer systems:
The text briefly discusses I/O ports, which it explains as being two things. They are data paths from the CPU to devices, and they are also logical concepts.
An I/O port can also be called an I/O address, which makes it clearer
that it can be implemented as a portion of primary memory that acts
like a mail drop, a place
where the CPU and the device in question can exchange messages with
each other. The text tells us that the I/O port can be called a logical
abstraction, by which the text means that we can treat the port like a
physical device as far as the operating system is concerned On page 207, we are told that storage devices and I/O devices are typically connected to a system bus with a device controller, which we can think of as an adapter between the device and the system. The device controller acts like a device driver, which is a software implementation of a similar idea. They both serve as an interface between part of the system and the device in question. The text turns to the concept of interrupts.
We are told again about wait states, and are supposed to be amazed by
the number of wait states that might take place between a request for
data and the return of that data across a slow data bus from an even
slower device. The text explains that the CPU can't wait around for
that data dump to take place: it has other business to take care of.
So, someone invented the interrupt, an electrical path assigned to a
device
that allows the device to signal the CPU, requesting the CPU's
immediate attention. In the article that I have provided a link to in
this paragraph, you will see that there are hardware and software interrupts. This discussion is about interrupt requests generated by hardware. The CPU watches for interrupt requests. It stores such requests as numbers in an interrupt register. As the text explains on page 210,
the CPU interrupts processing when there is a code in the interrupt
register, empties the register, and passes control of the computer to
an interrupt handler that
matches the code of the requested interrupt. An interrupt handler is
typically part of the operating system, but larger programs can include
code to handle anticipated interrupts as well. When an interrupt is
handled by the operating system, the procedure matches the text. On page 211, the text explains that some interrupts have
higher priorities than others, which is why they are numbered. For more
details, look at this short set of slides
from a University of Toronto lecturer about interrupts. At the bottom
of page 211, the text discusses another aspect of having to process an
interrupt. As you know, the CPU loads instructions, variables, and more
in its registers as it prepares to execute them. It does the same with
interrupts. The question that should arise is how does the CPU resume
its processing once the interrupt has been handled? When the CPU
prepares to process the interrupt, it copies everything in its
registers to a memory area called the stack.
This is a holding area for the data that the CPU will need to continue
from the point of interruption once it is ready to do so. Copying the
registers to the stack is called a push, copying the information from the stack back to the registers is called a pop. On page 213, the text describes a buffer as a small amount of memory that usually holds data being transferred from one location to another. Buffers are often set up for network cards, to hold data received from or being sent to a network device. The buffer exists because the data can't be sent across the network in the same way that was prepared by the application that created it. In the example on page 214, a print job is being sent from an application across a network to a printer. The network transmission is sent one bit at a time, but the bits are stored in a buffer by the receiving device until they can be assembled as a full page of data, which is what the printing process requires. As the text notes, this process will fail if the size of the buffer is not large enough to hold the necessary clump of data for the intended process. When a buffer is too small for its job, the system still tries to load it with the available data, causing a buffer overflow. On page 217, the text defines a cache (pronounce like cash) as an area of memory that is used to improve system performance. This sounds like a buffer, but the text tells us there are several differences:
The text provides an example of using a cache to speed up writing data to a hard drive, and another example of speeding up reading
data from a hard drive. In both cases, the data in question is held in
a cache to reduce the number of times it is necessary to access the
storage device. Both of these examples depict the use of secondary storage cache, as discussed on page 220. You should also read about primary storage cache, discussed on page 219, which uses caches for data that the processor is expected to need quickly or often. On page 220, the text describes applications that will not run will unless they are run on computers that have multiple processors. Page 221 shows us an image of a processor that actually contains six cores, which are each processors in their own right, and cache memory that can be used by those six cores. Placing multiple cores on the architecture of a single processor is a newer way of providing more processing power to a computer than providing a means to install multiple processors on the motherboard of a single computer, described on page 223. As the text explains, this method is more often found in midrange (and higher) class computers. The text also repeats its earlier observations about using clusters of computers to achieve greater processing power of a high end application. The chapter ends with a discussion about data compression,
storing a given amount of data in less space than it would normally
take by processing the files holding that data and storing them in
special formats. Often, the data files are converted to a compressed
form with a program that uses a compression algorithm, and they often must be converted back to normal form with a program that uses a matching decompression algorithm.
The text remarks that this decompression process may only convert the
data to a "near original" state, because some compression algorithms
are considered lossy and others are considered lossless. Lossy compression methods eliminate some data from the resulting files. The amount of data lost must be weighed against the improvement in file size. For example, converting a photographic file from a JPG format, which already has some compression in it, to a PNG format will generally produce a much smaller file, but it will remove a lot of the detail that the original photo contained. Lossless compression methods do not generally compress files as much as lossy methods, but as you might guess, lossless methods retain more fidelity to the original data file than the lossy methods can. Compression can be used with many kinds of special files,
music and video files among them, as well as with more common file
types.
|