The goal of the project is to gain more familiarity with C by writing several utility functions that will be useful for two future projects, a Disassembler and an Assembler.

You may work on this project individually or in groups of two.

• Clone the Encoding/Decoding Names Project: Clone the Encoding/Decoding Names repository from Kit. (Don't forget to rename the directory to something more meaningful, e.g., encodeDecode or enDeCode.)

  This repository comes with several files, two of which are incomplete that you will be completing. It also contains a test driver (enDeCodingDriver.c) that is already written for you. (A test driver is a main function written to "drive" tests of other functions.) The repository also contains a REPO_SETUP_TIPS.md file with information about how to compile and run this project.

• Encoding/Decoding Names: The two source files you will modify are instructionNames.c and registerNames.c. The instructionNames.c source file contains stub versions of functions that should turn MIPS instruction names into numeric codes — opcodes (I- and J-format instructions) and funct codes (R-format instructions) — according to this MIPS Instructions Table. Similarly, the registerNames.c source file contains stub versions of functions that should turn register names into register numbers, and vice versa, based on this MIPS Registers Table.

  The functions that go from code numbers to names are quite simple and efficient, using the code numbers as indices into global arrays of instruction or register names.

  The functions that go from names to numbers could be implemented as loops through the possible names, returning the index when a name is found. If you want to challenge yourself further, feel free to come up with a more efficient implementation. (You'll want to use the strcmp function or repeated character comparisons to compare names. Do not compare C strings using the == operator, since that compares the locations of the strings rather than the string contents. In other words, string1 == string2 will only be true when string1 and string2 refer to the same memory location, but not when they are two strings with equivalent content.)

  As you work on the functions in instructionNames.c and registerNames.c, you can repeatedly compile and run the test program to see improved test results. You will need to compile all of the source files together to create a single executable:

      gcc *.c
      ./a.out

  As specified in the syllabus, your program should adhere to the Kalamazoo College CS Program Style Guide and Documentation Standards, including use of the Braces Line Up style pattern.

• Submit the Project: Add your source file to the Git "staging area", commit your changes (don't forget to include the description, i.e., git commit -m "Short message"), and push your changes.

  Remember that you can complete the edit/add/commit/push cycle repeatedly. In fact, pushing versions of your project while it is still under construction is a way to create backups of your work as you go. Following agile development principles, repeatedly Edit, Test, and Add/Commit until the program is done. You can `git push` to Kit as often as you want. (See the [Working with Git Repositories in Kit](http://www.cs.kzoo.edu/CSShared/HelpFiles/Kit/RepositoryAssignments.md) document for more information about writing a program within a Git repository.)

• "Turn In" the Project: When you're done, click on the Turn In button in Kit to signal that your project is ready to grade. (You can still edit/commit/push new changes after clicking on the Turn In button if you think of something you forgot earlier, but if the project has already been graded you will need to submit a Regrade Request in Kit to indicate that the project has been updated. Whether regrade requests are granted depends on the grader's workload and the significance of the project modifications.)