Carnegie Mellon

Course Overview
15-213/14-513/15-513:
Introduction to Computer Systems
1st Lecture, Aug 29, 2023 Instructors:
Phil Gibbons (15-213 / 15-513)
Brian Railing (15-213 / 15-513)
David Varodayan (14-513)

The course that gives CMU its “Zip”!

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 1
 Carnegie Mellon

Overview
 Introductions
 Big Picture

 Course theme
 Five realities
 How the course fits into the CS/ECE/INI curriculum
 Academic integrity
 Logistics and Policies

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 2

 Carnegie Mellon
Carnegie Mellon

Instructors
Brian Railing Phil Gibbons

15-
213
15-
513

David
Varodayan

14-513

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 3

 Carnegie Mellon

The Big Picture

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 4

 Carnegie Mellon

Course Theme:
(Systems) Knowledge is Power!
 Systems Knowledge
 How hardware (processors, memories, disk drives, network infrastructure)
plus software (operating systems, compilers, libraries, network protocols)
combine to support the execution of application programs
 How you as a programmer can best use these resources
 Useful outcomes from taking 213/513
 Become more effective programmers

Able to find and eliminate bugs efficiently
 Able to understand and tune for program performance
 Prepare for later “systems” classes in CS & ECE
 Compilers, Operating Systems, Networks, Computer Architecture,
Embedded Systems, Storage Systems, etc.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 5

 Carnegie Mellon

It’s Important to Understand How

Things Work
 Why do I need to know this stuff?
 Abstraction is good, but don’t forget reality
 Most CS and CE courses emphasize
abstraction; so do we!
 Abstract data types
 Asymptotic analysis
 But it’s helpful to understand what
abstractions build upon and their limits!
 Especially in the presence of bugs
 Need to understand details of underlying implementations
 Sometimes the abstract interfaces don’t provide the level of control or
performance you need

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 6

 Great Reality #1:
Carnegie Mellon

Ints are not Integers, Floats are

not

Reals
Example 1: Is x ≥ 0? 2

 Float’s: Yes!

 Int’s:
 40000 * 40000 --> 1600000000
 50000 * 50000 --> ?
 Example 2: Is (x + y) + z = x + (y + z)?
 Unsigned & Signed Int’s: Yes!
 Float’s:
 (1e20 + -1e20) + 3.14 --> 3.14
 1e20 + (-1e20 + 3.14) --> ??
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
Source: xkcd.com/571 7
 Carnegie Mellon

Computer Arithmetic
 Does not generate random values
 Arithmetic operations have important mathematical properties
 Cannot assume all “usual” mathematical
properties
 Due to finiteness of representations
 Integer operations satisfy “ring” properties

Commutativity, associativity, distributivity
 Floating point operations satisfy “ordering” properties
 Monotonicity, values of signs

 Observation
 Need to understand which abstractions apply in which contexts
 Important issues for compiler writers and serious application programmers

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 8

 Carnegie Mellon

Great Reality #2:

You’ve Got to Know Assembly
 Chances are, you’ll never write programs in
assembly
 Compilers are much better & more patient than you are
 But: Understanding assembly is key to machine-
level execution model
 Behavior of programs in presence of bugs
High-level language models break down

 Tuning program performance
 Understand optimizations done / not done by the compiler
 Understanding sources of program inefficiency
 Implementing system software
 Compiler has machine code as target
 Operating systems must manage process state
 Creating / fighting malware
 x86 assembly is the language of choice!
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 9
 Carnegie Mellon

Great Reality #3: Memory

Matters
Random Access Memory Is an Unphysical
Abstraction
 Memory is not unbounded
 It must be allocated and managed
 Many applications are memory dominated
 Memory referencing bugs especially
pernicious
 Effects are distant in both time and space
 Memory performance is not uniform
 Cache and virtual memory effects can greatly affect program performance
 Adapting program to characteristics of memory system can lead to major
speed improvements

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 10

 Carnegie Mellon

Memory Referencing Bug

Example
typedef struct {
int a[2];
double d;
} struct_t;

double fun(int i) {
volatile struct_t s;
s.d = 3.14;
s.a[i] = 1073741824; /* Possibly out of bounds */
return s.d;
}

fun(0) --> 3.14

