Lecture 01 Introduction
Joseph Haugh
University of New Mexico
Recall a successful programming experience you’ve had?
- Take 5 minutes to answer on an index card/sheet of paper the following:
- Which programming language did you use?
- Briefly describe what was successful about it. Some examples to help you: you found and fixed a difficult bug, you understood your program and it is doing what it was intended to do, you finally got that loop to work as you wanted, you liked the structure and modularity of your program, etc.
Which skills did you show in that successful programming experience?
- Name three (3) skills that helped you to be successful in that experience.
- Take 5 minutes to write down which are those skills on your index card/sheet of paper and then we’ll talk about them.
In general
- Which skills are useful to be successful in programming?
- Are some necessary, which set of them is sufficient?
Do these factors determine a successful programmer?
- The programming language: can you be a good programmer and not be successful in some PLs? does it matter which programming language you use?
- What are the advantages of the C programming language?
CS341L focuses on
- Understanding how programs execute
- Understanding the interactions between HW and SW
- Learning How the Operating System (OS) manages the hardware and some fundamental systems concepts
- Using low-level features of C
- Learning “how things work under the hood”
Learning objectives for today (part 1)
- After this module, students will be able to:
- define what a computer system is and list its components,
- list the topics covered in this course,
- list the issues about the computer representation of data and programs.
Computer Systems
- General definition (from textbook):
- Hardware and systems software working together to run application programs.
- The specific implementations change over time, but the underlying concepts do not change.
Components of a computer system
- Basic Hardware (organization)
- Systems Software (operating system)
Hardware organization
- Buses (transfer words = fixed-size chunks of bytes)
- I/O Devices
- Main Memory
- Processor
- Storage devices form a hierarchy
Operating System
- Manages the hardware
- O.S. concepts
- Processes: running concurrently + context switching
- Threads
- Virtual Memory
- Files
- Network
- Systems communicate with other systems
Programs (object of study)
- Bits + context = information
- Programs are translated by other programs
- Pre-processing
- Compilation
- Assembly
- Linking
- Why should programmers understand compilation? To optimize program performance, to understand linking errors, to avoid security holes.
Abstraction into reality
In this class we travel from the abstract concepts and models of how a computer works down to the details of how those concepts are implemented
In this process we face many challenges which are illustrated in five (5) great realities
Realities of how programs run
- Ints are not integers, floats are not reals
- You must know assembly
- Memory matters
- There is more to performance than what you learned in the analysis of algorithms class
- Computers do more than execute programs
Reading guide for the realities
- At the end there are 12 slides that show examples of these realities (slides 32-43); as you read them, answer:
- can you think of specific examples of each?
- In your experience as a programmer, have you encountered similar problems to the ones described on these slides?
- If there is some reality you cannot illustrate right now, keep it in mind and pay attention to when we cover it in the course.
Course Goals
- Provide a foundational background in key computer systems topics, e.g:
- mapping higher-level languages to assembly language data and control structures
- program performance
- role of programming language and OS tools such as linkers, loaders, libraries, and kernels in executing real programs
- Be able to apply these topics to reason about and discuss/understand new systems
- Gain additional experience writing, debugging, and analyzing C and assembly programs
My Approach to teaching/learning
- Student-centered learning
- Does NOT mean self-taught
- Active learning principles and techniques
- Formative and Summative assessments
- Teach the students (not teach the subject)
Lectures and Lab sessions
- Lectures are twice a week, 1h 15 minutes each time
- Each section has one lab session per week
- Attendance to both lectures and the lab session each week is compulsory
- Start the assignments early
- Material in this course is dense, so you don’t want to fall behind
For you to do
- Study the syllabus carefully, ask questions about it, and make sure you understand it completely
- Course description
- Course policies
- Evaluations + dates
- This is our contract for the semester
Textbooks (Mandatory)
- Randal E. Bryant and David R. O’Hallaron, Computer Systems: A Programmer’s Perspective, Third Edition, Pearson 2016 (http://csapp.cs.cmu.edu)
- Ebook through inclusive access from the UNM bookstore accessible in canvas.unm.edu
- We are NOT using the Mastering platform this semester, it should not be included
Textbooks (Optional)
- Brian Kernighan and Dennis Ritchie, (KRC) The C Programming Language, Second Edition, Prentice Hall, 1988
- Great reference on C, from the creators, but syntax is a little outdated in some constructs
Major Topics covered in CS341L
- Each slide shows the list of topics from a specific area of study in the semester
- Each topic is covered in the textbook:
- Programs and data
- The Memory hierarchy
- Exceptional Control Flow
- Virtual Memory
- I/O, Concurrency, and other
I. Programs and Data
- Ch. 2 (Data representation and manipulation), Ch. 3 (assembly), Ch. 5 Optimizing program performance, Ch. 7 Linking
- Subtopics:
- Computer representation of data (data types)
- Bits operations, arithmetic, assembly language programs
- Representation of C control and data structures in assembly
- Running programs on a system
- Includes aspects of architecture and compilers
II. The Memory Hierarchy
- Chapter 6
- Subtopics:
- Memory technology, memory hierarchy, caches, disks, locality
- Includes aspects of architecture and OS
III. Exceptional Control Flow
- Chapter 8
- Subtopics:
- Hardware exceptions, processes, process control, Unix signals, non-local jumps
- Includes aspects of compilers, OS, and architecture
IV. Virtual Memory
- Chapter 9
- Subtopics:
- Virtual memory, address translation, dynamic storage allocation. (These subtopics were covered for cache memories, add one level to the addressing.)
- Includes aspects of architecture and OS
V. I/O, Concurrency, etc.
- Subtopics:
- High level and low-level I/O
- Internet services, Web servers
- Concurrency, concurrent server design, threads
- I/O multiplexing with select
- Includes aspects of networking, OS, and architecture
- Notions of network programming (usually there is not enough time for this, but the book has a chapter on it)
Index cards
- Acquire and bring a deck of 3 x 5 index cards for lectures, they will be used to:
- Write down muddy points or questions about the topics covered
- Write down your answers to the exercises done during lectures
- Write down a concept that interested you from that lecture
- Hand in your index card at the end of the lecture, you will receive feedback and it counts toward participation.
Muddy points?
- Use the index cards, to write down something that is not clear in today’s lecture, so that we can address it in the next one.
- This applies to all lectures through the semester and counts as participation.
- Welcome and enjoy the class!
Great Reality #1: Ints are not Integers, Floats are not Reals
- Example 1: Is x2 ≥ 0?
- 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) ➙ ??
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
“That’s not what I told it to do!”
for (int i = 0; i < 10; i++) {
printf(“0.%d “, i);
}
printf(“\n”);
for (double i = 0.0; i < 1.0; i += 0.1) {
printf(“%.1f “, i);
}
printf(“\n”);
“That’s not what I told it to do!”
for (int i = 0; i < 10; i++) {
printf(“0.%d “, i);
}
printf(“\n”);
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9
for (double i = 0.0; i < 1.0; i += 0.1) {
printf(“%.1f “, i);
}
printf(“\n”);
0.0 0.1 0.2 0.3 0.4 0.5 0.6 0.7 0.8 0.9 1.0
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!
Great Reality #3: Memory Matters Random Access Memory Is an Un-physical 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
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)
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
And lots of other questions
- “How did he hack my machine?”
- “Why isn’t the compiler’s optimizer making my program any faster?”
- “Why is it saying symbol undefined when I try to compile my program?”
- “Why is my program breaking with multiple threads?”
- “How do I do I/O like accessing the network?”
- “Won’t this just be solved automatically if I just program in (Favorite Programming Language)?”