An Integrated Approach to Teaching Computing Systems Architecture

Kishore Ramachandran &

Bill Leahy

College of ComputingGeorgia Institute of Technology

Outline

• Traditional approach• Pedagogy of new approach• Where does it fit and how do

we put it in practice?• Experience at Tech• Evaluating the pedagogy• Challenges• Comparison to other

pedagogical models• Concluding remarks

Traditional Approach

• Stovepipe model– Architecture and OS as

distinct courses usually in the junior/senior years

• Georgia Tech– Followed similar model until

1999– Two junior level courses

one on OS and the other on architecture

What is wrong with the traditional approach?

• Symbiotic relationship missed– High level language and

instruction sets– OS abstractions and processor– Network protocols and physical

network– Students get this?

• Not if compartmentalized

• Gap between the time when the courses are taken– Concepts forgotten

• Connections not seen at all by the students most of the time

Why change?

• Problems with the traditional approach

• Changing CS scene– New areas evolving– Graphics, visualization, HCI– Need rethinking of “core”

• UG research involvement– Need to infuse interest

early– Entry level for systems

research high

New approach• Excitement of middle-school

kids– What is inside a box?– What makes it play cool music or

video games?

• An integrated course– Combining OS and architecture

• Goal of the course– “Unraveling the box”– Take the journey together

exploring hardware and the OS abstractions

– Emphasize connectedness

Pedagogy of new approach

• Present what is “inside a box”– Processor module– Memory module– I/O and storage module– Parallel module– Network module

• Key differentiator– Concomitant treatment of

hardware and software in each module

Pedagogical style• Discovery as opposed to

indoctrination or instruction• Top down approach

– Start with problem to be solved– Explore solution space together

• Example:– What is memory management?

• Understand the need first• Discover the software issues and

the corresponding hardware issues

• Story telling approach– Keeps the student interest alive

Processor module

• HLL constructs and their influence on instruction-set design

• Simple implementation followed by performance-conscious pipelined implementation

• Process abstraction in OS and processor scheduling

Memory module

• Memory management in OS

• Architectural issues• Memory hierarchies

I/O and storage module

• Program discontinuities including interrupts, traps, and exceptions– Processor mechanisms– OS mechanisms

• Devices and device drivers• Emphasis on disk

subsystem– Storage abstraction– File system fundamentals

Parallel module

• Introduce threads as a programming construct

• OS issues for supporting parallel programming

• Architectural issues for supporting parallel programming

Network module

• Evolution of networking hardware

• Network protocol stack

Connecting the different modules

• HLL constructs lead to design of instruction-set for LC-2200

• Processor implementation of LC-2200

• Memory management assists to LC-2200

• Interrupt and DMA support to LC-2200

• ……

Why parallelism in a first course?

• Our motivation then (circa 98)– Love affair of CS with parallelism

• PL and concurrency• OS and concurrency

– Enablers in the 90’s• Java, MT OS, multiple CPUs in

desktops

• In hindsight now– Multicore CPUs– Multithreading as a programming

concept in intro courses

Why networking in a first course?

• “box” without connectivity is no good today

• Protocol stack is an integral part of any OS

• Our motivation– Understand evolution of

networking gear– Understand mechanisms

needed in protocol stack– Understand how a “box”

avails of network services

Where does this course fit?

• Assumed knowledge– Logic design, assembly language,

and C programming

• New course is a first systems course– Preferably in sophomore year

• What follows?– Advanced architecture, OS,

networking courses– For those following other pursuits

• Sufficient exposure to “core”

Putting this pedagogical style in practice

• 4 credit-hour semester course or 5-credit hour quarter course

• 45 hours of lecture– Roughly 9 hours for each

module (some more than others)

• 60-90 hours of unsupervised lab time for projects

Experience at Georgia Tech

• CS 2200 introduced in Fall 1999

• Project component for each module– Concepts “get in” via

projects– Collaboration allowed

• Key is “learning”

– Creativity in evaluation

Evaluating the pedagogy

• CS students hardware-averse• OS and hardware together

makes “sense”– Hardware design as an

algorithmic exercise

• Successful internships– Anecdotal evidence from

industries and students

• Concepts learned early apply to other domains (e.g. web caching)

• Students better prepared for advanced courses

• Informal poll– At beginning of course

• 10% interested in the course

– At end of course• Majority feel the course was

useful and important

• Increased interest in systems– Number of UG students doing

research in systems

Other reasons why this is a good approach

• Allows curricular innovation

• GT CS has been a leader of innovation– Evidence

• New ThreadsTM approach• Chapter 7, Pages 309-315,

“The Right Stuff,” from THE WORLD IS FLAT: UPDATED AND EXPANDED EDITION, by Thomas L. Friedman

Meeting the Challenges• Textbook

– Good books available for the stovepipe model

– None for an integrated model• We developed comprehensive

notes and slides– Used standard textbooks as

background• Responding to students

– Turned our courseware into online textbook in 2005

• To match the style and content• Available to the community• In use for 8 consecutive

semesters (including summers)

Adopting the pedagogical style

• Online textbook• Extensive online slides• Several detailed project

ideas from 7+ years of teaching this course

• Several problem sets and model exams online

• In short– Painless transition from

stovepipe model to this one

Comparison to other recent pedagogical models

• Patt and Patel– Logic design, assembly language,

plus C– Ideal as a pre-req for our course

• Bryant and O’Hallaron– Programmer’s perspective– Goal

• How to create “power programmers”?

• Important but different from our focus

– Best applied to senior level UG– A worthy follow on to our course

• Saltzer and Kaashoek– System building blocks that

appear in different large complex software systems

– Goal• How to prepare students who

can create modular software systems?

– A worthy follow on to our course

Concluding remarks

• An integrated approach to teaching computer system architecture at sophomore level

• Been in practice at GT for 7+ years

• Online textbook, slides, project ideas, and tools available for the whole community

Applause!!!

Project: Processor Design

• Students given datapath 90% complete

• Project entails– Completing the datapath– Writing micro-code for

implementing LC-2200 instruction set

– Circuit design using LogicWorks

Project: Interrupts and I/O

• Students supplied with LC-2200 simulator and LC-2200 assembler

• Project entails– Adding circuitry to project 1 for

handling interrupts– Enhancing the simulator to deal

with interrupts– Writing an interrupt handler (in

LC-2200 assembly) to work with the enhanced simulator

Project: Virtual memory subsystem• Students supplied with a

processor plus memory system simulator

• Project entails– Developing a page-based

VM system on top– Experimenting with

different page replacement algorithms

Project: MT OS

• Students provided with a processor plus memory system simulator

• Project entails– Implementing multithreaded OS

modules for managing the CPU and I/O scheduling queues

– Parallel programming using pthreads

– Experimenting with different CPU scheduling algorithms

Project: Reliable Transport Layer

• Students provided with a simulated network layer

• Project entails– Implementing a reliable

transport that deals with• Packet corruption• Lost packets• Out-of-order delivery of

packets

– Parallel programming using pthreads