fun(1) --> 3.14
fun(2) --> 3.1399998664856
fun(3) --> 2.00000061035156
fun(4) --> 3.14
fun(6) --> Segmentation fault
 Result is system specific
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 11
 Carnegie Mellon

Memory Referencing Bug

Example
typedef struct { fun(0) --> 3.14
int a[2]; fun(1) --> 3.14
double d; fun(2) --> 3.1399998664856
} struct_t;
fun(3) --> 2.00000061035156
fun(4) --> 3.14
fun(6) --> Segmentation fault

Explanation:
Critical State 6
? 5
? 4
d7 ... d4 3 Location accessed by
d3 ... d0 2 fun(i)
struct_t
a[1] 1
a[0] 0

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 12

 Carnegie Mellon

Memory Referencing Errors

 C and C++ do not provide any memory
protection
 Out of bounds array references
 Invalid pointer values
 Abuses of malloc/free
 Can lead to nasty bugs
 Whether or not bug has any effect depends on system and compiler
 Action at a distance
 Corrupted object logically unrelated to one being accessed
 Effect of bug may be first observed long after it is generated
 How can I deal with this?
 Program in Java, Ruby, Python, ML, …
 Understand what possible interactions may occur
 Use or develop tools to detect referencing errors (e.g. Valgrind) 13
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
 Carnegie Mellon

Great Reality #4: There’s more to performance

than asymptotic complexity

 Constant factors matter too!

 And even exact op count does not predict

performance
 Easily see 10:1 performance range depending on how code written
 Must optimize at multiple levels: algorithm, data representations,
procedures, and loops
 Must understand system to optimize
performance
 How programs compiled and executed
 How to measure program performance and identify bottlenecks
 How to improve performance without destroying code modularity and
generality

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 14

 Carnegie Mellon

Memory System Performance

Example
void copyij(int src[2048][2048], void copyji(int src[2048][2048],
int dst[2048][2048]) int dst[2048][2048])
{ {
int i,j; int i,j;
for (i = 0; i < 2048; i++) for (j = 0; j < 2048; j++)
for (j = 0; j < 2048; j++) for (i = 0; i < 2048; i++)
dst[i][j] = src[i][j]; dst[i][j] = src[i][j];
} }

4.3ms 81.8ms
2.0 GHz Intel Core i7 Haswell
 Hierarchical memory organization
 Performance depends on access patterns

 Including how step through multi-dimensional array

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 15

 Carnegie Mellon

Learn why on Sept 26: Memory

Hierarchy
copyij

16000

14000
Read throughput (MB/s)

12000

10000

8000

6000

4000

2000
copyji 16
0 32 k
64 k
s1 12
s2 25 8k k
s3 10 51 6k
s4 24 2k
s5 2m k
s6 4m
s7 16 8m
s8 32 m
Stride (x8 bytes) s9 64
s1 12 m m Size (bytes)
0 s1 8m
1

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 16

 Carnegie Mellon
Great Reality #5:
Computers do more than
execute programs
 They need to get data in and out
 I/O system critical to program reliability and performance

 They communicate with each other over

networks
 Many system-level issues arise in presence of network
 Concurrent operations by autonomous processes
 Coping with unreliable media
 Cross platform compatibility
 Complex performance issues

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 17

 Carnegie Mellon

Course Perspective
 Most Systems Courses are Builder-Centric
 Computer Architecture

Design pipelined processor in Verilog
 Operating Systems
 Implement sample portions of operating system
 Compilers
 Write compiler for simple language
 Networking
 Implement and simulate network protocols

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 18

 Carnegie Mellon

Course Perspective (Cont.)

 Our Course is Programmer-Centric
 By knowing more about the underlying system, you can be more effective
as a programmer
 Enable you to
 Write programs that are more reliable and efficient
 Incorporate features that require hooks into OS
– E.g., concurrency, signal handlers
 Cover material in this course that you won’t see elsewhere
 Not just a course for dedicated hackers
 We bring out the hidden hacker in everyone!

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 19

 Carnegie Mellon

Role within CS/ECE Curriculum CS 122

Imperative
Programming

