Skip to main content

Hello World in Assembly

Photo by Martin Sanchez on Unsplash
Assembly alert! I promised to talk more about the compiler, but before it, more assembly. It is for a good reason, though. I was surprised to see my professor doing the “hello world” in assembly! Not only on x86_64 but also in the ARMv8 – different source code. He coded just like C or C++, saved, compiled and run it. The output was exactly like any other language. Nobody knew, but he was doing the Lab 5! I wish I were recording it.

Our goal in this class was to compare the compiler output with the hand-crafted assembly. As expected, the compiler produced non-optimal executables even when we played with some fine-tuning options that I mentioned in the last post.

How to compile an assembly code? Here are the commands:

- Using GNU Assembler
> as -g -o test.o test.s
> ld -o test test.o

- Using NASM Assembler
> nasm -g -f elf64 -o test.o test.s
> ld -o test test.o

- Using GCC
> gcc -g -o test.o test.S

How to get the assembly code from an executable?
> objdump -d test

Using those tools, we played on both architectures, and the compiler didn’t get any closer than our hand-crafted script. However, I don’t believe that we should start using low-level languages for everything. There are drawbacks to doing so. The major one is the fact that assembly is hardware-oriented. This means that it needs to be rewritten on different platforms. Comparing it with C or C++, you just need to code once and compile it multiple times (one for each platform). So, unless it is a requirement, I would take it as a last resource to improve the performance.

If you want to know more about the used scripts and the assembly language, here are some resources:
https://wiki.cdot.senecacollege.ca/wiki/Assembler_Basics
https://wiki.cdot.senecacollege.ca/wiki/SPO600_64-bit_Assembler_Lab

See you!

Comments

Popular posts from this blog

Project Stage 3

Photo by  NASA  on  Unsplash Hello! In this post, I’ll make a list of optimization opportunities that I identified on the AWK project based on what I’ve learned in the SPO600 classes. There are two types of optimizations: portable and platform-specific. Portable optimizations are the ones that work everywhere, like better algorithms and implementations, and also compiler building flags. Platform-specific, on the other hand, works only for a targeted architecture. Like the SIMD instructions available only on Arch64 and many others specific for x86_64. It is possible to “force” the usage of such instructions according to the targeted hardware. We can do that on compilation time, and also on run-time. Now that we know our options, let’s dig in. According to my previous post , the functions nematch and readrec are the hotspots. Here is the command line used to run the awk: ./awk 'BEGIN {FS = "<|:|=";} {if ($8 == "DDD>") a ++;} END {print "cou...

Going Faster

Photo by  Anders Jildén  on  Unsplash Today’s topic is compiler optimizations. Besides translating our source code into machine binary executable, the compiler, based on optimization parameters, can also produce faster executables. Just by adding some parameters to the compiler, we can get a better performance or a smaller executable, for example. There are hundreds of those parameters which we can turn on or off using the prefix -f and -fno. However, instead of doing one by one, we can use the features mode using the -O param. It ranges from 0 (no optimization – the default) to 3 (the highest). Using those parameters has a cost —usually, the faster, the larger executable. How does the compiler make it faster if my code is perfect? I’m going to put some methods here, but if you want, here is more detail . Also, bear in mind that most of the optimizations are done in the intermediate representation of the program. So, the examples below are rewritten just to...

Project Stage 2

Photo by  SpaceX  on  Unsplash Hey! Were you curious about the results of profiling AWK ? Me too! Quick recap, what is profiling, and how to do it? Profiling is a technique to map the time execution of each part of the application. We can add instrumentation to the executable, or use interruption sampling to generate that map. Here, I’ll use both. Click here for more details on profiling . For the instrumentation, we have to tell the compiler to add the tools needed to collect the execution data. So, I’ve changed the “makefile” file, CFLAGS variable with “-g -Og -pg” and ran the make command. Then, I just ran the awk the same way I did to benchmark it. Here is the command line: ./awk 'BEGIN {FS = "<|:|=";} {if ($8 == "DDD>") a ++;} END {print "count: " a;}' bmark-data.txt This awk version, instrumented, generates a file gmon.out, which contains all execution data. This is the raw material to create a profile report using gp...