Skip to main content

Loops in Assembly Architectures (Lab 3)

The modern C and C++ languages are often taken for granted for their simple syntax and compiler intuition. In Assembly, every variable and value are stored in registers, simple output lines are multiple statements in length, and a number can only be 0 to 9. Below I examine two different architectures, X86_64 and aarch64:


x86_64

The loop I have created that outputs Loop: number thirty times can be found here. Writing this was extremely difficult, constantly fighting a lack of good documentation and examples online. To write this code I viewed many examples online, wrote pseudo code, and wrote the program in C++ before beginning. Debugging was difficult as the errors given were vague or rididculous at times (no // style commenting comes to mind). The Visual Studio compiler for writing C or C++ for example, is alternatively much more informative and allows for easy: break points, live variable information, and detailed information on error codes. I dislike X86 for the limited amount of available registers but like it for it's simpler syntax.

aarch64

The loop previously mentioned can be found here. I found aarch64 harder to write because of it's complicated syntax and was very grateful I wrote the X86_64 code first as it was simply rewriting it. The debugging in aarch64 converesely is superb and actually offers suggestions on how to fix code (i.e. did you mean...?). aarch64 has many available registers however some syntax issues are strange as although x (register#) works in most cases it sometimes uses w (register#) for some lines. I found it not too time consuming to write this however I did get stuck on the division for a little while due to the unneccessarily complicated syntax.


In conclusion, for the amount of time it took to write in assembly the pros of smaller size and faster compile time are not worth the frustration of writing it. This lab however was an excellent experience for seeing how the compiler interprets code from higher level languages.  

Comments

Popular posts from this blog

Final Project Part 02 - Sha1 Function Enhancements

To try to squeeze out a bit more performance I attempted to some compiler optimizations. Unfortunately, due to the sheer complexity of the algorithm, I was unable to find other logic complexities to simplify. I tried some loop unrolling to make the compiler have to work a little less, some examples are here below: I made a graph to demonstrate the minute differences this makes in the test vectors below: At most a few millisecond difference is all that can be acquired, and this is only from the finalcount[] array as the digest array produces errors if not compiled in a loop along with other for loops in the code. To test this I simply altered the sha1.c code and ran the make file to see if the vectors passed or failed. As mentioned this is a compiler optimzation, in other words it is completed already, especially at the -O3 level where the benchmarking was done. I would not  recommend this change to be pushed upstream normally due to the insignificant time ch...

Inline Assembler (Lab 7)

Part 1 After given an Inline assembler version of the volume program I made in the last lab, I got some results that shocked me. After running it with the same 500,000,000 sample size It took only 1.2 seconds of computing time, which is better than even the best variant (bit-shifting) of the program I had made by over 50%. I answered some questions below to further my understanding: 1. What is another way of defining variables instead of the (type name register) format? This can be done using normal type variables as the compiler will automatically put values into registers. 2. For the line vol_int = (int16_t) (0.5 * 32767.0); should 32767 or 32768 be used? 32767 should be used because the int will round the value and 32768 is not in the int16_t range. 3. What does __asm__("dup v1.8h,w22"); do? The duplicate simply means copy the int value into a new vector register . This is for SIMD instructions. 4. What happens if we remove : "=r"(in_cursor) ...

Final Project Part 02 - Final Summary

In conclusion, the -O3 flag was the most important discovery with trying to optimize clib. It offered a significant speed up with no interference, and provided the chance to uniform a many times used function, strdup. Overall the function is built extremely well with very advanced logic. Attempting to alter said logic sprouted many errors and warnings and left only simple compiler optimizations such as loop unrolling which made small differences in speed up. Clib as a whole is a great idea, offering many compartmentalized features for the C programming language that programmers could definitely find useful when developing. I hope in the future I can get more involved in writing code for open source projects such as clib whether that be doing optimization work or building from the ground up. This project not only gave me an insight on how these open source projects work but also at real world coding and improvement opportunities. I can honestly say now that I have had some experience ...