Foundation of Computer
Systems 213/513
Underlying principles for
hardware,
software, and networking
CS Systems ECE Systems
• 15-319 Cloud • 18-330 Computer Security
Computing • 18-349 Intro to Embedded
• 15-330 Computer Systems
Security • 18-441 Computer Networks
• 15-346 Computer • 18-447 Computer
Architecture Architecture
• 15-410 Operating • 18-452 Wireless Networking
Systems CS •Graphics
18-451 Cyberphysical
• 15-411 Compiler Design • 15-462 Computer
Systems
• 15-415 Database Graphics
Applications • 15-463 Comp.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 20
 Carnegie Mellon

Academic
Integrity
Please pay close attention,
especially if this is your
first semester at CMU

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 22

 Carnegie Mellon

Cheating/Plagiarism: Description
 Unauthorized use of information
 Borrowing code: by copying, retyping, looking at a file
 Describing: verbal description of code from one person to another

Even if you just describe/discuss how to put together CS:APP code
snippets to solve the problem
 Searching the Web for solutions, discussions, tutorials, blogs, other
universities’ 213 instances,… in English or any other language
 Copying code from a previous course or online solution
 Reusing your code from a previous semester (here or elsewhere)
 If you take the course this semester, all work has to be done this
semester (unless you have special permission from the instructors)

 Using AI to generate your code (e.g., GitHub CoPilot, ChatGPT)

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 23

 Carnegie Mellon

Cheating/Plagiarism: Description
(cont.)
 Unauthorized supplying of information
 Providing copy: Giving a copy of a file to someone
 Providing access:

Putting material in unprotected directory
 Putting material in unprotected code repository (e.g., Github)
– Or, letting protections expire
 Applies to this term and the future
 There is no statute of limitations for academic integrity violations

 Collaborations beyond high-level, strategic advice

 Anything more than block diagram or a few words
 Code / pseudo-code is NOT high level
 Coaching, arranging blocks of allowed code is NOT high level
 Code-level debugging is NOT high level

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 24

 Carnegie Mellon

Cheating/Plagiarism: Description
 What is NOT cheating?
 Explaining how to use systems or tools
 Helping others with high-level design issues
High means VERY high
 Using code supplied by us
 Using code from the CS:APP web site
 Using books from the library, Unix manpages, other published material
 Except the “Solutions Manual for CS:APP”
 Using general online references
 OK: The GNU C Library Manual, Beej’s Guide to C, cplusplus.com
 Not OK: searching for “213 malloc solution”

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 25

 Carnegie Mellon

Cheating/Plagiarism: Attribution
 If you copy code (that you’re allowed to copy),
you MUST credit the author
 Starter code: No
 Any other allowed code (course, CS:APP, etc): Yes
 Indicate source, beginning, and end
 Here’s what it should look like:
/** Hash a 4-byte integer.
* This is the “6 shifts” function from
*
https://burtleburtle.net/bob/hash/integer.html
* (second from the top on that page)
*/
uint32_t hash( uint32_t a)
{
a = (a+0x7ed55d16) + (a<<12);
// ...
}
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 26
 Carnegie Mellon

Cheating: Consequences
 Penalty for cheating:
 Best case: -100% for assignment
 You would be better off to turn in nothing
 Worst case: Removal from course with failing grade
 This is the default
 University-level involvement (from notification to serious things)
 Loss of respect by you, the instructors and your colleagues
 If you do cheat – come clean asap!

 Detection of cheating:
 We have sophisticated tools for detecting code plagiarism
 In Fall 2015, 20 students were caught cheating and failed the course.
 Some were expelled from the University
 In January 2016, 11 students were penalized for cheating violations that occurred as far back as Spring 2014.
 In May 2019, we gave an AIV to a student who took the course in Fall 2018 for unauthorized coaching of a Spring
2019 student. His grade was changed retroactively.

 Don’t do it!
 Manage your time carefully
 Ask the staff for help when you get stuck
 We will help you! We will give you extensions! We want you to succeed.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 27
 Carnegie Mellon

Cheating Notes
 We have written over 100 letters for cheating
cases
 Don’t add to this total
 Some have been for years earlier

 Your work is sophisticated enough that there

are many different solutions
 Things that look the same are very suspicious
 If you do your own work and commit regularly, your work is unique

 We use PhD-level research to detect

similarities
 Inputs include: multiple tools, online searches, archives of online solutions
