代写15-213 / 15-503: Introduction to Computer Systems Summer 2025代做Java程序

15-213 / 15-503:

Introduction to Computer Systems

Summer 2025

1    Organization

Class web page:   https://www.cs.cmu.edu/~213/

Canvas:   https://www.cs.cmu.edu/~213/external/canvas

Ed:   https://www.cs.cmu.edu/~213/external/piazza

Autolab:   https://autolab.andrew.cmu.edu/courses/15213-m25

Office Hours:   Please see the class web page for instructor and TA office hours.

Recitations:   Please see the class web page for the list of recitations.

Lectures:

•  15-213 students: Tue, Wed, Thur, Fri, 12:30pm–1:50pm Eastern Time, SH 105

•  15-503 students: Previously recorded videos of lectures will be made available from the course sched- ule page.

2    Objectives

Our aim in the course is to help you become a better programmer by teaching you the basic concepts underlying all computer systems.  We want you to learn what really happens when your programs run, so that when things go wrong (as they always do) you will have the intellectual tools to solve the problem.

Why do you need to understand computer systems if you do all of your programming in high level lan- guages? In most of computer science, we’re pushed to make abstractions and stay within their frameworks. But, any abstraction ignores efects that can become critical. As an analogy, Newtonian mechanics ignores relativistic efects. The Newtonian abstraction is completely appropriate for bodies moving at less than 0. 1c, but higher speeds require working at a greater level of detail.

The following “realities” are some of the major areas where the abstractions you’ve learned in previous classes break down:

1.  Ints are not integers, Floats are not reals.   Our finite representations of numbers have significant limitations, and because of these limitations we sometimes have to think in terms of bit-level repre- sentations.

2.  You’ve got to know assembly language. Even if you never write programs in assembly, The behavior of a program cannot be understood sometimes purely based on the abstraction of a high-level language. Further, understanding the efects of bugs requires familiarity with the machine-level model.

3.  Memory matters. Computer memory is not unbounded.  It must be allocated and managed. Memory referencing errors are especially pernicious. An erroneous updating of one object can cause a change in some logically unrelated object. Also, the combination of caching and virtual memory provides the functionality of a uniform. unbounded address space, but not the performance.

4.   There is more to performance than asymptotic complexity.  Constant factors also matter.  There are systematic ways to evaluate and improve program performance.

5.   Computers do more than execute instructions. They also need to get data in and out and they interact with other systems over networks.

By the end of the course, you will understand these “realities” in some detail.  As a result, you will be prepared to take any of the upper-level systems classes at Carnegie Mellon (both CS and ECE). Even more important, you will have learned skills and knowledge that will help you throughout your career.

In detail, we set forth the following learning objectives, as activities you should be able to do after complet- ing the course:

1.  Explain common bit-level representations of numeric values (unsigned, two’s complement, floating point) and the consequent mathematical properties of arithmetic and bit-level operations on them.

2.  Recognize the relation between programs expressed in C and in assembly code, including the imple- mentation of expressions, control, procedures, and data structures.

3.  Demonstrate ability to understand basic intention of a program through its binary representation and apply these skills to debugging programs.

4.  Investigate the programmer’s interaction with the underlying system through the diferent APIs and abstractions, including system support for process and thread control, virtual memory, and network-ing.

5.  Analyze the consequences of imperfect system usage, such as poor memory and CPU performance, crashes, and security vulnerabilities.

6.  Apply tools, both standard and self-developed, that will aid program development, including compil- ers, code analyzers, debuggers, consistency checkers, and profilers.

7.  Apply these analytic and tool-use abilities to create reliable and e伍cient programs exercising the diferent components of a modern computing system.

8.  Understand the sources of conflict that can arise when multiple threads of execution share resources, and demonstrate the ability to use synchronization constructs to mediate those conflicts.

3    Textbook

The primary textbook for the course is

Randal E. Bryant and David R. O’Hallaron,  Computer Systems: A Programmer’s Perspective, Third Edition (CS:APP3e), Pearson, 2016 (ISBN 0-13-409266-X).

A new paper copy of the textbook currently costs $143.99 if purchased directly from Pearson.   (Note: the supplemental “MasteringEngineering” product is not needed for this course.)  An electronic copy is available for 180-day “rental” for $44.99, or permanent purchase for $74.99, from VitalSource.  The CMU Libraries have electronic copies on reserve for 15-213 students.  Their version is a scan of the paper book, so it may be harder to read than VitalSource’s version, but on the other hand, it’s free.

