Several years ago I wrote an article on the use of analogies in teaching computer architecture because one of the greatest difficulties faced by any teacher is getting over basic concepts to students who sometimes don’t have an intuitive feel for the subject.
Use of Analogies in Teaching Computer Architecture
Academics want their students to do well and are continually searching for more effective ways of teaching. In particular, they seek tools that convey key concepts to students. One tool that can be used to introduce new ideas is the analogy that compares the new concept with something that a student already understands; for example, the cache memory might be compared to the notebook that is already familiar to the student.
This paper examines the use of analogy in the teaching of computer architecture by means of case studies. We discuss the nature of the analogy and its strengths and weaknesses – a poor analogy may do more harm than good by inviting the student to draw misleading and erroneous comparisons between the concept being taught and the analogy.
Some of the analogies are very effective and offer remarkable parallels with the concept being described, such as the use of ice on a frozen pond to model data storage.
The paper looks at analogies in architecturally-
In this paper, I discuss the use of analogies as a teaching aid in my own subject area, computer architecture. Of course, the use of analogies is commonplace; for example, it seems that almost everyone introduces a program by means of an analogy with a recipe in a cookbook. Sometimes, however, the analogy is not entirely helpful; we speak of burning a CD because of the analogy between use of a laser as a heating tool and the use of a laser in writing to a CD – even though this analogy is not appropriate and can be misleading.
Before we look at the analogies themselves, we need to mention two aspects of education; the student and the nature of education itself.
Politicians, the press, and even academics often speak of the student as if there
were a single, well-
This observation was brought home to me shortly after I started teaching. I had a class of students of unusually poor ability. I went to the head of department and told him that I had a dilemma and the course was not progressing well. I explained that if I teach the students at the level appropriate to the course, then few students would pass the exam and the class would gain very little. On the other hand, if I taught the students at a level at which they can participate, then I will be failing the university by not maintaining academic standards. My head of department told me that my job was to educate students and (in this case) attempting to maintain standards for the sake of it would benefit no one.
The above remarks are made in the context of the UK higher education system where
an attempt is made to maintain academic standards across the entire higher education
system by means of external examiners. The course, exam papers, and standards of
marking at each and every university are checked by professors (so-
I teach at a university in an industrial area – a region that would be called the
rust belt in the USA. Most of my students are from the local area and are often the
first generation from their family entering higher education. They frequently have
little idea of what is expected of them and may have low motivation (especially in
my subject where the expectation of a well-
Moreover, I teach computer hardware and architecture at various levels from freshman to senior. This is one of the least popular core subjects because many students perceive it as an unnecessary hurdle on the way to their goal.
My teaching career has, to a great extent, been a continuous search to become a more effective teacher. In the 1970s I wrote a book, an introduction to computer hardware that was intended to help the type of students I taught to understand the subject . Reviews were positive and it was published. However, one reviewer stated that he did not see the point of a book that spent several hundred pages dealing with computer hardware – surely the subject could be reduced to a few equations and general principles, and the students could take if from there. Clearly, the reviewer was living in a very different world to the one I inhabited.
Of course, this reviewer was probably correct about some of his students at the UK equivalent of MIT or Stanford. But the majority of my students are not like that. I cannot give them Boole’s postulates and expect them to derive the rules of Boolean algebra and fully design a computer with no further explanation.
It is my job to take concepts and ideas that may sometimes be difficult and explain
them in such a way that the students not only understand them sufficiently to pass
exams, but can make use of them and build on them. This factor is particularly important
today when there is a strong emphasis on the notion of life-
There are many ways of enhancing your teaching; this paper concentrates on the use of analogies in teaching computer hardware. Analogies help to convey challenging concepts to the student; just as importantly, they help improve the atmosphere in the classroom by relating rather dry concepts to everyday life.
As Yelamarthi et al point out : “The use of analogies has been found to motivate students to actively [become] involved in classroom discussions. It has successfully inculcated a better understanding by relating theoretical knowledge to real world experiences. This has helped students understand the importance of the concept being taught along with its various applications. Now more than ever before, students must be taught in a manner that will connect each topic with their own lives. This helps in meliorating student understanding.”
In the following sections we look at some of the analogies I have used to teach computer hardware and architecture.
The paper ends with a comment on the dangers of misusing analogies and a short discussion of the effectiveness of this teaching technique.
Memory and Ice
An important topic in computer architecture is memory, not least because it forms
the basis of the so-
We take it for granted that students know what memory is because it’s a term we use in everyday life. However, the human notion of memory is also misleading in several crucial ways.
I introduce computer memory by means of analogy. The analogy I use is ice. Why? The ice on a pond represents a form of memory because the ice remembers that it has been cold even when the temperature rises above freezing point.
An important attribute of any analogy is its exactness or precision. Does the analogy provide a powerful insight into a topic? Is it just a simple means of illustration, or is it largely misleading because the analogy breaks down as soon as you look in any detail? The use of ice as an analogy for memory is, in many ways, quite exact. If you cool water to below freezing, ice forms. If you increase the temperature above freezing, the ice remains (until it melts) indicating that it was once cold. Consider the following:
Some computer architecture courses include a section on analog signal processing – a topic that is of importance in today’s world of multimedia. Capturing analog signals requires the introduction of two topics: sampling and quantization. These topics are commonplace in electronics and computer engineering courses, but are less frequently encountered in computer science courses at freshman or sophomore level for students with relatively little background in mathematics.
Quantization can be introduced via dynamic range. I use the analogy of sugar in coffee. When you ask someone if they take sugar, they may say “half a spoon”. The point is that they could specify the amount of sugar more precisely but that would require more complexity (weighing the sugar or a large number of graded spoons) and most people could not detect small differences in the amount of sugar (demonstrating that the quantization level is related to the nature of the application).
The minimum rate at which a time-
Incidentally, the classic analogy used to illustrate the effect of under-
When dealing with input/output techniques, students are introduced to open-
If you send a letter to someone, you assume that they will receive it. If they do
not receive the letter, you do not know they did not receive it and they do not know
that a letter was sent to them. This is a limitation of an open-
If you wish to ensure receipt of the mail, you can send it advice-
This analogy is also useful in dealing with the implications of open-
Data setup and hold times
There’s one area where I’ve been forced to use analogies. This involves a topic that seems very straightforward to me but not to my students (perhaps it’s the numeric aspects where students have to perform calculations that cause confusion). Clocked circuits such as memory devices have minimum setup and hold times; that is, data must be present for tsetup seconds before the data is captured and then remain stable for thold seconds after the capture.
The way to illustrate setup and hold times is by means of analogy with catching a train. I ask my students when they have to be at the train station to get an 11.30 train. Most students immediately realize the problem and say ‘about 11.15’ because they appreciate they have to read the annunciator to find the platform and then physically board the train before it leaves. This well illustrates the nature of setup time. I have never found a good analogy for the hold time.
When I’m about to discuss the nature of privileged states (user and supervisor states) that are associated with user programs and protected mode operating system programs, I begin by asking the class, “What’s the difference between going to a supermarket to buy something and going to the bank to get some money?”
Curiously, not one student has ever answered this rather simple question correctly. The answer is, of course, that when you go to the supermarket, you perform the transactions yourself by loading your cart with products from the shelves. I tell the students you don’t go to a bank, enter the vault with a cart and proceed to fill it with bundles of notes from the shelves of the vault.
In a bank you have to go to a teller and he or she carries out transactions on your behalf. Consequently, you are not allowed to perform an improper transaction. It’s the same with user mode operations – you are forced to request certain transactions of the operating system (e.g., I/O, disk operations) via mechanisms such as traps (operating system calls). These traps behave like the bank teller and act as the only interface between a user mode program and the operating system. Consequently, a user mode programmer cannot carry out an action that would be harmful to the computer system. In a 68K environment, even corrupting the stack would not necessarily crash the system because the operating system maintains its own, privileged stack that cannot be accessed by a user (applications level) program.
In an introductory architecture class, I briefly discuss multitasking, the apparent ability of a computer to execute multiple programs at the same time. Here I use the example of simultaneous chess, where a group of members of a high school or club all play a chess match against a single powerful opponent. The master chess player goes from opponent to opponent making a move at a time. If there are n opponents he, or she makes n moves in the time each opponent makes a single move.
This analogy works because it is correct in several respects. First, the chess master is far faster than the individual players. This means that each player has the impression that they have full exclusive access to their opponent; they are not necessarily aware of the sharing. Second, the master has to maintain the status of play of each of his or her opponents in order to return to play. Similarly, in a multitasking system the operating system has to store the state of each task in order to reactivate it.
One of the areas in which the computer world closely mirrors the human world is the
interrupt. This makes it easy to teach all the concepts associated with interrupt
handling by means of simple analogies. For example, the interrupt in a computer corresponds
exactly to an interrupt in real life – I tell the students that I might be writing
on the board when a student interrupts by asking a question which I answer and then
return to the board. This illustrates the need to respond to the source of the interrupt
and then return to the pre-
The next step is to explain that if a second student has a question I will ignore it until I’ve answered the first student’s question (interrupt masking); however, if a student falls ill, I will deal with that problem before finishing the first student’s question. This illustrates the concept of interrupt prioritization.
Finally, I deal with interrupt acknowledgement in the following way. I say that if I am writing on the board I will not see who asked the question. I am aware only that a question has been asked and that it could have come from a finite number of students. I explain that I can respond by asking each student in turn whether they asked the question or I can say “Who asked me a question?” and expect one person to answer. These two concepts illustrate polled interrupts and vectored interrupts, respectively.
Few elementary texts introduce associative memory. I find it important to distinguish between human memory which is generally considered to be associative and computer main store memory which is accessed by supplying the address of a specific location.
I often ask a student how old they are. They answer in a surprised tone and I point out that they found that information amongst all the information they store in their brain in very little time – and I didn’t even need to give them the address of where it was stored in their memory. This demonstrates the nature of associative memory. I clinch the concept of associative memory with an old joke.
A Dutch resistance fighter was giving a lecture in London on his wartime experiences. He explains how he was walking through the Dutch countryside when he was strafed by a Fokker. A young girl in the audience looks horrified and her mother says, “It’s OK – it’s a type of Dutch aircraft”. The speaker looks at her and says, “Ja, der Fokker was a Messerschmitt”.
This joke aptly demonstrates the associativity of human memory, where information is retrieved in parallel by means of matching stored data against a key. In this case, there are two responses to the key ‘Fokker’; one being an aircraft type and the other an epithet.
The ISO model for OSI
Some courses on hardware/architecture include the fundamental concepts of data communications such as protocols, the seven layers of the ISO model for open systems communications, and details of the physical and data link layers.
Communications and protocols is also a fruitful area for analogies and can help overcome some of the confusion surrounding the complexities of layered protocols.
Consider an analogy to help fix the nature of the session layer in a student’s mind. The session layer organizes the dialogue between two presentation layers by establishing, managing and synchronizing the channel between two application processes. This layer provides dialogue control of the type, "Roger, over", in radio communications, and the mechanisms used to synchronize application communications. The session layer resolves collisions between synchronization requests. An example is: "... did you follow that? ... " "... then I'll go over it again."
Consider an analogy that might be used to describe the presentation layer of the
ISO model for OSI. A Russian diplomat can phone a Chinese diplomat at the UN, even
though neither speaks the other's language. Suppose the Russian diplomat speaks to
This analogy illustrates an important characteristic of the OSI reference model.
A metaphor I use to introduce operating systems (in the context of computer architecture) is the orchestral conductor. The conductor of a great orchestra is an important figure in society; he or she is famous and gets invited on to chat shows. And yet … how much music does a conductor make? None. Not a single note.
The conductor’s value lies in his or her ability to coordinate the activities of the entire orchestra. The conductor knows the strengths and weaknesses of each player and the characteristics of each piece of music. Consequently, the conductor can maximize or optimize the performance of the orchestra and ‘hide’ any weaknesses due to individual players.
The operating system is in a similar position to the conductor. An operating system does not perform useful computation in the sense that it does not allow you to edit text or play games. However, the operating system knows the structure of the hardware and the tasks to be run and is able to allocate resources to maximize throughput.
The operating system is at the heart of the computer just as the conductor is at
the heart of the orchestra’s performance. Where this analogy breaks down lies in
Some analogies are rather limited but serve to make a minor point. The following list provides a few of the examples I have used.
Huffman encoding Information can be encoded by using a variable-
Binary representation Binary digits are represented by two states (on/off or high/low). You can easily demonstrate the advantage of binary arithmetic by pointing out that you need only to distinguish between two different states – if you used, for example, base ten arithmetic it would require precision electronics capable of discriminating between ten different states. I use the analogy with punched cards (although these are now obsolete) and point out that cards using base ten would require holes in ten different sizes and you have to distinguish between a size six hole and a size seven hole.
Pipelining Probably the mother of all analogies is the analogy between pipelining
in processors and the production line. An instruction is executed in an n-
Cache memory Computers locate frequently used data in a high-
Bus arbitration In systems with buses and multiple bus masters (i.e., devices like
CPUs that can request control of the bus) an arbitration mechanism is needed to determine
which of several requesting bus masters is to gain control of the bus. I discuss
the same problem first in the realm of the bar – a lot of people may be at the bar
trying to get a drink and the bartender has to decide who gets served next. Then
I take the problem to the realm of a computer-
Scheduling William Klinger  suggests an analogy for process scheduling in operating systems that goes beyond my own approach. He combines it with role playing. The students set up a mock fast food restaurant and the students are given food orders by their professor. They then stand in line while the orders are prepared. This provides an opportunity to demonstrate scheduling algorithms by rearranging the order of the students in the line.
CSMA/CD The Ethernet connects several sources to a single cable. If two devices transmit a frame at almost the same time, the two frames collide and are lost. When this happens the two transmitters resend their frames. However, to avoid the damage of repeated collisions, each transmitter backs off for a random period. I use the analogy of two people approaching a revolving door. They each step forward, collide and politely step back. Then they step forward, collide, and so on. Everyone has been in this situation many times. I suggest that the Ethernet solution would require each person to throw a die after the first collision and then wait that number of seconds before advancing. Unless both people throw the same number, there will not be a second collision.
Just because someone might use a metaphor doesn’t mean that it’s illuminating or
apposite. One of the worst metaphors that appeared in some elementary texts was the
This is a significant point because some of my students do not always appreciate
how a computer operates; for example, if I ask, “What is the difference between an
Effectiveness of this approach
It would be nice to provide a quantitative indicator of the effectiveness of this
approach to teaching computer hardware. That is not possible. In terms of raw marks,
an approach to the subject that seeks to engage students and to make them think about
the material being taught does not appear stunningly significant. Other factors play
greater roles; for example, a few years ago I taught a senior year architecture class
to a group of students that were on two different degree courses. One was an accredited
CS course, and the other was not accredited. The non-
However, two factors do tend to point to the success of teaching methods that seek to engage students. First, the student feedback is generally very positive – particularly in terms of the comments that students make. There is also a good atmosphere in the class. Second, several students have written to me, years after they have taken the course, and stated how much it helped them – even though they did not appreciate it at the time.
In retrospect, I am not certain whether techniques that use the type of analogies
described in this paper (and any of the other techniques I might use to engage students)
are effective at the lower end of the range of student abilities. Some students who
have great difficulties following the course (and who either fail or receive marginal
passes in much of their work) seem to prefer a rote-
 Clements, A, "Principles of Computer Hardware", Oxford University Press, 1985.
 Kelamarthi, K, "The practical use of analogies to mentor the engineer of 2020",
American Society of Engineering Education, Illinois-
 Klinger, W, "Stanislavski and Computer Science", ACM SIGCSE Bulletins, Vol.
37, Issue 4,December 2005, pp111-