such as wdxtub, past semester submissions
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 28
 Carnegie Mellon

Some Concrete Examples:

 This is Cheating:
 Searching the internet with the phrase 15-213, 15213, 213, 18213, 513,
malloclab, etc.
 That’s right, just entering it in a search engine
 Looking at someone’s code on the computer next to yours
 Giving your code to someone else, now or in the future
 Posting your code in a publicly accessible place on the Internet, now or in
the future
 Hacking the course infrastructure
 This is OK (and encouraged):
 Googling a man page for fputs
 Asking a friend for help with gdb
 Asking a TA or course instructor for help, showing them your code, …
 Looking in the textbook for a code example
 Talking about a (high-level) approach to the lab with a classmate
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 29
 Carnegie Mellon

How it Feels: Student and Instructor

 Fred is desperate. He can’t get his code to work and the
deadline is drawing near. In panic and frustration, he searches
the web and finds a solution posted by a student at U.
Oklahoma on Github. He carefully strips out the comments
and inserts his own. He changes the names of the variables
and functions. Phew! Got it done!
 The course staff run checking tools that compare all submitted
solutions to the solutions from this and other semesters, along
with ones that are on the Web.
 Remember: We are as good at web searching as you are
 Meanwhile, Fred has had an uneasy feeling: Will I get away
with it? Why does my conscience bother me?
 Fred gets email from an instructor: “Please see me tomorrow
at 9:30 am.”
 Fred does not sleep well that night
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 30
 Carnegie Mellon

How it Feels: Student and Instructor

 The instructor feels frustrated. His job is to help students
learn, not to be police. Every hour he spends looking at code
for cheating is time that he cannot spend providing help to
students. But, these cases can’t be overlooked
 At the meeting:
 Instructor: “Explain why your code looks so much like the code on Github.”
 Fred: “Gee, I don’t know. I guess all solutions look pretty much alike.”
 Instructor: “I don’t believe you. I am going to file an academic integrity violation.”
 Fred will have the right to appeal, but the instructor does not need him to admit
his guilt in order to penalize him.
 Consequences
 Fred may (most likely) will be given a failing grade for the course
 Fred will be reported to the university
 A second AIV will lead to a disciplinary hearing
 Fred will go through the rest of his life carrying a burden of shame
 The instructor would have rather spent that time teaching Fred in office hours!
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 31
 Carnegie Mellon

Why It’s a Big Deal

 This material is best learned by doing
 Even though that can, at times, be difficult and frustrating
 Starting with a copy of a program and then tweaking it is very different
from writing from scratch
 Planning, designing, organizing a program are important skills

 We are the gateway to other system courses

 Want to make sure everyone completing the course has mastered the
material
 Industry appreciates the value of this course
 We want to make sure anyone claiming to have taken the course is
prepared for the real world
 Working in teams and collaboration is an important
skill
 But only if team members have solid foundations
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 32
 Carnegie Mellon

A Scenario: Cheating or Not?

Alice is working on malloc lab and is just plain stuck.
Her code is seg faulting and she doesn't know why. It is
only 2 days until malloc lab is due and she has 3 other
assignments due this same week. She is in the cluster.
Bob is sitting next to her. He is pretty much done.
Sitting next to Bob is Charlie. He is also stuck.
 1. Charlie gets up for a break and Bob makes a

printout of his own code and leaves it on Charlie’s

chair.
 Who cheated: Charlie? Bob?
 2. Charlie finds the copy of Bob’s malloc code, looks it
over, and then copies one function, but changes the
names of all the variables.
 Who cheated: Charlie? Bob?
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 33
 Carnegie Mellon

Another Scenario
Alice is working on malloc lab and is just plain stuck. Her code is
seg faulting and she doesn't know why. It is only 2 days until
malloc lab is due and she has 3 other assignments due this same
week. She is in the cluster.
Bob is sitting next to her. He is pretty much done.
Sitting next to Bob is Charlie. He is also stuck.
 1. Bob offers to help Alice and they go over her code
together.
 Who cheated: Bob? Alice?
 2. Bob gets up to go to the bathroom and Charlie
looks over at his screen to see how Bob implemented
his free list.
 Who cheated: Charlie? Bob?

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 34

 Carnegie Mellon

