diff --git a/Computer Systems - A Programmer's Perspective.pdf b/Computer Systems - A Programmer's Perspective.pdf new file mode 100644 index 0000000..8fa4072 Binary files /dev/null and b/Computer Systems - A Programmer's Perspective.pdf differ diff --git a/Finals/cse351-10au-final-solution.pdf b/Finals/cse351-10au-final-solution.pdf new file mode 100644 index 0000000..1ed43ff Binary files /dev/null and b/Finals/cse351-10au-final-solution.pdf differ diff --git a/Finals/cse351-10au-final.pdf b/Finals/cse351-10au-final.pdf new file mode 100644 index 0000000..57e821f Binary files /dev/null and b/Finals/cse351-10au-final.pdf differ diff --git a/Finals/cse351-10sp-final-solution.pdf b/Finals/cse351-10sp-final-solution.pdf new file mode 100644 index 0000000..5f9146e Binary files /dev/null and b/Finals/cse351-10sp-final-solution.pdf differ diff --git a/Finals/cse351-10sp-final.pdf b/Finals/cse351-10sp-final.pdf new file mode 100644 index 0000000..5569489 Binary files /dev/null and b/Finals/cse351-10sp-final.pdf differ diff --git a/Finals/cse351-12au-final-solution.pdf b/Finals/cse351-12au-final-solution.pdf new file mode 100644 index 0000000..275d441 Binary files /dev/null and b/Finals/cse351-12au-final-solution.pdf differ diff --git a/Finals/cse351-12au-final.pdf b/Finals/cse351-12au-final.pdf new file mode 100644 index 0000000..855128a Binary files /dev/null and b/Finals/cse351-12au-final.pdf differ diff --git a/Finals/cse351-12sp-final-solution.pdf b/Finals/cse351-12sp-final-solution.pdf new file mode 100644 index 0000000..b3e359c Binary files /dev/null and b/Finals/cse351-12sp-final-solution.pdf differ diff --git a/Finals/cse351-12sp-final.pdf b/Finals/cse351-12sp-final.pdf new file mode 100644 index 0000000..cd10645 Binary files /dev/null and b/Finals/cse351-12sp-final.pdf differ diff --git a/Finals/cse351-13wi-final-solution.pdf b/Finals/cse351-13wi-final-solution.pdf new file mode 100644 index 0000000..437e94c Binary files /dev/null and b/Finals/cse351-13wi-final-solution.pdf differ diff --git a/Finals/cse351-13wi-final.pdf b/Finals/cse351-13wi-final.pdf new file mode 100644 index 0000000..c3862db Binary files /dev/null and b/Finals/cse351-13wi-final.pdf differ diff --git a/Midterms/cse351-10au-midterm-solution.pdf b/Midterms/cse351-10au-midterm-solution.pdf new file mode 100644 index 0000000..eb4ab58 Binary files /dev/null and b/Midterms/cse351-10au-midterm-solution.pdf differ diff --git a/Midterms/cse351-10au-midterm.pdf b/Midterms/cse351-10au-midterm.pdf new file mode 100644 index 0000000..70af571 Binary files /dev/null and b/Midterms/cse351-10au-midterm.pdf differ diff --git a/Midterms/cse351-10sp-midterm-solution.pdf b/Midterms/cse351-10sp-midterm-solution.pdf new file mode 100644 index 0000000..7e1bb91 Binary files /dev/null and b/Midterms/cse351-10sp-midterm-solution.pdf differ diff --git a/Midterms/cse351-10sp-midterm.pdf b/Midterms/cse351-10sp-midterm.pdf new file mode 100644 index 0000000..ada4a96 Binary files /dev/null and b/Midterms/cse351-10sp-midterm.pdf differ diff --git a/Midterms/cse351-11wi-midterm-solution.pdf b/Midterms/cse351-11wi-midterm-solution.pdf new file mode 100644 index 0000000..ad2c1a9 Binary files /dev/null and b/Midterms/cse351-11wi-midterm-solution.pdf differ diff --git a/Midterms/cse351-12au-midterm-solution.pdf b/Midterms/cse351-12au-midterm-solution.pdf new file mode 100644 index 0000000..c838ec6 Binary files /dev/null and b/Midterms/cse351-12au-midterm-solution.pdf differ diff --git a/Midterms/cse351-12au-midterm.pdf b/Midterms/cse351-12au-midterm.pdf new file mode 100644 index 0000000..3755787 Binary files /dev/null and b/Midterms/cse351-12au-midterm.pdf differ diff --git a/Midterms/cse351-12sp-midterm-solution.pdf b/Midterms/cse351-12sp-midterm-solution.pdf new file mode 100644 index 0000000..686e17a Binary files /dev/null and b/Midterms/cse351-12sp-midterm-solution.pdf differ diff --git a/Midterms/cse351-12sp-midterm.pdf b/Midterms/cse351-12sp-midterm.pdf new file mode 100644 index 0000000..38dad27 Binary files /dev/null and b/Midterms/cse351-12sp-midterm.pdf differ diff --git a/Midterms/cse351-13wi-midterm-solution.pdf b/Midterms/cse351-13wi-midterm-solution.pdf new file mode 100644 index 0000000..745d3d1 Binary files /dev/null and b/Midterms/cse351-13wi-midterm-solution.pdf differ diff --git a/Midterms/cse351-13wi-midterm.pdf b/Midterms/cse351-13wi-midterm.pdf new file mode 100644 index 0000000..d045e3b Binary files /dev/null and b/Midterms/cse351-13wi-midterm.pdf differ diff --git a/The_C_Programming_Language_2nd_edition.pdf b/The_C_Programming_Language_2nd_edition.pdf new file mode 100644 index 0000000..2ccecad Binary files /dev/null and b/The_C_Programming_Language_2nd_edition.pdf differ diff --git a/Week 01/01-intro.pdf b/Week 01/01-intro.pdf new file mode 100644 index 0000000..50f053d Binary files /dev/null and b/Week 01/01-intro.pdf differ diff --git a/Week 01/02-memory.pdf b/Week 01/02-memory.pdf new file mode 100644 index 0000000..2c2d26f Binary files /dev/null and b/Week 01/02-memory.pdf differ diff --git a/Week 01/Section/351Section1Slides.pdf b/Week 01/Section/351Section1Slides.pdf new file mode 100644 index 0000000..31549fd Binary files /dev/null and b/Week 01/Section/351Section1Slides.pdf differ diff --git a/Week 01/Section/Cheatsheet-c.pdf b/Week 01/Section/Cheatsheet-c.pdf new file mode 100644 index 0000000..6606ca9 Binary files /dev/null and b/Week 01/Section/Cheatsheet-c.pdf differ diff --git a/Week 01/Section/Cheatsheet-emacs.pdf b/Week 01/Section/Cheatsheet-emacs.pdf new file mode 100644 index 0000000..b67c7e1 Binary files /dev/null and b/Week 01/Section/Cheatsheet-emacs.pdf differ diff --git a/Week 01/Section/Cheatsheet-unix.pdf b/Week 01/Section/Cheatsheet-unix.pdf new file mode 100644 index 0000000..b4d28e1 Binary files /dev/null and b/Week 01/Section/Cheatsheet-unix.pdf differ diff --git a/Week 01/arrays.c b/Week 01/arrays.c new file mode 100644 index 0000000..6df8d4e --- /dev/null +++ b/Week 01/arrays.c @@ -0,0 +1,152 @@ +// Chun-Wei Chen +// CSE 351 +// 04/03/13 + +// These #includes tell the compiler to include the named +// header files, similar to imports in Java. The code for +// these is generally located under /usr/include/, such +// as /usr/include/assert.h. assert.h contains the +// declaration of the assert() function, stdio.h contains +// the declaration of the printf() function, and stdlib.h +// contains the declaration of the malloc() and free() +// functions, all of which are used in the code below. +#include +#include +#include + +// Fill the given array with values. Note that C doesn't +// keep track of the length of arrays, so we have to +// specify it explictly here. +void fillArray(int* array, int len) { + printf("Filling an array at address %p with %d " + "values\n", array, len); + for (int i = 0; i < len; ++i) { + array[i] = i * 3 + 2; + // assert() verifies that the given condition is true + // and exits the program otherwise. This is just a + // "sanity check" to make sure that the line of code + // above is doing what we intend. + assert(array[i] == i * 3 + 2); + } + printf("Done!\n"); +} + +// Structs are simply storage for memory of various types. +// In this case, we are typedef-ing (as in naming) a +// struct containing four integers as FourInts. +typedef struct { + int a, b, c, d; +} FourInts; + +// main() is the entry point of the program. +int main(int argc, char* argv[]) { + // Create a new array capable of storing 10 elements + // and fill it with values using the function declared + // above. Arrays declared in this manner are located on + // the stack, which is where statically allocated (as + // in not at runtime) memory is stored. + int array[10]; + // The "array" that we pass here is actually a pointer + // to a block of memory capable of storing 10 integers. + // array[0] is the first integer in this block of + // memory, array[1] is the second, and so on. Since + // C does not track array lengths, we have to specify + // how many elements the array contains. + // + // TODO(1): What happens if the second argument is set + // to 11 instead? How about 100? 1000? Make sure to set + // the second argument back to 10 when you are done + // testing. + // Answer: Setting the second argument to 11 doesn't give + // segementaion fault. It just accesses another part of the + // already allocated stack space. Setting the second argument + // to 100 or 1000 gives segementaion fault since it has now + // accessed beyond the part of memory that is allocated for the stack. + fillArray(array, 10); + + int value; + // In C, we can take the address of something using the + // & operator. &value is of the type int*, meaning that + // it is a pointer to an integer (as in it stores the + // address in memory of where the actual int is located). + // + // TODO(2): We can actually use the address of the value + // declared here as if it were an array of a single + // element; why is this possible? + // Answer: Since &value is of the type int* and the first + // argument of fillArray also takes an int*, it works fine. + fillArray(&value, 1); + // fillArray should set value to 0 * 3 + 2 = 2. + assert(value == 2); + + // The following creates an instance of FourInts on the + // stack. FourInts is really just an array of four ints, + // although we can refer to the ints stored in it by + // name as well. + FourInts four_ints; + // Set the first int to have a value of 0 and verify + // that the value changed. + four_ints.a = 0; + assert(four_ints.a == 0); + + // Depending on whether or not you like to live + // dangerously, the following is either exciting or + // terrifying. Though &four_ints is of type FourInts* + // (as in a pointer to a FourInts struct), we can + // use a cast to pretend that it is actually an array + // of integers instead. + fillArray((int*) &four_ints, 4); + // We can confirm that fillArray updated the values + // in the FourInts struct: + assert(four_ints.a == 2); + assert(four_ints.b == 5); + assert(four_ints.c == 8); + assert(four_ints.d == 11); + + // In the case that the size of an array is not known + // until runtime, the malloc() function can be used to + // allocate memory dynamically. Memory that is + // allocated dynamically is stored on the heap, which + // is separate from the stack. C is unlike Java, + // however, in that dynamically-allocated memory must + // be freed explicitly when the program is done using + // it via the free() function. malloc() takes a single + // argument, which is the number of bytes to allocate. + // sizeof(int) gives how many bytes an int contains + // (which is four), so sizeof(int) * 5 is 20. + int* heap_array = (int*) malloc(sizeof(int) * 5); + fillArray(heap_array, 5); + // Now that we have finished with the heap-allocated + // array, free() the memory associated with it. + // + // TODO(3): What happens if we remove the free() + // statement below? Try running "valgrind ./arrays" + // after compiling the program both with and without + // it. valgrind is a tool for analyzing how programs + // use memory, which is often invaluable for C and + // C++ programming. + // Answer: Memory leak occurs. When I ran "valgrind ./arrays" + // it shows 20 bytes in 1 blocks are definitely lost. + free(heap_array); + + // TODO(4): Now it's your turn to write some code. + // Using malloc(), allocate a FourInts struct + // dynamically (on the heap) and use fillArray to + // populate it with values. Make sure to free the + // memory when you are done, and use the valgrind + // tool mentioned above to check that there aren't + // any errors. As a "sanity check," add four assert + // statements to verify that the a, b, c, and d + // fields of the FourInts struct are set to what + // you would expect. (Hint, you'll need to use the + // -> operator to access fields of a FourInts* + // variable instead of the . operator). + FourInts* fourInts = (FourInts*) malloc(sizeof(int) * 4); + fillArray((int*) fourInts, 4); + assert(fourInts->a == 2); + assert(fourInts->b == 5); + assert(fourInts->c == 8); + assert(fourInts->d == 11); + free(fourInts); + return 0; +} diff --git a/Week 01/lab0.pdf b/Week 01/lab0.pdf new file mode 100644 index 0000000..8b2a963 Binary files /dev/null and b/Week 01/lab0.pdf differ diff --git a/Week 01/solution-arrays.txt b/Week 01/solution-arrays.txt new file mode 100644 index 0000000..eddfc5a --- /dev/null +++ b/Week 01/solution-arrays.txt @@ -0,0 +1,45 @@ +TODO(1): What happens if the second argument is set to 11 + instead? How about +100? 1000? Make sure to set the + second argument back to 10 when you are done +testing. + + Even if the second argument is too large (i.e. larger + than the array really is), fillArray will write that + many integers to memory, overwriting whatever exists + beyond the bounds of the array. If the second argument + is very + large, it may cause a segfault. + + +TODO(2): We can actually use the address of the value declared + here as if it were an array of a single element; + why is this possible? + +An array in C is just a sequence of pointers to + locations in memory, so in a +very real sense, this + value IS an array of a single element. + +TODO(3): What happens if we remove the free() statement below? + + +The memory will never be freed, resulting in a memory + leak - an area of memory +which has already been + allocated, but cannot be accessed by the running code. + Particularly bad or persistent memory leaks can lead + to a program running out of +memory entirely, so it's + important to avoid this situation by freeing all + the memory you malloc. +Your code for TODO(4) should look something like this: + + +FourInts * ints = (FourInts *) malloc(sizeof(FourInts)); +fillArray((int *) ints, 4); +assert(ints->a == 2); +assert(ints->b == 5); +assert(ints->c == 8); +assert(ints->d == 11); +free(ints); \ No newline at end of file diff --git a/Week 02/03-integers.pdf b/Week 02/03-integers.pdf new file mode 100644 index 0000000..8465c84 Binary files /dev/null and b/Week 02/03-integers.pdf differ diff --git a/Week 02/04-floats.pdf b/Week 02/04-floats.pdf new file mode 100644 index 0000000..288579e Binary files /dev/null and b/Week 02/04-floats.pdf differ diff --git a/Week 02/05-machineprog.pdf b/Week 02/05-machineprog.pdf new file mode 100644 index 0000000..5187009 Binary files /dev/null and b/Week 02/05-machineprog.pdf differ diff --git a/Week 02/Lab1/Makefile b/Week 02/Lab1/Makefile new file mode 100644 index 0000000..9ff8b6a --- /dev/null +++ b/Week 02/Lab1/Makefile @@ -0,0 +1,32 @@ +# +# Makefile that builds btest and other helper programs for the CS:APP data lab +# +CC = gcc +CFLAGS = -O -Wall -m64 -g +LIBS = -lm + +all: btest fshow ishow ptest + +btest: btest.c bits.c decl.c tests.c btest.h bits.h + $(CC) $(CFLAGS) $(LIBS) -o btest bits.c btest.c decl.c tests.c + +fshow: fshow.c + $(CC) $(CFLAGS) -o fshow fshow.c + +ishow: ishow.c + $(CC) $(CFLAGS) -o ishow ishow.c + +ptest: ptest.c pointer.c + $(CC) $(CFLAGS) -Wno-unused-variable -o ptest ptest.c pointer.c + +# Forces a recompile. Used by the driver program. +btestexplicit: + $(CC) $(CFLAGS) $(LIBS) -o btest bits.c btest.c decl.c tests.c + +clean: + rm -f *.o btest fshow ishow ptest *~ + +test: btest ptest + ./btest + ./ptest + diff --git a/Week 02/Lab1/README b/Week 02/Lab1/README new file mode 100644 index 0000000..32a7ec2 --- /dev/null +++ b/Week 02/Lab1/README @@ -0,0 +1,139 @@ +*********************** +The CS:APP Data Lab +Directions to Students +*********************** + +Your goal is to modify your copy of bits.c so that it passes all the +tests in btest without violating any of the coding guidelines. + + +********* +0. Files: +********* + +Makefile - Makes btest, fshow, and ishow +README - This file +bits.c - The file you will be modifying and handing in +bits.h - Header file +btest.c - The main btest program + btest.h - Used to build btest + decl.c - Used to build btest + tests.c - Used to build btest + tests-header.c- Used to build btest +dlc* - Rule checking compiler binary (data lab compiler) +driver.pl* - Driver program that uses btest and dlc to autograde bits.c +fshow.c - Utility for examining floating-point representations +ishow.c - Utility for examining integer representations + +*********************************************************** +1. Modifying bits.c and checking it for compliance with dlc +*********************************************************** + +IMPORTANT: Carefully read the instructions in the bits.c file before +you start. These give the coding rules that you will need to follow if +you want full credit. + +Use the dlc compiler (./dlc) to automatically check your version of +bits.c for compliance with the coding guidelines: + + unix> ./dlc bits.c + +dlc returns silently if there are no problems with your code. +Otherwise it prints messages that flag any problems. Running dlc with +the -e switch: + + unix> ./dlc -e bits.c + +causes dlc to print counts of the number of operators used by each function. + +Once you have a legal solution, you can test it for correctness using +the ./btest program. + +********************* +2. Testing with btest +********************* + +The Makefile in this directory compiles your version of bits.c with +additional code to create a program (or test harness) named btest. + +To compile and run the btest program, type: + + unix> make btest + unix> ./btest [optional cmd line args] + +You will need to recompile btest each time you change your bits.c +program. When moving from one platform to another, you will want to +get rid of the old version of btest and generate a new one. Use the +commands: + + unix> make clean + unix> make btest + +Btest tests your code for correctness by running millions of test +cases on each function. It tests wide swaths around well known corner +cases such as Tmin and zero for integer puzzles, and zero, inf, and +the boundary between denormalized and normalized numbers for floating +point puzzles. When btest detects an error in one of your functions, +it prints out the test that failed, the incorrect result, and the +expected result, and then terminates the testing for that function. + +Here are the command line options for btest: + + unix> ./btest -h + Usage: ./btest [-hg] [-r ] [-f [-1|-2|-3 ]*] [-T