COS 217: Introduction

to Programming
Systems
Spring 2008 (MW 10:00-10:50 in CS 105)
Professor Jennifer Rexford

Preceptors: Bob Dondero (lead) and Tom

Jablin
http://www.cs.princeton.edu/courses/archive/
spring08/cos217/ 1
Goals for Today’s Class
• COS 217 overview
– Goals of the course
– Introductions
– Learning the material
– Course grading
– Academic policies

• Getting started
– Modularity/Interfaces/Abstraction
– C Programming: How C differs from Java
– Getting input and providing output
http://www.cs.princeton.edu/courses/archive/spring08/cos217/ 2
Goals of COS 217
• Understand boundary between code and
computer
– Machine architecture
– Operating systems
– Compilers

• Learn C and the Unix development tools

– C is widely used for programming low-level systems
– Unix has a rich development environment
– Unix is open and well-specified, good for study &
research

• Improve your programming skills

– More experience in programming
– Challenging and interesting programming assignments
3
– Emphasis on modularity and debugging
Introductions
• Jennifer Rexford (professor)
– Room 306 in Computer Science Building
– jrex@cs.princeton.edu

• Bob Dondero (lead preceptor)

– Room 206 in Computer Science Building
– rdondero@cs.princeton.edu

• Tom Jablin (preceptor)

– Room 213 in Computer Science Building
– tjablin@CS.Princeton.EDU

• Donna O’Leary (administrator)

– Room 410 in Computer Science Building
– doleary@cs.princeton.edu 4
Learning the Material: Tuning In
• Lecture
– Goal: Introduce concepts and work through examples
– When: MW 10:00-10:50 in CS 105
– Slides available online at course Web site

• Precept (required attendance)

– Goal: Demonstrate tools and work through programming
examples
– MW 1:30-2:20, Friend Center 007, Bob Dondero
– TTh 1:30-2:20 Friend Center 111, Bob Dondero
– TTh 3:30-4:20 Computer Science 102, Tom Jablin

• Website - get there from:

http://www.cs.princeton.edu

5
• Mailing List at cos217@lists.cs.princeton.edu
Learning the Material: Books
• Required textbooks
– C Programming: A Modern Approach, King, 1996.
– The Practice of Programming, Kernighan and Pike, 1999.
– ONE OF:
• Online -- Programming from the Ground Up, Bartlett, 2004.
• Preferred -- Computer Systems: A Programmer's
Perspective, Randal E. Bryant and David R. O'Hallaron,
Prentice-Hall 2003.
• Highly recommended
– Programming with GNU Software, Loukides and Oram, 1997.
• Optional (available online)
– IA32 Intel Architecture Software Developer's Manual, Volumes
1-3
– Tool Interface Standard & Executable and Linking Format
– Using as, the GNU Assembler
• Other textbooks (on reserve in the Engineering Library)
– The C Programming Language (2nd edition), Kernighan and
Ritchie, 1988.
– C: A Reference Manual, Harbison and Steele, 2002. 6
– C Interfaces and Implementations, Hanson, 1996.
Learning the Material: Doing
1. A “de-comment” program
2. A string module
3. A symbol table abstract data type (ADT)
4. A heap manager
5. UNIX commands in AI-32 assembly language
6. A buffer overrun attack
7. A UNIX shell

7
Facilities for Programming
• Recommended options: OIT “hats” LINUX cluster
– Friend Center 016 or 017 computer, secure shell to “hats”,
or
– Your own PC, secure shell to “hats.princeton.edu” (Linux)
– Why: common environment, and access to lab TAs

• Other option: on your own PC (not recommended;

reasonable only for some parts of some
assignments):
– Running GNU tools on Linux, or
– Running GNU tools on Windows, or
– Running a standard C development environment

• Assignments are due Sundays (typically) at 9:00PM

• Advice: start early, to allow time for debugging
(especially in the background while you are doing
other things!)… 8
Why Debugging is Necessary…

9
Grading
• Seven programming assignments (60%)
– Working code
– Clean, readable, maintainable code
– On time (penalties for late submission)
– Final assignment counts double (15%)
• Exams (30%)
– Midterm
– Final
• Class participation (10%)
– Precept attendance is mandatory

10
Policies
www.cs.princeton.edu/courses/archive/spring08/cos217/policies.html

Programming in an individual creative process much like

composition. You must reach your own understanding of the
problem and discover a path to its solution. During this time,
discussions with friends are encouraged. However, when the
time comes to write code that solves the problem, such
discussions are no longer appropriate - the program must be
your own work. If you have a question about how to use some
feature of C, UNIX, etc., you can certainly ask your friends or
the teaching assistants, but do not, under any circumstances,
copy another person's program. Letting someone copy your
program or using someone else's code in any form is a
violation of academic regulations. "Using someone else's
code" includes using solutions or partial solutions to
assignments provided by commercial web sites, instructors,
preceptors, teaching assistants, friends, or students from any
previous offering of this course or any other course. 11
Any questions before we
start?

12
Modularity/Abstraction/Interfaces

Client Interface Implementation