Another Scenario (cont.)

 3. Alice is having trouble with GDB. She asks Bob
how to set a breakpoint, and he shows her.
 Who cheated: Bob? Alice?
 4. Charlie goes to a TA and asks for help
 Who cheated: Charlie?

 If you are uncertain which of these constitutes

cheating, and which do not, please read the syllabus
carefully. If you’re still uncertain, ask one of the staff

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 35

 Carnegie Mellon

Version Control: Your Good Friend

 Starting with cache lab, labs will be distributed via
GitHub Classroom
 Must be used by all students

 Students must commit early and often

 If a student is accused of cheating (plagiarism), we will

consult
the GIT server and look for a reasonable commit history
 Missing GIT history will count against you

 Please make sure you have one!

 Note: Posting your work for this class in a public Git repo (on
your personal GitHub account, for instance) is considered an
AIV
 You’re making it too easy for other people to copy from you
 Use a private repo shared with specific people if you want to e.g. show your work to a
potential employer
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 36
 Carnegie Mellon

How to Avoid AIVs

 Start early
 Don’t rely on marathon programming sessions

 Your brain works better in small bursts of activity

 Ideas / solutions will come to mind while you’re doing other things
 Plan for stumbling blocks
 Assignment is harder than you expected
 Code doesn’t work
 Bugs hard to track down
 Life gets in the way
 Minor health issues
 Unanticipated events

 Reach out to the faculty! We will help you, give

extensions, etc. Our goal is for you to learn &
Bryant andsucceed, not
O’Hallaron, Computer Systems: be Perspective,
A Programmer’s cops. Third Edition 37
 Carnegie Mellon

Logistics

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 38

 Carnegie Mellon

Education research in this course

 We (faculty) use this course as a basis for formal
research studies into how we can teach more
effectively.
 Nothing we do for research purposes will affect your

grade.
 You have the right to request to be excluded from

the studies.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 39

 Carnegie Mellon

Primary Textbook
 Randal E. Bryant and David R. O’Hallaron,
 Computer Systems: A Programmer’s Perspective, Third Edition (CS:APP3e),
Pearson, 2016
 https://csapp.cs.cmu.edu
 This book really matters for the course!
 How to solve labs
 Practice problems typical of exam problems
 Electronic editions available (Don’t get paperback/international version!)
 On reserve in Sorrells Library

 Note: All textbooks have errors

 Don’t panic if you see something that seems wrong
 Come talk to us about it if you can’t make it make sense

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 41

 Carnegie Mellon

Recommended reading
 Brian Kernighan and Dennis Ritchie,
 The C Programming Language, Second Edition, Prentice Hall, 1988
 Everyone calls this book “K&R”
 Guide to C by the designers of the language
 Well-written, concise
 A little dated
 Doesn’t cover additions to C since 1988 (that’s thirty years ago…)
 Casual about issues we consider serious problems now
 On reserve in Sorrells Library

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 42

 Carnegie Mellon

If you want more books about C

 C for Programmers with an introduction to C11
 Paul and Harvey Deitel
 Opposite of K&R: modern, verbose
 Lots of worked-out examples
 Ugly code style (compare readability to K&R)
 21st Century C
 Ben Klemens
 Supplement to full C textbooks: goes into the corners of the language
 Opinionated
 First half is about how to build C programs in the Unix environment
 So, if you want to understand the Makefiles we give you…

 Learn C the Hard Way

 Zed A. Shaw
 Extremely opinionated
 Also has lots of worked-out examples
 Only book I can find that takes “undefined behavior” seriously enough
 These books are not on reserve
 The library may still have them, or you can borrow a copy from Weinberg 43
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition
 Carnegie Mellon

Course Components
 Lectures
 Higher level concepts
 In-class quizzes (except 15-513) could tilt you to a higher grade if borderline
 Some lectures include more involved in-class activities
 Labs (8)
 1-2+ weeks each
 Provide in-depth understanding of an aspect of systems
 Programming and measurement
 Written Assignments (best 10 of 12)
 Reinforce concepts. A “midterm” assignment counts double.
 You earn 1/4 of score by grading your peers’ work according to our rubric
 Due Wednesdays at 11:59pm ET with peer grades due the next Wednesday
 Final Exam
 Test your understanding of concepts & mathematical principles
 Covers content from the whole semester
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 44
 Carnegie Mellon

