Assigned | Friday, January 13, 2017 at 3:00pm |
---|---|
Prelim Due Date | Thursday, January 19, 2017 at 11:59pm (23:59): At least 3
functions in bits.c implemented and passing all tests
(including proper number of operations). |
Final Due Date | Thursday, January 26, 2017 at 11:59pm (23:59) |
Files | packaged in: lab1.tar |
Video | This video shows how to use the optional helper function print_binary() as well as a few more bit tricks you might find helpful for this lab. |
Submissions | Submit your completed and using the course's Assignments Page. |
The purpose of this assignment is to become more familiar with data at the bit-level representation. You will do this by solving a series of programming “puzzles”. Many of these puzzles may seem artificial, but bit manipulations are very useful in cryptography, data encoding, implementing file formats (e.g., MP3), etc. By working your way through these problems, you will get very familiar with bit representations and hopefully will have some fun. You will also be doing some basic pointer manipulations and pointer arithmetic. Again, the purpose is to get you familiar with data representations and pointers.
You can download lab1.tar
here from a browser.
Use wget
to download from the command line.
In a terminal, run:
wget https://courses.cs.washington.edu/courses/cse410/17wi/labs/lab1/lab1.tar
If you are SSH'ed into klaatu, then you can copy the file directly from the class directory:
cp /courses/cse410/lab1/lab1.tar .
Do note that the final period comes a space after "lab1.tar" and is used to indicate that the destination is the current directory.
Once you have a local copy, extract its contents using the following command:
tar xf lab1.tar
tar
is a file archive utility; the "xf" options mean to extract the file given as an argument.
This should generate a directory next to lab1.tar
called lab1
that contains a number of tools, described later, a bits.c
file, and a pointer.c
file.
bits.c
and pointer.c
contain skeletons for the programming puzzles, along with a comment block that describes exactly what the function must do and what restrictions there are on its implementation.
Your assignment is to complete each function skeleton using:
The intent of the restrictions is to require you to think about the data as bits - because of the restrictions, your solutions won't be the most efficient way to accomplish the function's goal, but the process of working out the solution should make the notion of data as bits completely clear.
Similarly, you will start working with basic pointers and use them to compute the size of different data items in memory and to modify the contents of an array.
This section describes the puzzles that you will be solving in
bits.c
. More complete (and definitive, should there be any
inconsistencies) documentation is found in the bits.c
file
itself.
The table below describes a set of functions that manipulate and
test sets of bits. The Rating column gives the difficulty rating (the
number of points) for each puzzle and the Description column states
the desired output for each puzzle along with the constraints. See the
comments in bits.c
for more details on the desired behavior of the
functions. You may also refer to the test functions in tests.c. These
are used as reference functions to express the correct behavior of
your functions, although they don't satisfy the coding rules for your
functions.
Rating | Function Name | Description |
---|---|---|
1 | bitAnd | Compute x & y using only ~ and |. Hint: DeMorgan's Law. |
1 | bitXor | Compute x ^ y using only ~ and &. Hint: DeMorgan's Law. |
1 | thirdBits | Return an int with every third bit (starting from the least significant bit) set to 1 (i.e. 0100 1001 0010 0100 1001 0010 0100 10012). Hint: Remember the restrictions on integer constants. |
2 | getByte | Extract the nth byte from int x. Hint: Bytes are 8 bits. |
3 | logicalShift | Shift x to the right by n bits, using a logical shift. You only have access to arithmetic shifts in this function. |
3 | invert | Invert (0<->1) n bits from position p to position p+n-1. Hint: Use a bitmask. |
4 | bang | Compute !x without using the ! operator. Hint: Recall that 0 is false and anything else is true. |
The following table describes a set of functions that make use of
the two's complement representation of integers. Again, refer to the
comments in bits.c
and the reference versions in tests.c for more
information.
Rating | Function Name | Description |
---|---|---|
2 | sign | Return 1 if positive, 0 if zero, and -1 if negative. Hint: Shifting is the key. |
3 | fitsBits | Return 1 if x can be represented as an n-bit, two's complement integer. Hint: -1 = ~0. |
3 | addOK | Return 1 if x+y can be computed without overflow. Hint: Think about what happens to sign bits during addition. |
Extra Credit: | ||
4 | isPower2 | returns 1 if x is a power of 2, and 0 otherwise |
We have included two tools to help you check the correctness of your work.
dlc
is a modified version of an ANSI C compiler from
the MIT CILK group that you can use to check for compliance with the
coding rules for each puzzle. The typical usage is:
$ ./dlc bits.c
Note: dlc will always output the following warning, which can be ignored:
/usr/include/stdc-predef.h:1: Warning: Non-includable file <command-line> included from includable file /usr/include/stdc-predef.h.
The program runs silently unless it detects a problem, such as an illegal operator, too many operators, or non-straightline code in the integer puzzles. Running with the -e switch:
$ ./dlc -e bits.c
causes dlc
to print counts of the number of operators
used by each function. Type ./dlc -help
for a list of
command line options.
btest
is a program that checks the functional
correctness of the code in bits.c
. To build and use it, type the
following two commands:
$ make
$ ./btest
Notice that you must rebuild btest
each time you
modify your bits.c
file. (You rebuild it by typing make
.)
You'll find it helpful to work through the functions one at a time,
testing each one as you go. You can use the -f
flag to
instruct btest
to test only a single function:
$ ./btest -f bitXor
You can feed it specific function arguments using the option
flags -1
, -2
, and -3
:
$ ./btest -f bitXor -1 7 -2 0xf
Check the file README for documentation on running the btest
program.
We may test your solution on inputs that btest does not check by default and we will check to see if your solutions follow the coding rules.
Start early on bits.c
, if you get stuck on one problem
move on. You may find you suddenly realize the solution the next day. Puzzle
over the problems yourself, it is much more rewarding to find the solution
yourself than stumble upon someone else's solution. If you do not quite meet
the operator limit don't worry there will be partial credit, but often times
working with a suboptimal solution will allow you to see how to improve it.
Do not include the <stdio.h>
header file in your
bits.c
file, as it confuses dlc and results in some non-intuitive
error messages. You will still be able to use printf in your bits.c
file for debugging without including the <stdio.h>
header, although gcc
will print a warning that you can
ignore.
You should be able to use the debugger on your code. For example:
$ make
gcc -O -Wall -m32 -g -lm -o btest bits.c
btest.c decl.c tests.c
gcc -O -Wall -m32 -g -o fshow fshow.c
gcc -O -Wall -m32 -g -o ishow ishow.c
$ gdb ./btest
GNU gdb (GDB) Fedora (7.1-34.fc13)
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "i686-redhat-linux-gnu".
For bug reporting instructions, please see:
<http://www.gnu.org/software/gdb/bugs/>.
Reading symbols from /homes/iws/dvhc/cse351/lab1/src/btest...done.
(gdb) b bitXor
Breakpoint 1 at 0x8048717: file bits.c
, line 144.
(gdb) r
Starting program: /homes/iws/dvhc/cse351/lab1/src/btest
ScoreRatingErrorsFunction
Breakpoint 1, bitXor (x=-2147483648, y=-2147483648) at bits.c
:144
144}
(gdb) p x
$1 = -2147483648
(gdb) p/x x
$2 = 0x80000000
(gdb) q
A debugging session is active.
Inferior 1 [process 12728] will be killed.
Quit anyway? (y or n) y
The dlc
program enforces a stricter form of C
declarations than is the case for C++ or that is enforced
by gcc
. In particular, in a block (what you enclose in
curly braces) all your variable declarations must appear before any
statement that is not a declaration. For example, dlc
will complain about the following code:
int foo(int x)
{
int a = x;
a *= 3; /* Statement that is not a declaration */
int b = a; /* ERROR: Declaration not allowed here */
}
Instead, you must declare all your variables first, like this:
int foo(int x)
{
int a = x;
int b;
a *= 3;
b = a;
}
This section describes the four functions you will be completing in pointer.c
that is also in the lab1 folder you downloaded. Refer to the file pointer.c
itself for more complete details. You are permitted to use casts for these functions.
The first three functions in pointer.c
ask you to compute the size (in bytes) of various data elements (ints, doubles, and pointers). You will accomplish this by noting that arrays of these data elements allocate contiguous space in memory so that one element follows the next.
The changeValue
function in pointer.c
asks you to change the value of an element of an array using only the starting address of the array. You will add the appropriate value to the pointer to create a new pointer to the data element to be modified.You are not permitted to use [] syntax to access or change elements in the array anywhere in the pointer.c
file.
The last two functions in pointer.c
ask you to determine whether pointers fall within certain address ranges, defined by aligned memory blocks or arrays.
For pointer.c
, we have included a simple test harness: ptest.c. You can test your solutions like this:
$ make ptest
$ ./ptest
This test harness only checks if your solutions return the expected result, not if they meet the specific criteria of each problem. We may test your solution on inputs that ptest does not check by default and we will review your solutions to ensure they meet the restrictions of the assignment.
Note: dlc does not work with pointer.c
For the Preliminary Submission - By the preliminary deadline, we
expect you to have 3 functions of your choice in bits.c
completed
and passing all tests (including using the proper number of
operations). The purpose of this deadline is help you get started
early on the assignment and it will be worth a small-ish number of points
(no more than 10% of the total points for lab 1). Files submitted
that contain at least 3 functions passing the spec will receive
full credit for this stage. We will ignore all
non-functioning/incomplete functions in the file, although please do
ensure that the file will compile and run before submitting. We strongly encourage you to have more of the assignment done — 3 functions is just the minimum.
For the Final Submission - Please submit your completed
bits.c
file and pointer.c
file (*two* separate files). This will be a complete re-grade of
the entire bits.c
file — you are welcome to change anything you
submitted for the preliminary submission.