Project Goals:

This project has two objectives — to give you additional experience with C programming, and to complete several utility functions that will be useful for two future projects, a Disassembler and an Assembler.

The utility functions in this program work with three tables that associate names (strings) with integer codes. For example, one of the tables (the MIPS Registers Table) associates a set of register names ("$zero", "$at", "$t0", etc.) with code numbers (0, 1, 8, etc.). The other two tables associate two different sets of instruction names with their own sets of codes. (One set of instructions is known as the "IJ" instructions; the other is known as the "R" instructions.) For now, we don't care what the names or numbers mean, we just want to develop functions that will return either the right code for a given name, or the right name for a given code. In other words, we want to look up a name in a table and return the associated code, or look up a code in the same table and return the name.

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

Steps:

• 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.

• Understanding the Existing Code: Re-read the description of the program above in the Project Goals section and then read the "top-of-file" documentation in the enDeCodingDriver.c test driver. Try compiling and running the program to see what (if anything) it does, compared to what it should be doing.

  Look over the two source files you will modify: instructionNames.c and registerNames.c. The instructionNames.c source file contains two (incomplete) arrays representing the two tables of instruction names (the "IJ" instructions and the "R" instructions). It also has stub versions of functions that should look up instruction names and return numeric codes or look up numeric codes and return instruction names.

  The numeric codes for the IJ instructions are known as "opcodes" (for operation codes), while the numeric codes for R instructions are known as "funct" codes. This explains the function and parameter names in this file.

  Similarly, the registerNames.c source file contains an (incomplete) array of register names and stub versions of functions that should look up register names and return register numbers, and vice versa.

• Encoding/Decoding Names: The first thing to do is to is to fill in the missing entries in the three arrays. You can find the tables with the appropriate IJ and R instruction names and codes in MIPS Instructions Table. You can find the table with the appropriate register names and numbers in MIPS Registers Table. In all three arrays, the numeric code serves as the index into the array for the name. For example, "$zero" is register 0, and so appears at index 0 in the regArray array. lw is an IJ instruction with code 35, and so appears at index 35 in the ijFormatInstructions array. Note that the two instruction arrays will still have a number of empty (zero-length) strings even when you're done, because there are gaps in their codes. The register array, on the other hand, should be completely filled in when you're done, because there are no gaps in that table.

  Next, move on to implement the incomplete functions. The functions that go from code numbers to names are quite simple and efficient, using the code numbers as indices into the 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.)