Programs and Data

 Topics
 Bit operations, arithmetic, assembly language programs
 Representation of C control and data structures
 Includes aspects of architecture and compilers

 Assignments
 L0 (C programming Lab): Test/refresh your C programming abilities
 L1 (datalab): Manipulating bits
 L2 (bomblab): Defusing a binary bomb
 L3 (attacklab): The basics of code injection attacks

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 45

 Carnegie Mellon

The Memory Hierarchy

 Topics
 Memory technology, memory hierarchy, caches, disks, locality
 Includes aspects of architecture and OS

 Assignments
 L4 (cachelab): Building a cache simulator and optimizing for locality.
 Learn how to exploit locality in your programs.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 46

 Carnegie Mellon

Virtual Memory
 Topics
 Virtual memory, address translation, dynamic storage allocation
 Includes aspects of architecture and OS

 Assignments
 L5 (malloclab): Writing your own malloc package
 Get a real feel for systems-level programming

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 47

 Carnegie Mellon

Exceptional Control Flow

 Topics
 Hardware exceptions, processes, process control, Unix signals,
nonlocal jumps
 Includes aspects of compilers, OS, and architecture

 Assignments
 L6 (tshlab): Writing your own Unix shell.
 A first introduction to concurrency

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 48

 Carnegie Mellon

Networking, and Concurrency

 Topics
 High level and low-level I/O, network programming
 Internet services, Web servers
 concurrency, concurrent server design, threads
 I/O multiplexing with select
 Includes aspects of networking, OS, and architecture

 Assignments
 L7 (proxylab): Writing your own Web proxy
 Learn network programming and more about concurrency and
synchronization.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 49

 Carnegie Mellon

Lab Rationale
 Each lab has a well-defined goal such as solving a
puzzle or winning a contest

 Doing the lab should result in new skills and

concepts

 We try to use competition in a fun and healthy way

 Set a reasonable threshold for full credit
 Post intermediate results (anonymized) on Autolab scoreboard for glory!

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 50

 Carnegie Mellon

Lab0: C Programming
 You can start now: see 213 schedule page
 It should all be review:

 Basic C control flow, syntax, etc.

 Explicit memory management, as required in C.
 Creating and manipulating pointer-based data structures.
 Implementing robust code that operates correctly with invalid arguments,
including NULL pointers.
 Creating rules in a Makefile
 If this lab takes you more than 10 hours, please
think hard about taking the course.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 51

 Carnegie Mellon

Policies: Lab
 Work groups
 You must work alone on all lab assignments

 Handins
 Labs due at 11:59pm ET
 Electronic handins using Autolab (no exceptions!)

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 52

 Carnegie Mellon

Timeliness
 Grace days
 5 grace days for the semester
 Limit of 0, 1, or 2 grace days per lab used automatically
 Covers scheduling crunch, out-of-town trips, illnesses, minor setbacks
 Lateness penalties
 Once grace day(s) used up, get penalized 15% per day
 No handins later than 3 days after due date
 Catastrophic events
 Major illness, death in family, …
 Fill in form (link on Piazza) to request more time
 Formulate a plan (with your academic advisor) to get back on track
 Advice
 Once you start running late, it’s really hard to catch up
 Try to save your grace days until the last few labs
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 53
 Carnegie Mellon

Facilities
 Labs will use the Intel Computer Systems Cluster
 The “shark machines”
 linux> ssh shark.ics.cs.cmu.edu

 Servers donated by Intel for 213/513

 Login using your Andrew ID and password
 Storage shared with general-purpose Andrew clusters (AFS)

 Please don’t use the general-purpose Andrew clusters for 213 work

They get overloaded
 They don’t have the right compilers
 You can try to do the labs on your local machine
 But it probably doesn’t have the right compilers either
 make submit definitely won’t work
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 54
 Carnegie Mellon

