A Learning Environment to Teach Computer Architecture

SEBASTIANO PIZZUTILO and FILIPPO TANGORRA

Dipartimento di Informatica

Università di Bari

via Orabona 4, 70126 Bari

ITALY

Abstract: - Realizing teaching tools in computer architecture and assembly language fields has found remarkable difficulties. The rapid machine obsolescence and the growing complexity of modern processors impose continuous revisions of the course contents and consequently of the relative didactic materials (as lectures, exercises, simulators, assembly programs). The ARCHO learning environment was developed to support the computer architecture and the assembly language teaching at introductory level, preserving the necessity to meet technological innovations and architectural choices of new processor models. The flexibility of the environment allows the teacher to adapt contents and didactic tools to new learning needs. Thus student has always revised matter to navigate the hypertext lectures, to resolve exercises and to compile and test programs on the computer processor simulator. ARCHO provides and integrates two different systems: ARCAL to support the study of theoretical concepts and to verify lectures and APE to support the laboratory activity by using a computer architecture simulator.

Key Words: - Educational software, Courseware, Computer architecture simulation

1. Introduction

Various learning systems have been developed to support computer architecture education integrating theoretical learning materials and laboratory activities in order to meet the specific needs of the target population and to improve didactic effectiveness.

At the University of Bari, the “Computer Architecture” is an introductory course of the Computer Science degree curriculum. The annual enrolment is approximately 500 students. The course is also supplied by teleconferencing to many University sites in the region. The contents of the lectures cover topics according suggestions of ACM/CS [1] guidelines for architecture courses and using the popular textbook by A. Tannenbaum [2]. The basic concepts of theoretical lectures are reinforced with laboratory activities, that allow the student to be familiar with the internal format of data types and the assembly language level.

The large number of students, their geographical scattering and their different background make ineffective the traditional organization of lectures and impracticable the following of the single student progress in the learning process. The previous features amplify the usual problems connected to the laboratory activities of a computer architecture course. In fact, we have many difficulties in the laboratory management, as for example: a) high costs of the hardware equipment which increase with the number of workstations; b) problems to continually keep the laboratory up-to-date with the constant technological innovations (important for processor architecture studies); c) high costs of equipment maintenance.

On the other side, there are difficulties to follow pedagogical objectives of the course, as follows: a) to introducing progressively the complexity of the modern computer instruction set; b) to observe the relationship between assembly/machine level languages and the architecture; c) to compare the instruction set and performance of different computer type (RISC/CISC) because laboratory components are not so rich and refer to a specific hardware system [3].

In order to overcome the previous limitations, we have started the “ARCHO” project for the implementation of a computer based learning environment for teaching computer architecture; it is aimed at the design and building a learning and self teaching tool, which allows continuous self-evaluation of own educational progress.

The paper is organized in five Sections. After the Introduction, the Section 2 introduces the features of the ARCHO environment, then Section 3 describes the components of the system ARCAL, which supports the theoretical lectures and the exercises, pointing out the aspects of personalization of the didactical path. Section 4 illustrates the APE system and describes the user (teaching/student) interactions. Conclusions are reported in Section 5.

2. The ARCHO environment

The multimedia interactive environment ARCHO is devoted to improve the quality of the student learning in computer architecture. It provides two interfaces for the teacher and the student interactions.

The teacher can define the instructional level as well as the wide-ranging complexity for the student. Therefore the teacher functionalities of ARCHO permits the following tasks:

·  to modify the learning path and the lecture contents and exercises,

·  to verify the student tests and eventually to attend with suitable suggestions,

·  to define the most useful processor to reinforce the theoretical concepts of laboratory topics.

On the other hand, the student can take profit by graduating efforts with respect his/her learning progress and evaluating the own preparation level. The student functionalities of ARCHO allows the following tasks:

·  to go deeply into course arguments, choosing personalized formative path, useful to supply cultural gap and/or to give a common base to learn new concepts in the classroom during the lectures,

·  to train by exercises on the just learned concepts,

·  to self-evaluate the obtained progress,

·  to use a dynamic computer architecture simulation environment, suitable for the pedagogical aims of laboratory activities [4,5].

The student can use the system in University computer service rooms or directly at home via Internet.

The learning environment provides and integrates two different systems: ARCAL to support the study of theoretical concepts and to verify lectures and APE to support the laboratory activity.

3. The ARCAL system

The ARCAL system presents an hypertext (in Italian) to the student corresponding to didactical units of the course of “Computer Architecture”[6]. It is also able to offer to the student interactive exercises for each didactical unit and the opportunity to self-evaluate the learning of acquired concepts and methods .

The system is able to store the student’s learning path (the visited units, the results of exercises and tests), so that it is possible to recall the learning process starting from the break point. Furthermore, the system allows the teacher to manage the didactic units, by adding new units and by deleting or updating the old ones.

In figure 1 the structure of the ARCAL system is reported.

The ARCAL interface allows, by an authorizing procedure, the user to select groups of tasks (student or teacher) of the system. It is composed by three modules: the student module, the guide module and the teacher module.

The student module allows tasks of learning the course contents [7]. It uses a data base of general information about students, linked with information about the learning progress of each student (tracks on already read didactical units, exercise results and so on…) so as to permit a self evaluation of the obtained learning progress.

Fig.1 The structure of ARCAL

The guide module is able to help by explanations the user to interact with the system. It is possible to activate this module everywhere in the system.

The teacher module collect all management tasks of the didactic materials, so as to update the already provided lessons, to examine the learning student path and results of developed exercises and so on.