- universal remote - cathode ray tube
- volume - electron gun
- change channel - Sony Wega 36XBR250
- adjust picture - 241 pounds, $2,699
- decode NTSC, PAL
signals
13
Modularity/Abstraction/Interfaces

Interface Implementation
Client - gas plasma monitor
- universal remote
- volume - Pioneer PDP-502MX
- change channel - wall mountable
- adjust picture - 4 inches deep
- decode NTSC, PAL - $19,995
signals
Can substitute better implementation without changing client! 14
Software in COS126

Specification 1 Person
102 Lines of Code
1 Type of Machine
Design 0 Spec Modifications
1 Week
Programming

Debugging

Testing

15
Software in the Real World

Specification Lots of People

106 Lines of Code
Lots of Machines
Design Lots of Spec Modifications
1 Decade or more
Programming

Debugging

Testing

16
Good Software is Modularized
• Understandable
– Well-designed Write code in modules
– Consistent with well-defined interfaces
– Documented

• Robust Write code in modules

– Works for any input and test them separately
– Tested

• Reusable Write code in modules

that can be used elsewhere
– Components

• Efficient Write code in modules

– Only matters for 1% and optimize the slow ones
17
System Interfaces/Abstraction

Applications

O perating System
Software
Com piler Firm w are
Instruction Set Architecture
Instruction Set Processor I/O System
Datapath & Control
Digital Design
Hardware Circuit Design
Layout

More than 99.5% of Linux OS code goes through a compiler…

Almost 100% of application code…
Figure Source H&P
The C Programming Language
• “C has always been a language that never attempts
to tie a programmer down.”
• “C has always appealed to systems programmers
who like the terse, concise manner in which
powerful expressions can be coded.”
• “C allowed programmers to (while sacrificing
portability) have direct access to many machine-
level features that would otherwise require the
use of Assembly Language.”
• “C is quirky, flawed, and an enormous success.
While accidents of history surely helped, it evidently
satisfied a need for a system implementation
language efficient enough to displace assembly
language, yet sufficiently abstract and fluent to
describe algorithms and interactions in a wide
variety of environments.” – Dennis Ritchie 19
The C Programming Language
• Systems programming language
– Originally used to write Unix and Unix tools
– Data types and control structures close to most
machines
– Now also a popular application programming language

• Pros and cons

– Can do whatever you want: flexible and efficient
– Can do whatever you want: can shoot yourself in the
foot

• Notable features
– All functions are call-by-value
– Pointer (address) arithmetic
– Simple scope structure
– I/O and memory management facilities provided by
libraries

• History
– BCPL  B  C  K&R C  ANSI C 20
1960 1970 1972 1978 1988
Java vs. C
• Abstraction
– C exposes the raw machine
– Java hides a lot of it

• Bad things you can do in C that you can’t do in Java

– Shoot yourself in the foot (safety)
– Others shoot you in the foot (security)
– Ignoring wounds (error handling)

• Dangerous things you must do in C that you don’t in

Java
– Memory management (i.e., malloc and free)

• Good things that you can do in C, but Java makes

you
– Objected-oriented methodology

• Good things that you can’t do in C but you can in

21
Java
Java vs. C
Java C
hello.java: hello.c:
public class hello { #include <stdio.h>
public static void
Progra main(String[] args) { int main(void) {
m System.out.println( printf(“Hello, world\n”);
“Hello, world”); return 0;
} }
}

% javac hello.java % gcc hello.c

Compil % ls % ls
e hello.java hello.class a.out hello.c
% %

% java hello % a.out

Run Hello, world Hello, world
% %

22
Java vs. C, cont’d
Java C
Boolean boolean int
Char type char // 16-bit unicode char /* 8 bits */
Void type // no equivalent void
byte // 8 bits char
Integer short // 16 bits short
types int // 32 bits int
long // 64 bits long
Floating float // 32 bits float
point types double // 64 bits double
#define MAX 1000
Constant final int MAX = 1000;
(enumerations, “const”)
int [] A = new int [10]; int A[10];
Arrays float [][] B = float B[5][20];
new float [5][20];
Bound
// run-time checking /* no run-time check */ 23
check
Java vs. C, cont’d
Java C
Pointer // pointer implicit
int *p;
type in // class variables
class r { struct r {
Record int x; int x;
type float y; float y;
} }
String s1 = “Hello”; char *s1 = “Hello”;
String type String s2 = new char s2[6];
String( “hello” ); strcpy( s2, “hello” );
String
#include <string.h>
concatena s1 + s2
strcat( s1, s2 );
te
Logical &&, ||, ! &&, ||, !
Compare =, !=, >, <, >=, <= =, !=, >, <, >=, <=
Arithmetic +, -, *, /, %, unary - +, -, *, /, %, unary -
Bit-wise 24
>>, <<, >>>, &, |, ^ >>, <<, &, |, ^
Java vs. C, cont’d
Java C
/* comments */ /* comments */
Comments
// another kind
{ {
statement1; statement1;
Block
statement2; statement2;
} }
=, *=, /=, +=, -=, <<=, =, *=, /=, +=, -=, <<=,
Assignments >>=, >>>=, =, ^=, |=, %= >>=, =, ^=, |=, %=