Used copies of the book may be available from various sources for cheaper than the above prices, but please make sure to get a copy of the third edition.  The first and second editions (published 2003 and 2011) are quite diferent, particularly in their discussion of assembly language programming, and may confuse you.    Please also make sure you are reading the hardcover version of the third edition (ISBN 0-13-409266-X). The paperback version (also sometimes known as the international version) contains a completely diferent set of practice and homework problems, many of which are badly posed or even incorrect.   Amazon’s “Kindle edition” of the book was based on the paperback version and has the same problem.

Bryant and O’Halloran maintain a website for CS:APP containing errata,  additional “Web asides,” and additional reference material for students.

In addition, we expect you to use reference material about the C programming language.  Our suggested reference is:

Brian W. Kernighan and Dennis M. Ritchie,  The C Programming Language, Second Edition, Prentice Hall, 1988.

This is the classic K & R book, the standard against which all reference manuals are compared.  This book should be in the library of anyone who programs in C.  Copies are on reserve in the Sorrells Engineering Library.

4    Course Organization

Your participation in the course will involve these forms of activity:

1.  15-213: Attending the lectures

2.  15-503: Viewing the videotaped lectures

3.  Doing laboratory assignments

4.  Doing written assignments and peer reviewing written assignments

5.  Reading the text

6.  Taking a final exam

Attendance will not be taken at the lectures. You will be considered responsible for all material presented at the lectures.

Lectures will typically cover higher-level concepts, though there may also be times that are applied, covering important “how-to’s”, especially in using tools that will help you do the labs.

The textbook contains both practice problems within the chapter text and homework problems at the end of each chapter.  The intention is that you work on the practice problems as you are reading the book.

The answers to these problems are at the end of each chapter.  Our experience has been that trying out the concepts on simple examples helps make the ideas more concrete. Try out the practice problems associated with the readings for each class and ask questions about them at the next class.

The only graded assignments in this class will be a set of eight labs and a set of eleven written assignments. Some of the labs are fairly short, requiring just one week, while others are more ambitious, requiring several weeks. The written assignments are 1-3 questions each.

5    Getting Help

