An Integrated Approach to Teaching Computing Systems Architecture Kishore Ramachandran & Bill Leahy College of Computing Georgia 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 Georgia Tech 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 An integrated course 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