Function /
procedure foo( x, y, z ); foo( x, y, z );
call
Function
return 5; return 5;
return
Procedure
return; return;
return 25
Java vs. C, cont’d
Java C
if (expression) if (expression)
statement1 statement1
Conditional
else else
statement2; statement2;
switch (n) { switch (n) {
case 1: case 1:
... ...
break; break;
case 2: case 2:
Switch ... ...
break; break;
default: default:
... ...
} }

“goto” // no equivalent goto L;

Exception throw, try-catch-finally /* no equivalent */

26
Java vs. C, cont’d
Java C

int i;
“for” loop for (i=0; i<10; i++)
for (int i=0;i<10;i++)
statement;
statement;
“while” while (expression) while (expression)
loop statement; statement;
do { do {
“do- while” statement; statement;
loop … …
} while (expression) } while (expression)
Terminate
continue; continue;
a loop body
Terminate
break; break;
a loop

27
Standard Input/Output
stdout
stdin program

stderr
• Three standard I/O streams
– In: stdin
– Out (normal): stdout
– Out (errors): stderr

• Binding
– Flexible/dynamic binding of streams to actual devices
or files
– Default binding
• stdin bound to keyboard
• stdout and stderr bound to the terminal screen 28
Standard I/O in C
• Three standard I/O
streams copyfile.c:
– stdin
– stdout #include <stdio.h>
– stderr int main(void) {
int c;
• Basic calls for standard c = getchar();
I/O while (c != EOF) {
– int getchar(void); putchar(c);
– int putchar(int c); c = getchar();
– int puts(const char *s); }
– char *gets(char *s); return 0;
• Use “man” pages }
% man getchar

% a.out < file1 > file2

29
Pipes Connect Output to Input
stdout
stdout
stdin a.out
stdin a.out
stderr
stderr

% a.out < file1 | a.out > file2

% a.out < file1 | a.out | a.out > file2

30
What’s all this good for?
• In the old days…
– Programmers hard-coded input/output devices into
programs
– Hard to program, and hard to port to different I/O
devices

• Along came OS-360 (1964)

– Separate I/O device driver (in OS) from data (in
program)
– A good early example of modularity and data
abstraction
– However, still clumsy to connect output of one
program to input of another

31
What’s all this good for?
stdout
stdin program

stderr
• Unix (early 1970s)
– First OS to have standard I/O redirection and pipes

• Standard I/O redirection

– Write program once
– Same program can be made to work for different
input/output devices at run time

• Good practice of modularity

32
What’s all this good for?
stdout
stdout
stdin program2
stdin program1
stderr
stderr
• Pipes
– Write small programs that specialize in very simple tasks
– Connect lots of smaller programs to make bigger programs
– Makes bigger programs easier to write
– Earliest and best success story of programming with
components

• Standard I/O redirection & pipes: big part of Unix

success
• Good practice of modularity is a learned art 33
Formatted Output: printf
• int printf(char *format, ...);
– Translate arguments into characters according to “format”
– Output the formatted string to stdout

• Conversions (read “man printf” for more)

– %d  integer
– %f  float or double
– %3f  float or double with 3 decimal places
– %% percent

• Examples
– int i = 217;
printf(“Course number is: %d”, i );

34
Formatted Input: scanf
• int scanf(const char *format, ...);
– Read characters from stdin
– Interpret them according to “format” and put them into the
arguments

• Conversions (read “man scanf” for more)

– %d  integer
– %f  float
– %lf  double
– %%  literal %

• Example
– double v;
scanf( “%lf”, &v );
– int day, month, year;
scanf( “%d/%d/%d”, &month, &day, &year);
35
Standard Error Handing: stderr
• stderr is the second output stream for output
errors
• Some functions to use stderr
– int fprintf(FILE *stream, const char *format, ...);
• Same as printf except the file stream
– int fputc(int c, FILE *stream);
• putc() is the same as fputc()
– int fgetc(FILE *stream);
• getc() is the same as fgetc()

• Example
– fprintf( stderr, “This is an error.\n” );
– fprintf( stdout, “This is correct.\n” );
– printf( “This is correct.\n” );
36
Example
#include <stdio.h>
#include <stdlib.h>

const double KMETERS_PER_MILE = 1.609;

int main(void) {
int miles;
double kmeters;
printf(“miles: ”);
if ( scanf(“%d”, &miles) != 1 ) {
fprintf( stderr, “Error: Expect a number.\n”);
exit(EXIT_FAILURE);
}
kmeters = miles * KMETERS_PER_MILE;
printf(“= %f kilometers.\n”, kmeters );
return 0;
}
37
Summary
• The goal of this course:
– Master the art of programming
– Learn C and assembly languages for systems
programming
– Introduction to computer systems

• It is easy to learn C if you already know Java

– C is not object oriented, but many structures are
similar
– Standard I/O functions are quite different from Java’s
input and output

• Next lecture
– Character input and output

http://www.cs.princeton.edu/courses/archive/spring08/cos217/ 38