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