Tutorial Week 10
In this week we continue what we started last week, namely to familiarise ourselves with RISC-V assembly.
Task 1. Here are some suggestions for writing programs in the RISC-V assembler language.
• Cryptography often works by XORing a stream of data with a stream of keys. Assume that the plaintext is at memory region A, and a key (of the same length as the plaintext) is at memory region B. Assume the beginning of the plaintext data (i.e. memory region A) is held in register a0, the length of the data (i.e. plaintext and password) is in register a1 the beginning of the key is in register a2. Write a RISC-V program that creates a stream of data encrypted data at memory region C, where the i-th word of the encrypted data is the XOR of the i-th word of the key with the i-th word of the data. The results (i.e. ciphertext) should be stored in a memory region starting at the address stored in register a3. If you are interested in the cryptographic background of this (not relevant for the course), it might be interesting to learn about the one-time pad and Counter Mode.
• Write a program that exchanges the content of registers a0 and a1. Can you do this without using a third, temporary register?
• Write a program that prints out the content of register a0.
• Write a program that prints out the content of all RISC-V registers.
• Think of an interesting short program and write it in RISC-V.
Task 2 . Set up the simulator you are using such that you can call it with an a file as argument, and prints out the content of the accumulator a0 upon termination of the input RISC-V code.
Task 3. Here are two little compiled programs. They were compiled using the code generator we discussed in the last few lectures Reverse engineer the programs, i.e. work out the original source programs. The first program is quite similar to the sumto program we analysed in the lecture, the second one is quite well known.
• Program 1.
• Program 2.
I recommend to look for jump-and-link commands jal because they correspond to recursive calls. Try and see where the activation records are constructed and torn down, that tells you how many arguments the procedure takes, and what kind of arguments are supplied. Where is something pushed on the stack, and what? Where/what is popped off?