Week 7/8 Lab Sheet: ARM Assembler Exercises: ROT13 2020/21

Lab Sheet: ARM Assembler Exercises: ROT13

This lab sheet covers exercises of ARM assembler programming, based on a sequence of screencasts discussing a Caesar (ROT13) implementation. Watch this sequence of screencasts before attempting the exercises below, asking for some small changes to the versions that are online as gitlab projects (marked as ). For making these change to the ARM assembler and running it, use the online CPUlator.

Exercise Version 0: Also handle upper case letters in ROT13

The C code in Version 0 of ROT13 only handles lower case letters. Do the exercise, embedded in the C source code for Version 0, to modify the C function rot13_in_c to also handle upper case letters, as we do in later versions of the Assembler code.

Exercise Version 2: Reverse the order of the arguments in calls1.s

In ARM Assembler code of Version 2 , the file calls1.s provides a simple template to call a func- tion using C-calling conventions. Modify the code starting from label testme in calls1.s so that the arguments are passed in reverse order. When running the program you should see

Arguments: one: 5 ; two: 4; three: 3; four: 2; five: 1 Program is done

Exercise Version 3: Return the length of the string as an exit code from the program

As a side-effect of the change from v2, the program in Version 3 no longer returns the length of the string, that has been processed, as a result (returned as the value in R0 when reaching the SWI command at the end). In Version 2 this length was accumulated in R4. But in this version R4 is used and modified in the isalph sub-routine. Modify the code in Version 3 so that the length is kept in one register, and make sure that none of the sub-routines modifies this value. Make this modification and run it in in the CPUlator. Set a breakpoint at the SWI command and check whether the value in R4 is the string length. For the default input expect a string length of 43 (hex 0x2b). You don’t need to execute the SWI in the CPUlator itself: this is likely to fail, because the chipset is slightly different from the RPi2.

Exercise Version 4: Fix the clobbering of registers R4 and R5 by our sub- routine isalph

When executing either Version 3 or Version 4 of the ROT13 code (in rot13_3.s and rot13_4.s), note that the CPUlator gives you warnings about values in registers being “clobbered” by a sub-routine. This is because our sub-routine (isalph) doesn’t adhere to the ARM procedure calling convention. This is mentioned at the end of the screencast for Version 3 of the code. Fix the code in Verison 4 (rot13_4.s), to avoid such clobbering. You’ll need to save the relevant registers on the stack at the beginning of the sub-routine, and restore them at the end of the sub-routine. If

1 Week 7/8 Lab Sheet: ARM Assembler Exercises: ROT13 2020/21 you make the correct changes, the warnings about “clobbering” should disappear in the CPUlator, and, of course, the program should still perform the same ROT13 .

Exercise Version 4: Avoid code duplication after the 2 calls to the sub-routine isalph

Version 4 of the ROT13 code (in rot13_4.s) calls isalph twice, once to check whether the character in R3 is a lower, then if it is an upper case character. The 6 lines of code after the two calls to isalph are duplicated: CMP R5, #0 BEQ norot2 ADD R3, #ROT @ do the rotation operation on the current char CMP R3, R4 BLE norot2 SUB R3, #26

These lines check whether a wrap-around is necessary to keep the character within the alphabet. This is obviously bad style and a source for bugs if further changes need to be made to the code. Modify the code rot13_4.s of Version 4 , by putting the above six lines into a sub-routine, and eliminating the conditional branch instructions, by using a return value to direct the control flow.

Exercise Version 5: Compare the performance of this version with Version 4

The main point of Version 5 is to enhance performance by reducing the number of memory load and store operations. To validate this behaviour, take each of the 2 versions, Version 4 and Version 5, of the code, and run them on the CPUlator. In the window that normally shows the register values, select ’Counters’ as the information to display. For each of the 2 versions take note of the value under ’Simulator core run time (ms)’. This value should be lower for Version 5 compared to Version 4. You may have to use a larger input text, such as the wod3_text in the data area, to achieve high enough runtimes to show a difference.

2