Home Up Exams Teaching Architecture Embedding Ethics Computer History External Examiner System
Home Teaching Glossary ARM Processors Supplements Prof issues About

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-related topics such as interrupts, protected-state operation, bus arbitration protocols, and multitasking. Not only do these analogies make it easier for students to learn new concepts, they help make the teaching environment more informal and invite active class participation.


The Student


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-defined standard student with consistent properties. Anyone who has taught can tell you that such a student does not exist and, in particular, there is a range of student types with different inherent abilities, motivations, and approaches to learning. Consequently, there cannot be a one-size-fits-all approach to education.


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-called external examiners) at other universities.


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-paid job is sometimes the magnet rather than a desire to learn computer science).


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.


The Job


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 [1]. 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-long learning.


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 [2]: “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.”


The Analogy


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-called von Neumann machine and is available in a bewildering number of implementations from semiconductor–based DRAM to magnetic disk and optical disks.


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:



Quantization


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-varying quantity must be sampled is given by Nyquist’s theorem – twice the rate of highest frequency component in the signal. I introduce this topic by considering the control of swimming baths. A large body of water cannot change its temperature rapidly and students can readily appreciate that sampling rate must be related to the rate at which a signal changes.


Incidentally, the classic analogy used to illustrate the effect of under-sampling used to be the wagon wheel. If you sample a signal at below the Nyquist rate, high frequency signals appear as low frequency signals. Similarly, if you watch a wagon with spoked wheels move on film or TV, you seen the wheels move forward and then suddenly change direction and reverse as the wagon accelerates. The reason for this is simple – if the wheel advances by 100 between each frame, you see the wheel rotating. However, if the wheel advances 3500 between frames you see the wheel rotating 100 in the reverse direction. The reason this analogy is harder to use today is not because of any flaw in the logic – it’s because few students have seen wagons on TV or the movies; the western is a genre that belongs to a past generation.


Handshaking


When dealing with input/output techniques, students are introduced to open- and closed-loop data transfers and handshaking. Typically, the explanation involves timing diagrams with a data available signal (open-loop protocols) and both data available and data accepted signals (closed-loop protocols). I find it easiest to introduce the topic by analogy to the mail system.


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-loop data transfer.

If you wish to ensure receipt of the mail, you can send it advice-of-delivery or recorded-mail. In this case, the recipient signs for the letter and the sender receives confirmation – exactly as in a closed-loop data transfer. This action models the closed-loop transfer where the receipt of a data available signal is met by the assertion of a data acknowledge signal.


This analogy is also useful in dealing with the implications of open-loop transfers. You can ask the class how they would deal with the mail problem. Some might suggest that the recipient can send a letter saying that they have not received anything recently (i.e., the concept of a time-out). Another student might suggest that you number the letters you send so that the recipient would notice an out-of-sequence letter and deduce that a previous letter had been lost (i.e., the concept of frame numbering in HDLC transmission systems). Another advantage of this analogy is that it shows that the open-loop data transfer is conservative. You can only send data at the slowest rate that it can be reliably processed. However, with a closed-loop transfer you can send data as soon as you receive an acknowledgement. Similarly, with the advice-of-delivery service you can send your next letter as soon as you know that your last letter was received.


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.


Privileged states


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.


Multitasking


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.


Interrupts


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-interrupt state.


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.


Associative memory


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 a Russian-to-English interpreter who speaks to an English-to-Chinese interpreter at the other end of a telephone link, who, in turn, speaks to the Chinese diplomat. The diplomats represent the applications layer process and talk to each other about political problems. They don't speak to each other directly and use a presentation layer to format the data before it is transmitted between them. The Chinese-to-English and English-to-Russian translators represent the presentation layer.

This analogy illustrates an important characteristic of the OSI reference model. The English-to-Chinese translator may be a human or a machine. Replacing one with the other has no effect on the application layer above it or on the information transfer layers below it. All that is needed is a mechanism that translates English to Chinese, subject to specified performance criteria.


