ARM Assembly Language Tutorial

For some reason, I really keen on using assembly language in Raspberry Pi because it's an entirely new machine architecture for me--despite my past effort on GameBoy Advance (GBA) which results only on HelloWorl application ;). So, interest on ARM is back.

I've been reading a couple of ARM assembly language tutorials so far, but I think the best for complete newbie is this one: http://www.coranac.com/tonc/text/asm.htm. It centered around "guess what?" GBA. It's one of the best that describes GNU assembler on ARM architecture I think.

Another great ARM assembly tutorial was made by the late Fravia: http://www.woodmann.com/fravia/The%20ARM%20Processor.htm. The images links are broken in that link, so just download the ZIP file and view the article locally. That way, the images links would be fine.

Driver Signing for Windows Vista/7/Server 2008/8 (x86 and x64)

Details about driver signing and signing mechanism for other code running in kernel mode privilege in Windows Vista or newer (both x86 and x64) is in this link: http://msdn.microsoft.com/en-us/library/windows/hardware/gg487317.aspx

I observed that x64 versions on Windows have a better kernel mode code authentication enforcement via driver signing compared to the x86 version.

GTK+ Development for Raspberry Pi

After developing GTK+ applications (to run on Raspberry Pi) for more than 2 months, I found that it's much more productive to do most of the development and preliminary testing on my laptop. Once I'm done with the preliminary tests, I transfer the code to Raspberry Pi for native compilation. Most of the time the code runs without a hitch but in several rare occasions, I did find some minor bugs on my code once the code runs on Raspberry Pi. This is one BUG example:

...
GError *error;

// Function that uses "error" variable here
...

The code above runs just fine on my laptop (x64 Linux), but it terminated the program execution in Raspberry Pi complaining that the error variable is not initialized properly. This is the fix:

...
GError *error = NULL;

// Function that uses "error" variable here
...

Simply initializing the variable to NULL makes everything works as expected :-). There are other minor differences, but from what I have code, I can say that even multithread and multiprocess (running child process) code works just fine in Raspberry Pi when using GTK+v3.X (with the accompanying GLib, etc.). Testing the application on the laptop, most of the time mirrors the behavior of the code on Raspberry Pi.

The reason I'm doing this kind of development is simply time. It takes too much time to compile and test the application on Raspberry Pi. The code-test cycle on my Laptop is far faster and more productive. I hope this is also a consideration for those developing GTK+ application for Raspberry Pi.

Raspberry Pi Hardware Support for Thread Synchronization

Hardware support for synchronization in multithreaded application could improve its execution time and responsiveness. The synchronization primitives mostly available in the form of atomic Compare-and-Swap instruction. On x86/x64 architecture, the instruction is called CMPXCHGXX which stands for compare-and-exchange (the XX is only a placeholder because there are several variants of the instruction). On ARM architecture, the support is in the form of the SWP (swap) instruction.

Raspberry Pi CPU supports the SWP instruction. You can see this when you "cat /proc/cpuinfo" as follows:

pi@raspberrypi ~ $ cat /proc/cpuinfo
Processor       : ARMv6-compatible processor rev 7 (v6l)
BogoMIPS        : 697.95
Features        : swp half thumb fastmult vfp edsp java tls
CPU implementer : 0x41
CPU architecture: 7
CPU variant     : 0x0
CPU part        : 0xb76
CPU revision    : 7

Hardware        : BCM2708
Revision        : 000f
Serial          : 00000000231c08f2

As you can see, the swp instruction exist in the BCM2708, the CPU on the Raspberry Pi SoC. Therefore, we could expect that multithreaded application ported from the PC (x86/x64) could seamlessly ported to Raspberry Pi with expectation that the synchronization primitives would work with the help of the hardware (via swp instruction). I have yet to do some tests on this. It should be on the next post on the Raspberry Pi subject.