This module is organized in the following sub-modules:

a) the didactical units manager, which allows the updating of lessons, preserving the early standard layout of the presentation;

b) the index manager, which manages the general index and sub-index of each didactical unit. This sub-module is automatically activated when the sub-module a) is used to update units;

c) the page manager, to edit/modify new pages, choosing and inserting in the text new graphical objects ( widgets, character fonts, images, links, applications,…);

d) the exercise manager, to edit/modify the proposed exercises and tests. It is possible for the teacher to define questions and answers, suggesting to the student arguments to learn in case of wrong answers;

e) the student reports. It allows the teacher to read the test results , starting from the identification data of each student.

In figure 2 an example of dialog window of the teacher module is reported.

Fig.2 Main dialog window of teacher module

The Course module contains the didactical material organized in the following forms:

- theoretical units, accessible by a general index and presented to the student in a suggested logical order to avoid the getting lost in hyperspace [8] (each unit has a root document, where the student any time can go back);

- examples, linked to theoretical arguments, to show (by animations) the functioning of a processor or methods;

- exercises to be resolved by students. Here there are other facilities for students to keep annotations and to see at the exercise results.

The figure 3 shows an example of lesson.

Fig.3 Main dialog window of course module

4. The APE system

The design aim for APE system was to provide the teachers of the computer architecture courses with a tool that allows easily the rapid prototyping of processor simulators, which can be used in the laboratory activities. For this purpose, the system supports the processor simulator development providing two steps: the architecture definition step and the architecture test step.

It has been used an object oriented approach to describe the computer architecture, considering hardware components of the processor as objects. The set of the objects corresponds to the computer structure and their methods implement instructions and addressing methods [4, 5]. This approach permits to proceed in an iterative way for developing the processor simulator trough an approach similar to the rapid prototyping cycle (as shown in Figure 4).

Figure 4. The computer architecture modelling process.

The teacher establishes the processor requirements and, at the definition step, chooses the components of the architecture to simulate (as the type and the number of registers, the attributes of the processor and the memory…) and defines their parameters. The system then constructs a simulator that is the representation of the defined architecture including only those objects necessary to meet the teacher requirements. It serves, in the test step, as a work version of the architecture simulator in order to verify the result of the design activity.

During the test step, the teacher evaluates, by running assembly programs, the simulator's actual behaviour respect of its expected behaviour. If the simulator fails the execution, the teacher identifies the problems and establishes adjustments to the requirements for the architecture definition step repetition.

The object oriented approach guarantees an high level teacher interaction which avoids to treat implementative aspects. This process continues until the teacher states that the prototype successfully simulates the functions of the required processor.

Finally, the APE system builds the desired simulator that students run with assembly programs and displays results of the execution in terms of the processor status.

Fig. 5 The APE architecture

The overall structure of APE provides two main subsystems (figure 5), which support the two different user-interaction phases: the Architecture Definition Subsystem (APE-ADS) and the Architecture Test Subsystem (APE-ATS).

The APE-ADS subsystem supports the definition of processor characteristics with a graphical interface that helps the teacher in the choice of the basic architectural elements either from a database of the basic ISA level components or from a database of the basic microprogramming level components.

The APE-ATS subsystem supports tools for testing the simulator prototype. Helped by a graphical interface, the user can perform activities as: writing and translating of programs in assembly language or in symbolic language Micro Assembly Language (MAL), a didactic language for a microprogramming level [2,9]; running and debugging of machine programs and microprograms; displaying of the architecture status both at ISA level and at the microprogramming level; simulation of the performances of the designed architecture at both same levels.

The APE-ADS and APE-ATS subsystems concern with the activity of preparation of the teachers that we have indicated in figure 4 as teacher interaction. Differently, we denoted student interaction the use of the defined simulator in the laboratory activities.

4.1 The teacher interaction

The system allows the teacher to define and to build the simulator of the target computer architecture corresponding to different didactic purpose. In fact, also in presence of general guidelines (like as [1]) for the contents of the architecture courses, the teacher can point out particular aspects of the computer architecture. For example, the teacher has to decide how much relevance to give to the instruction set level or to the functional unit level of the computer organization.

The APE allows to interact at different levels and to switch from a level to another. Therefore, the computer architecture can be defined and tested both at the microprogramming level and at the instruction set level. In the latter case, the tool automatically constructs the corresponding microarchitecture.

The teacher has also to decide if the target architecture to simulate must be a hypothetical general machine or a real specific machine or, finally, more real machines can be used to illustrate different architecture implementations. However, in learning computer organization, common practices adopted by teachers for both approaches consist into the progressive introduction of the complexity of the processor and of the details of the assembly languages and into the concentration of the attention on a small part of the architecture. In fact, when the teacher, in the definition step, chooses the computer components for the simulation prototype, APE associates the assembly instructions and addressing methods for those components. In this phase, APE lists all instructions that the user can activate. In other words, not all instruction and addressing methods associated to the object instances that has been defined can be necessarily inserted in the resulting assembly language of the simulator. The tool leaves to the teacher the possibility to activate only the necessary instructions of the defined architecture.

4.2 The student interaction

The following educational objectives can be obtained with the processor simulator: i) increasing of skills in low level programming language; ii) taking confidence with the information representation and with data types at internal level as, for example, the instruction format and the binary/hexadecimal representation of signed integer, fixed point and floating point representations, coding etc.; iii) showing the computer organization using visualisation techniques and animations for a better comprehension of what it occurs within a processor; iv) displaying actions taking place within the processor units and the register/memory contents as they execute assembly programs.