Autolab
(https://autolab.andrew.cmu.edu)
 Labs are provided by the CMU Autolab system
 Project page: http://autolab.andrew.cmu.edu
 Developed by CMU faculty and students
 Key ideas: Autograding and Scoreboards

Autograding: Providing you with instant feedback.
 Scoreboards: Real-time, rank-ordered, and anonymous summary.
 Used by over 3,000 students each semester
 With Autolab you can use your Web browser to:
 Download the lab materials
 Handin your code for autograding by the Autolab server
 View the class scoreboard
 View the complete history of your code handins, autograded results,
instructor’s evaluations, and gradebook.
 View the TA annotations of your code for Style points.
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 55
 Carnegie Mellon

Your grade on autolab is your grade for

the lab
 Even if you got a better grade on the sharks
 Autolab does more stringent tests for some labs
 Screenshots can be faked
 File timestamps can be faked

 Even if you got a better grade earlier

 Don’t submit borderline code over and over
 All labs are calibrated so it’s possible to get 100% consistently

 One more reason to do the labs early!

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 56

 Carnegie Mellon

Autolab accounts
 Students enrolled by Monday Aug 28 have Autolab
accounts
 You must be enrolled to get an account
 Autolab is not tied into the Hub’s rosters
 If you add in, sign up with Google form (check on Piazza)
 We will update the autolab accounts once a day, so check back in 24 hours.
 For those who are waiting to add in, the first lab
(C Programming Lab) is available on the Schedule
page of the course Web site.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 57

 Carnegie
Carnegie Mello
Mellon

Getting Help
 Class Web page:
 http://www.cs.cmu.edu/~213 for 15-213/14-513/15-513
 Complete schedule of lectures, exams, and assignments
 Copies of lectures, assignments, exams, solutions
 FAQ
 Piazza
 Best place for questions about assignments
 We will fill the FAQ and Piazza with answers to common questions
 Be careful about public posts: Remember the AIV policy
 Canvas
 Recorded lectures
 In-class quizzes
 Written assignments

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 58

 Carnegie
Carnegie Mello
Mellon

Getting Help
 Email
 Send email to individual instructors or TAs only to schedule appointments

 Office hours
 TAs: See separate slide for 15-cohort vs. 18-cohort
 Instructors: See course home page

 Walk-in Tutoring
 Details TBA. Will put information on class webpage.

 1:1 Appointments
 You can schedule 1:1 appointments with any of the teaching staff

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 59

 Carnegie Mellon

Recitations
 Begin Friday Sept 1
 You must go to the recitation the registrar put you in

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 60

 Carnegie Mellon

Office Hours
 TA office hours begin next week (week of Sept 4)
 Both in-person and remote (Zoom) will be offered

 Only one or the other, at any particular time

 Schedule will be posted on Piazza

 TAs can spend only 10 minutes per student

 Come prepared – have a specific problem you want to ask about
 Need more time? Schedule a 1:1 session, or come to faculty office hours

 Faculty office hours also begin Sept 4

 Schedule will also be posted on Piazza and the course website

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 61

 Carnegie Mellon

Policies: Grading
 Final Exam (30%)

 Labs (50%): weighted according to effort

 Written Assignments (20%): drop lowest 2 out of 12

 15/20 points from average of the three scores assigned by the peer graders
 5/20 points for completing the peer reviews with constructive feedback

 In-lecture quizzes and activities are NOT graded

 We may look at whether you did the quizzes, for curving only

 Final grades based on a straight scale (90/80/70/60)

with a small amount of curving
 Only upward
Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 62
 Carnegie Mellon

Bootcamps
 Bootcamp #1
 Linux, the Command Line and Git
 Sunday Sept 3
 Bootcamp #2
 Debugging Fundamentals & GDB
 Sunday Sept 10
 Bootcamp #3
 GCC & Build Automation (makefiles)
 See schedule page on the web

 More bootcamps listed on the schedule page on the

web

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 63

 Carnegie Mellon

Waitlist questions
 15-213: Amy Weis ([email protected])
 15-513: Amy Weis ([email protected])

 14-513: INI Enrollment (ini-

[email protected])

 Please don’t contact the instructors with waitlist

questions.

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 64

 Carnegie Mellon

Managing this course

 Time management is key
 Start early.
 Office hours are basically empty the first few days an assignment is out.
 If you feel pressured, do appropriate risk analysis
 Read the Textbook!
 Come to lecture

 Go to recitation

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 65

 Carnegie Mellon

Welcome
and
Enjoy!

Bryant and O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition 67