We will use the class website (https://www.cs.cmu.edu/~213/) as the central repository for all information about the class.

For technical (lectures, assignments, exam) or logistics (accounts) questions, post a question on ed.  By default, any question you post will be private to you and the instructors. We will put posts on ed and in the FAQ web page answering some common questions. Be sure to check these before contacting an instructor.

The labs are ofered through a hosted autograding service, developed by Dave O'Hallaron and a group of CMU undergrads, called Autolab. See the Autolab web page at https://autolabproject.com/.

If you want to talk to a staf member in person, the posted o伍ce hours are the best opportunity, as they represent times when we guarantee that we will be available to meet, either in the location identi  ed or via Zoom. If a meeting is needed outside of the o伍ce hours, please use email to arrange a time.

6    Policies

6.1    Working Alone on Assignments

You will work on all assignments by yourself.

6.2    Version Control

We will be using GitHub Education for you to work on labs, with pre-populated directories for labs 4–8. The GIT repositories are private and will be deleted after the end of the semester.  You will have a chance to download their contents before they will be deleted.  We will explain the proper usage of the server and help with setting up the server via ed posts, in o伍ce hours and during the recitations. In general, you should work as follows:

• Add all of the provided source   les in your lab assignment upon downloading them from Autolab and commit the initial version.  Source   les include any code (extensions  `.c',  `.h',  `.pl',  `.py', and `.sh'), as well as any Make  le and any program input    le. It does not include any compiled libraries or reference programs.

• Commit early and often.  Make it a habit to commit at least every hour you work actively on the assignment, and commit in small increments. Commit at the end of your work day.

• Make sure you commit your   nal version right before you submit via Autolab.

It is good software engineering practice to use version control, and learning it before starting Lab 1 is a a good idea.  We may review commit statistics on the server and reach out to students who disregard our version control policy.

6.3    Handing in Assignments

All assignments are due at 11:59pm Eastern Time on the specified due date. All programming handins are electronic using the Autolab system. Note that Autolab may convert the deadline into your local time, you are still responsible for submitting before the deadline.  You may hand in labs as often you like, with your most recent handin counting for credit.

Written Assignments

Written assignments will be submitted using Canvas, and are due by the due date.  There are no late sub- missions and Canvas will generally just accept one submission. Please be aware of these restrictions when working on your submission and your peer reviews.

Late Programming Assignments

The penalty for late assignments is 15% per day. Each student will receive a budget of five grace days for the course. These grace days are provided to allow you to cope with most emergencies that prevent completing a lab on time, including computer problems, a cold, getting stuck at the airport, etc. Here is how grace days work:

• Each lab assignment has a maximum number of grace days that can be applied, ranging from 0 to 2. The grace day limits are indicated on the Assignments web page and in the assignment writeups.

• Grace days are applied automatically until you run out.

• If your last handin is one day late, and you have at least one remaining grace day, then you will receive full credit for the lab and automatically spend one grace day. For example, if an assignment is due at 11:59pm ET on Thursday and your last handin is noon ET on Friday, then you will receive full credit and spend one grace day.

• Once you have spent your grace days, or exhausted the limit for the assignment in question, then you will receive a penalty of 15% for each subsequent late day. For example, suppose you have only one grace day left.  If an assignment is due at 11:59pm ET on Thursday and your last handin is noon ET on Saturday, then you will spend your one remaining grace day and be penalized 15%.  If your last handin is noon ET on Sunday, then you will spend one grace day and be penalized 30%.

• Handins will not be accepted after the end date of the lab, which is typically three days after the due date.

Grace days are a tool to allow you to manage your time in the face of personal issues and to help smooth out burstiness in assignment due dates across classes.  They are for when you are sick, when a short-term emergency situation arises, when you have too many deadlines all at once, etc. Except for serious persistent personal issues (see below), you should not anticipate additional deadline leniency.  We strongly recom- mend that you conserve your grace days, saving them for the more di册cult assignments at the end of

the term. Grace days and penalties are computed automatically by Autolab, with grace days being used up before penalties are applied. You cannot choose how to distribute your grace days among your assignments.

6.4    Dealing with Serious Persistent Personal Issues

We hope that everyone in the course will remain happy and healthy.  But, if you have a serious persistent personal issue, such as being hospitalized for an extended period or needing to leave the country for a family matter, please talk to your academics advisor as soon as possible. Such issues consistently afect one’s ability to succeed in all classes, rather than just the course, and the academic advisors are equipped to coordinate plans for dealing with them. We will cooperate with such plans, but we cannot construct them independently of the academic advisors. Please contact your course instructor if you are unable to keep up with the course due to a serious personal issue.  A form will be provided that is checked regularly for extension requests, and extensions are granted in almost all cases when students follow these policies.

6.5    Requesting a Regrade for an Assignment or an Exam

After each lab, written assignment, or exam is graded, your score will be posted on the Autolab gradebook, Canvas, or Gradescope respectively. We will make the utmost efort to be fair and consistent in our grading. But, we are human. If you believe that you did not receive appropriate credit for an assignment or an exam, you may request a regrade as follows:

• Lab or Written Assignment regrade request: Post a regrade request as a private message on Piazza. Provide a detailed explanation of why you believe your grade did not conform to the posted grading standard, this includes cases where your final submission autograded worse than expected, so always verify your submissions.

• Exam regrade request:  All exam regrades must be completed using the exam system (typically, Gradescope).

• Verbal and email requests will NOT be accepted.

• All regrade requests must be received within seven days of the grades becoming available.

Your request will be processed of-line, and we will respond to your request as quickly as possible (typically within a week). This regrade policy is designed to correct legitimate mistakes in grading, while discouraging frivolous regrade requests (for the sake of being fair and consistent across the entire class).

6.6    Final Grade Assignment

Each student will receive a numeric score for the course, based on a weighted average of the following:

• Labs (50%): There are a total of eight labs, which will count a combined total of 50% of your score. Labs have diferent weightings, based on our perception of the relative efort required.  See the Labs web page for the lab weightings.

• Written Assignments (20%): There are a total of eleven written assignments, which will be graded by peer review. Your grade on an individual written assignment will be determined by three equally- weighted parts: (i) completed assignment demonstrates some efort, (ii) max score by peer reviewers, and (iii) completion of peer reviews with constructive feedback. We will drop your two lowest written assignment scores. There is a ’midterm’ written assignment that will be graded by the TAs and will count as two separate written scores, such that there will be eleven assignments and twelve scores. After dropping two scores, the remaining ten will count 2% each.

• Exam (30%): There will be a final exam counting 28 or 30%.  15-213 students will have an in-person midterm exam worth 2%, while 15-503 students will only have an in-person final exam for 30%.

The grading cutof points are: 90 (A), 80 (B), 70 (C), 60 (D).

In-class quizzes (except 15-503):  In the middle of many lectures, we will pause a few minutes to have students answer a 2–3 multiple-choice question quiz on the material covered in class.  This will help the instructor gauge which topics need further discussion.  Quiz questions will be answered by each student using Canvas. Student grades on these quizzes will be used solely as “bonus points,” as discussed next.

Bonus points:  We will selectively consider raising individual grades for students just below the cutofs based on factors such as attendance (primary), class participation, improvement throughout the course, final exam performance, and special circumstances. In particular, except for 15-503 students, the in-class quizzes provide a record of lecture attendance and attention, and hence are a good means for a student just below a cutof to have his/her grade raised.