Bit Transfiguration

• Checkpoint: complete at least 5 puzzles by 11:00pm Tuesday, 15 September
• Due: 11:00pm Thursday 17 September
• Starter code: fork wellesleycs240 / cs240-bits (just once!) and add bpw as admin. (Need help?)
• Submissions:
  • Commit and push your final version. (Need help?)
  • Do not submit a paper copy.
• Relevant reading, as needed:
  • CSAPP 2.1.7 - 2.1.10, 2.2 - 2.3
  • K&R 2.7, 2.9
• Collaboration: This assignment follows the standard collaboration policy. You may discuss problems and high-level strategies with other students, but your solutions must be your own work. You must cite anyone with whom you discussed the problems in a comment at the top of the bits.c file.

Contents

• Overview
• Instructions
• Bit Puzzles
• Checking Your Work
• Grading
• Advice

Overview

The purpose of this assignment is to become more familiar with data representation at the bit level. You’ll do this by solving a series of programming “puzzles.” Many of these puzzles may seem artificial, but in fact 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. Hopefully you will have some fun along the way!

The short Integer Arithmancy exercises will help familiarize you with number representations for this assignment.

Instructions

Get the source files for this assignment from the wellesleycs240 / cs240-bits repository, following the same fork-share-clone process described here, as we did in the first lab meeting, but replacing the cs240-lab1 repository with cs240-bits.

Your working copy should contain a number of tools, described later, and a bits.c file containing skeletons for the programming puzzles, along with comment blocks that describe exactly what the functions must do and what restrictions there are on implementation. Your assignment is to complete each function skeleton using:

• only straightline code (i.e., no loops or conditionals);
• a limited number of C arithmetic and logical operators; and
• no constants larger than 8 bits (i.e., 0 - 255 inclusive).

Carefully read the coding rules found in the bits.c file.

The intent of the restrictions is to require you to think about the data as bits – because of the restrictions, your solutions may not be the simplest or 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.

Please skim the entire document before starting to work.

Bit Puzzles

This section describes the puzzles that you will be solving in bits.c. More complete documentation is found in the bits.c file itself.

Bit Manipulations

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.

Two’s Complement Arithmetic

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.

Checking Your Work

We have included a few tools to help you check your work.

dlc: Compliance

dlc is a modified C compiler that you can use to check for compliance with the coding rules for each puzzle. The typical usage is:

$ ./dlc bits.c

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: Testing

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 README file 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.

driver.pl: Combined Testing and Conciseness

The driver.pl tool will both run btest and count the number of operators your solutions, displaying an automatically generated score for each. Here is (part of) the output on our sample solution:

$ ./driver.pl
[ ... status messages omitted here ... ]
Correctness Results     Perf Results
Points	Rating	Errors	Points	Ops	Puzzle
1       1       0       2       4   bitAnd
1       1       0       2       7   bitXor
1       1       0       2       4   thirdBits
2       2       0       2       7   fitsBits
2       2       0       2       4   sign
2       2       0       2       3   getByte
3       3       0       2       14  logicalShift
3       3       0       2       9   addOK
4       4       0       2       6   bang
3       3       0       2       7   conditional
4       4       0       2       11  isPower2

Score = 48/48 [26/26 Corr + 22/22 Perf] (76 total operators)

The “performance” score is based on the number of operators used. Fewer operators = higher score, in a range of 0-2 for each puzzle, but getting the absolute minimum number of operators is not necessary to get the full score. The combined score is not a direct indicator of your grade, but it is useful in estimating how close your solutions are to being correct and optimal. (Remember, it does not test all cases, so there may be others where your code is incorrect. It pays to think about edge cases and run extra tests manually!)

Grading

Your base grade will be derived as follows:

• 70% correctness
• 15% low operator count
• 15% succint and clear comments describing why your implementations work

Comments should demonstrate clearly to the course staff that you understand the series of operations you apply and how and why they work to accomplish the goal. In some cases your comments may be shorter than your code. In some cases they may be longer.

Partial credit may be awarded for partially working solutions or comments describing an intended approach that you did not finish implementing.

Advice

Start early. Try some pencil-and-paper or whiteboard hacking to design your solution before you start typing 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.

Commit often. Each time you get a new function working (or even just closer to working), commit your work. Also push your commits to your Bitbucket repository reasonably often. Then if things go wrong later you can always recover your work.

Number Conversion

The ishow tool lets you display integer representations and conversions. It takes hex or decimal input.

$ ./ishow 0x27
Hex = 0x00000027,	Signed = 39,	Unsigned = 39

Debugging

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.

Variable Declarations

The dlc program enforces a stricter form of C declarations than gcc enforces. 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;
}