The following guidelines are expected for all homework submissions:

• All homework must be typed. Homework which is not typed will be returned ungraded and will be subject to the late homework guidelines as set out on the syllabus page. PLEASE DO NOT scribble something on lined paper and rip it out of your spiral notebook — hanging chads went out with the presidential election in 2000.
• I don't care too much about what font you use or how large your margins are; however, you might want to check out a monospaced font for typing code, as it will be easy to see the indentations.
• Speaking of indenting, PLEASE DON'T USE TABS TO INDENT YOUR CODE. Tabs can often get interpreted differently by different computers and applications, and could make code that is nicely formatted on your computer look all over the map on my computer or printer. USE SPACES INSTEAD. You can set up almost every modern text editor to insert spaces whenever you press the TAB key, or you can simply pound the spacebar.
• Work with a partner. I can't stress this enough; part of this policy is don't split up the work – WORK TOGETHER on the assignment; DO NOT DIVIDE UP THE WORK!. Doing assignments this way mimics an industry code development model called pair programming which is part of the Extreme Programming [Agile] software development method. Feel free to collaborate in your pairs as much as you want, doing the entire assignment together. Only submit ONE copy for the both of you.
• DO NOT share your work between groups. Doing so will count as plagiarism. If you wish to discuss solutions with another group over coffee in the Lair, that's fine as long as it is kept at the conceptual and you don't share your code between groups. Each group needs to turn in its own version of the solutions.
• Repeat: you only need to turn in one copy per group.
• Submit your homework through GitHub, in your repository, and be sure to make me a contributor so I have access. I cannot evaluate what I cannot see! If I can't upload to your repo, you will not get an evaluation for the assignment.

Problems for Assignment #6

1. Using a previous homework problem with code from our stanley/penguin language as your guide, write an assembly program using nasm called findGCD.nasm which will find the GCD of the two numbers 3113041662 and 11570925. Read the two numbers from the keyboard at port stdin using the scanf() function from the C standard library and a format string. Write the result to port stdout using the printf() function from the C standard library and a different format string.
2. Change the program from the previous problem to be a nasm function which is able to be called from a C program. Then write a program gcdFinder.c containing the code in C to call your function. Use the assert() functions from the C library. You can link this into your program by #include <assert.h> as you've seen in class. Your assembly code should take the two numbers as arguments which are passed from the C code.
3. Parity is a term which is applied when counting the number of bits that are set to 1 in a sequence of bits. It is used to help guarantee that nothing has gone wrong with the bit sequence during transmission. Parity is calculated based on the number of 1 bits in a byte, and a ninth bit, the parity bit, is either set or cleared to achieve the proper parity, either even or odd. For example, for the byte 01101001, assuming even parity, the parity bit would be cleared so that the count of 1 bits remains even for all nine bits; for the byte 10101110, assuming even parity, the parity bit would be set so that the count of 1 bits remains even. Note that the parity bit IS NOT PART of the byte, IT IS A NINTH BIT which is separate.
   Write a nasm program called paritygen.nasm that will count the one bits in a byte of data and print the proper value for the parity bit assuming we are using odd parity. Use a call to the printf() C function to display the result. You may use whatever number you wish, hard-coded into your program, just make sure there are a few bits that are "1" in it somewhere. All-zero or all-one values are probably not the best to use…
4. In networking, it is necessary to make sure that bytes are transimitted in the proper order so the receiving device can interpret them correctly. This requires that big-endian and little-endian values are converted to something called Network Byte Order before they are transmitted. For this problem, write a C program whichEndIsUp.cthat will determine whether your computer is big-endian or little-endian.
5. Building on the previous problem, write a C function makeNBOC.c that takes an unsigned integer as argument and puts it into network byte order, then returns the result. You can include your code from the previous problem as a function in your file as well. Then in another file, make a program in C called makeNBOCtest.c that reads an UNSIGNED 32-BIT INTEGER number from the command line arguments and swaps its byte order by calling your new function from the other file. You only need to swap the byte order if that is necessary. NOTE: at the last minute, I realized that you should NOT have a main() method in the function file, only in the test program file, so don't do that or it will play havoc with the next problem. Also note the name change on the function file from makeNBO.c to makeNBOC.c.
6. Finally, create a nasm program called makeNBO.nasm which does the byte order swapping BY CALLING YOUR C function. Make your nasm program call the function at least five times with different values to test it. Feel free to hard-code whatever values you wish in the program, but try to use values that you can easily see the swapping occur. Usually hexadecimal values are best for this.