SPO600 - Assembly, Loops, 64 Arms Part 1

For this SPO600 lab, we were tasked with writing (or at least combing and building upon) a loop in both x86 and aarch64 that would run 10, then 30 times printing out a small string of text that ended with the instance of the loop (eg 1-10/30) and a new line character. When the loop was lengthened to 30 iterations, the iterations 10 and above were to be split in two, dividing by 10, and placed into the "Loop" string as two separate digits when printed


As Chris had already written a 'hello world' program, our group (Myself, Nick, and Yoav) went about copying the hello word.s code into the loop code and modifying it to print with each iteration of the loop. A harder task that it initially appeared, and that was before we tried to conquer aarch64.

To say this was difficult does not do the stumbling blocks we encountered justice. Our initial troubles were with the .data section of the code, trying to find proper, efficient mathematical way to insert the resulting loop digit bytes into the proper string index locations. That one line took more time to figure out than most of the loop.

Finding the right equation took longer than expected.

When that was solved to our satisfaction, we compiled and received a segmentation fault at (what was then) line 12 for our troubles, this was the index variable (aka where our loop iteration variable was being stored).  Enclosing 'index' in parentheses was the way to go (thank you Starter Kit!), but we still had faults.

After much trial and error going it on our own, gbd showed us that there was a weird variable being stored in the r12 register. So, despite copying the code from Chris' 'hello world' program earlier, we had made a mistake somewhere in our code additions and changes (like assuming all registers will work equally in certain conditions). On a rather Hail Mary move, we switched register from %rcx to %rdx and the fault was corrected.

%rcx does not like. Who knew?

 Thus we had it printing, but not in the right format:
Loop 0Loop 1Loop 2Loop 3Loop 4Loop5Loop 6Loop 7Loop 8Loop 9Loop10.

If the index and rdx conundrum were a challenge, this... this was kryptonite to our moral (and by far the thing we spent the most time working on). Eventually, I came to the conclusion that the new line character wasn't being used because it was being erased/overwritten by the data we were adding to the loop. It turns out, whoops, adding an entire 64bits registry to our already 64bit string-held registry was much more than we needed. Nick, in a moment of programming clarity switched from a full 64 bit to only taking the low byte of the registry (r13b instead of r13) when moving the value into 'index'. Now we had a loop printing out 10 times.  There was much rejoicing.

We don't need no stinkin' 64bits registry!

So now we had one half of one third of the lab done. On to the aarch64 conversion, which itself wasn't too problematic, simply switch most of the register and variable/values to the opposite of x86_64.

I mean, not too problematic outside of finding a replacement in aarch64 Assembler for storing 'index', since we no longer had the syntax of 'r_b' to work with. This necessitated more trial and error (add, str) until we used 'strb', because we like to inflict mental pain on ourselves during the learning process.

However, despite a 'hello world' example, and there being three of us, none of notices that we needed to change how our 'msg' was stored in a register. So we were stuck with odd segmentation faults that looped and printed out ten times, but it was displaying "qemu: Unsupported syscall: 0" ten times, which is pretty close to what we wanted. A letter or two off really. It wasn't until later that Nick realized our mistake and swapped the 'mov' we had been trying with an 'adr', thus at least solving the first part of the lab.

loop:
mov x27, x28
add x27, x27, 0x30 /* convert to ascii */
--> adr x26, msg

I will post the rest (30 iteration loop, remove leading zero, my thoughts on Assembler) in a second post just to keep things a decent length