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 group. 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. Agile teams are prevalent in the industry now, so feel free to collaborate in your groups as much as you want, doing the entire assignment together. Only submit ONE copy for the group.
• 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 unique 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

Learning Outcomes: 1) writing assembly code in the 'nasm' language; 2) writing C code to call 'nasm' functions; 3) writing functions in C; 4) writing programs in 'nasm' that call C functions; and 5) writing programs in C that call 'nasm' functions

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 and write the result to port stdout.
2. Copy your program from the previous problem to a new file called findGCDfunc.nasm. Change the code 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 new function. Use the assert() functions from the C assert library to test that your GCD finder code is working properly. You can link the assert library into your program by using #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 from the byte in question.
   Write a nasm function 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. Note that if there is an even number of ones, your program will print a 1 and if there is an odd number it will print a 0.
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.c that will determine whether your computer is big-endian or little-endian as was discussed in class.
5. Building on the previous problem, write a C function makeNBOC.c that takes a number as an argument, checks to see if the order needs to be swapped to make Network Byte Order, and swaps its byte order, if necessary. Modify a copy of your previous program from problem 4, whichendisup.c, to make a function that will determine the byte order and if it will need to be swapped. You can also research the hton() and ntoh() functions to do the swapping [if you like]. Write a test program makeNBOtest.c to call your new function and display the results of the function call on stdout using printf().
6. Finally, create a nasm program called makeNBON.nasm which does the byte order swapping BY CALLING YOUR C function from problem 5. Make your nasm program call the function at least five times with different values to test it.