Microsoft Word – SU 2021 CSE 2421 Lab6
SU 2021 CSE 2421 LAB 6: Lab 2 Revisited
Assigned: Tuesday, July 13th
Early Due Date: Sunday, July 18th by noon
Due: Monday, July 19th, by 11:30 p.m.
IMPORTANT: READ THESE INSTRUCTIONS AND FOLLOW THEM CAREFULLY.
Objectives:
– combining C language with assembler language programs
– debugging and extending existing C language code
– first x86-64 coding experience
– correctly using different size registers
REMINDERS and GRADING CRITERIA:
This is an individual lab. No partners are permitted.
This is your first attempt as programming in x86-64. Start now! There will be no deadline
extensions for this lab. Plan accordingly.
Every lab requires a Readme file (for this lab, it should be called lab6Readme – use only this
name.). This file must be a simple text file created on stdlinux that includes the following:
∙ Disclaimer:
BY SUBMITTING THIS FILE TO CARMEN, I CERTIFY THAT I STRICTLY ADHERED TO THE
TENURES OF THE OHIO STATE UNIVERSITY’S ACADEMIC INTEGRITY POLICY.
THIS IS THE README FILE FOR LAB 6.
∙ Your name
∙ Total amount of time (effort) it took for you to complete the lab
∙ Short description of any concerns, interesting problems or discoveries encountered, or
comments in general about the contents of the lab
∙ Describe how you used gdb to find work with your C language program if there were
any. Include how you set breakpoints, variables you printed out, what values they had,
what you found.
∙ Describe how you used gdb to find a bug in your x86-64 programs. Include details
with respect to what breakpoints you set what registers you looked at and how you
determined what the bug was.
∙ Did you have to jump between your C language/x86-64 language programs to fix any
bugs?
You should aim to always hand an assignment in on time or early. If you are late, you will receive
75% of your earned points for the designated grade if the assignment is submitted by 11:30 pm the
following day, based on the due date given above. If you are more than 24 hours late, you will
receive a zero for the assignment and your assignment will not be graded at all.
Any lab submitted that does not compile/make – without errors or warnings – and run without seg
faults or exhibit any other major OS errors/faults WILL RECEIVE AN AUTOMATIC GRADE OF
ZERO. No exceptions will be made for this rule – to achieve even a single point on a lab, your code
must minimally build (compile to an executable) on stdlinux and execute on stdlinux without hanging or
crashing, using the following command: make. A seg fault is considered crashing.
LAB DESCRIPTION
1. You will be rewriting lab2 from earlier in the semester. Required file names: bit_encode.c (this file
will be supplied on Piazza no later than 7/14/21 @4PM), create_key.s, rotate_right.s, rotate_left.s,
C2_SMag.s, Makefile. The file create_key.s will contain only a function called create_key(); the file
rotate_right.s will contain only a function called rotate_right(); and the file rotate_left.s will contain
only a function called rotate_left().
2. There is on difference between this lab and lab2: the output will be printing two hex digits
representing values in Sign Magnitude rather than in 2’s complement. Remember binary
representations for positive values are the same no matter the representation. Only negative values
change the binary representation.
3. The function unsigned int create_key() is an x86-64 function that must:
a. prompt for (using the printf() function) and
b. read in each of the 4 digits of the key (using the getchar() function) and
c. return the 8-bit key to the calling function.
d. You must create the 8-bit key from those 4 digits using ONLY the bitwise OR
instruction or ONLY the bitwise OR instruction and a shift instruction. For
example, if the user specifies 0110, then your internal key must be 0110 0110.
Using any other operations to create the key will result in a 50-point reduction in
your score for this lab.
4. The function unsigned_char rotate_right(unsigned char x) and the function
unsigned char rotate_left(unsigned char x) are also x86-64 functions that must be
passed a single hexadecimal value and return to the calling function that value
rotated 1 position right or left, respectively.
5. C2_SMag.s should contain a function unsigned char C2_SMag(unsigned char c)
that converts a two’s complement binary value to Signed Magnitude.
6. I will supply a bit_encode.c file from with main() from which the other functions will be called.
7. The output of your program should be exactly as described in lab 2 for bit_encode1.
8. You must create a Makefile where all will have 2 targets: bit_encode and lab6.zip.
REQUIREMENTS
1. You may only use x86-64 constructs that we have discussed in class, you can find in the slides,
or you can find in the sample x86-64 programs posted on Piazza. Any other x86-64 constructs
will invalidate your lab submission.
2. You must use correct stack frame procedures and conventions.
3. No values in the x86-64 functions of your program may store values on the stack other than with
push/pop.
4. You may declare variables in the main() function of your program that are stored on the stack.
5. You must use all (needful) x86-64 directives.
6. You must use the correct suffix for all data types (instructions and register sizes).
7. You must use 4-byte registers for the return value from getchar(), all create_key() computations
and the value create_key returns to main()
8. You must use 1-byte registers for all rotate_left(), rotate_right(), and C2_SMag() computations
and parameter passing.
9. You must use correct caller/callee saved register conventions.
10. You must call printf() once to prompt for the 4-bit key and getchar() for each bit of the key (i.e.,
4 times) within your assembler program. You can do this with 4 separate calls to getchar() or
you can get some practice at creating a loop. These C-library function calls MUST be made
within your create_key() x86-64 function.
11. You must include the certification header in your .s files
12. You must comment your code!
HELPFUL SUGGESTIONS
1. Don’t forget to use tui reg general when in gdb to see register values.
2. You can use next in gdb when you want do not want to go in to the code of the function being
called (printf, for example).
3. You can use step in gdb when you want do want to go into the code of the function being called.
4. You can reference http://csapp.cs.cmu.edu/public/docs/gdbnotes-x86-64.pdf for several other
very helpful gdb instructions for x86-64 use.
LAB SUBMISSION
You must submit all your lab assignments electronically to Carmen in .zip file format. You must create
your zip file from within your Makefile.
I highly recommend testing your .zip submission you’ve created prior to submission. If things are
missing, your lab can not be graded, and you will receive a 0 on the lab.
NOTE:
• Your programs MUST be submitted in source code form. Make sure that you zip all the
required files for the current lab (and .h files when necessary), and any other files specified in
the assignment description. Do NOT submit the object files (.o) and/or the executable. The
grader will not use executables that you submit anyway.
• It is YOUR responsibility to make sure your code can compile and run on CSE
department server stdlinux.cse.ohio-state.edu, without generating any errors or
warnings or segmentation faults, etc. Any program that generates errors or warnings
when compile or does not run without system errors will receive 0 points. No
exceptions!
HOW YOUR LAB WILL BE GRADED
Your lab will be tested in the following way:
1. Your code will be tested similarly to how your lab2 was tested. So, go back and review the
spreadsheet for that lab.
2. Your x86-64 code will be inspected to ensure that the requirements listed above were followed.
3. Your readme file will be inspected for answers to the questions asked. So, don’t forget to submit it.