An Integrated Approach to Teaching Computing Systems Architecture

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 – 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 • Simplementation followed by performanceconscious 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 Threads. TM 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 Logic. Works

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