Operating Systems


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 the dual-function nature of the modern operating system. Early operating systems were largely programs that optimized resources by scheduling tasks and controlling hardware resources. Today’s graphical operating systems like, Windows, perform the important function of acting as the interface between the user and the computer and its applications. Moreover, some functions that were one user applications have been incorporated into the operating system.


Minor Comparisons


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-length code (i.e., each code word may have a different length). This encoding mechanism is effective when some source codes are far more common (i.e., their probability of appearing at any point in a message is greater than other codes) than others and these have shorter code words. The analogy here is with Morse code which gives frequently-used letters like E short codes and seldom used letters like Q long codes.


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-stage pipeline and, at any instant, up to n instructions may be in the pipeline. This arrangement is analogous to the production line, where a car is assembled in stages. As the car passes along the production line, it is gradually constructed. This analogy is fairly exact because the same considerations govern the optimum number of stages in a car production plant and in a computer. Moreover, they both suffer from the same problem – when a new model of car is created, you have to wait for the current production line to empty. When a processor executes a jump (branch) instruction, you also have to wait for the pipeline to empty.


Cache memory Computers locate frequently used data in a high-speed cache memory. Because of the locality of data, future accesses are likely to access data in cache rather than main store. The analogy is the personal address book where you may have only a few tens of phone numbers, but your next call is likely to be to someone whose number is in the book. However, this is not an exact analogy because it omits many features of the computer cache – a human will know whether a name should be written in the note book, whereas the computer automatically puts data in its cache even if it will never be accessed again (cache pollution).


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-controlled nuclear reactor where several devices may be wanting to deal with a problem that might range from a message saying it’s time to perform a yearly check on a component, to a warning that the reactor’s cooling pump has just failed. Clearly, these two situations require different arbitration mechanisms. In a bar you want a fairness mechanism to ensure that each customer gets treated in the same way as every other customer – and that the customer being currently served goes to the back of the queue. On the other hand, in a safety critical system, some events must be responded to immediately and a prioritization mechanism is required. These real-world analogies allow class discussions of arbitration mechanisms and algorithms.


Scheduling William Klinger [3] 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.


Inappropriate metaphors


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 term high-speed moron used to describe the CPU. The intended sense was that the computer is fast but not clever. Such a use of moron carries with it the notion of errors, inaccuracy, and inability. It is true that a computer requires a program in order to carry out useful computation, but that is not the same as being moronic. No one would call a five-year old child moronic if they did not understand calculus; just like the computer, the child has to be programmed. In particular, the computer does not make errors in the sense that each of its operations is repeatable and not prone to random errors. If you multiple two numbers together, you always get the same result.


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 8-bit processor and a 32-bit processor”, some students will eventually say that a 32-bit processor is more accurate than an 8-bit processor. This betrays their understanding of the internal operation of a processor which always gets the same results with the same data and same operations. An 8-bit processor can perform 32-bit arithmetic simply by chaining four bytes; that is, an 8-bit processor can emulate a 32-bit processor.


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-accredited course was taught to the same standard as the accredited course – the only difference was that students on the non-accredited course could take any of the available CS modules (i.e., there were no specific core requirements). Consequently, students on the non-accredited course were often weaker and sometimes were studying computer architecture because they lacked the prerequisites for some of the advanced software courses. In the final exams, the average mark for students on the non-accredited course was marginally below the pass level of 40% and the average mark for students on the accredited course was over 70%. This demonstrated that student demographics were the prime factor in determining the outcome of the course.


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-learning approach; that is, if they are given facts to memorize or formulae that they learn and then plug numbers into in an exam, they are happier than when they are required to think about the material they are learning.


References


[1] Clements, A, "Principles of Computer Hardware", Oxford University Press, 1985.

[2] Kelamarthi, K, "The practical use of analogies to mentor the engineer of 2020",  American Society of Engineering Education,  Illinois-Indiana and North Central Joint Conference, March-April 2006

[3] Klinger, W, "Stanislavski and Computer Science",  ACM  SIGCSE Bulletins,  Vol. 37, Issue 4,December 2005, pp111-114


Science Fiction