An Integrated Approach to Teaching Computing Systems Architecture

1
An Integrated Approach to Teaching Computing
Systems Architecture

• Kishore Ramachandran
• Bill Leahy
• College of Computing
• Georgia Institute of Technology

2
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

3
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

4
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

5
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

6
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

7
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

8
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

9
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

10
Memory module

• Memory management in OS
• Architectural issues
• Memory hierarchies

11
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

12
Parallel module

• Introduce threads as a programming construct
• OS issues for supporting parallel programming
• Architectural issues for supporting parallel
  programming

13
Network module

• Evolution of networking hardware
• Network protocol stack

14
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

15
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 90s
• Java, MT OS, multiple CPUs in desktops
• In hindsight now
• Multicore CPUs
• Multithreading as a programming concept in intro
  courses

16
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

17
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

18
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

19
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

20
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)

21

• 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

22
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

23
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)

24
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

25
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 OHallaron
• Programmers 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

26

• 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

27
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

28

• Applause!!!
• ?

29
(No Transcript)
30
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

31
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

32
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

33
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

34
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

35
(No Transcript)