microcoded

ARM assembly on Android part 3

Mon, 14 Mar 2011 19:42:00 +0000

Before I dug into anything deeper I wanted to code a slightly larger sample and get to know some of the common instructions. I expanded the Hello World code and added a naive length function that iterates over the string and computes the number of characters between the start address and the null terminator.

Here’s the code:

.data
string:
	.asciz	"Hello, world!\n"
string2:
	.asciz	"String is %d characters\n"

.text
.global main
main:
	push		{r4, lr}
	ldr     	r4, =string
	mov     	r0, r4
	bl      	printf
	mov     	r0, r4
	bl      	length
	mov     	r0, #0
	pop		{r4, pc}
	
.global length
length:
	push		{r4, lr}
	mov 		r1, #0
	mov 		r4, #0
length_loop:
	ldr     	r3, [r0, r4]
	and		2, r3, #0x000000FF
	cmp     	r2, #0
	beq     	length_outro
	add     	r1, r1, #1
	and     	r2, r3, #0x0000FF00
	cmp     	r2, #0
	beq     	length_outro
	add     	r1, r1, #1
	and     	r2, r3, #0x00FF0000
	cmp     	r2, #0
	beq     	length_outro
	add     	r1, r1, #1
	and     	r2, r3, #0xFF000000
	cmp     	r2, #0
	beq     	length_outro
	add     	r1, r1, #1
	add     	r4, r4, #4 
	b       	length_loop
length_outro:
	ldr     	r0, =string2
	bl      	printf
	pop     	{r4, pc}

The main function is very similar to the previous example with mainly two differences: we load the address of string in r4 before moving it over to r0 as an argument to the function calls and we also have a second function call.

Between function calls only registers r4-r11 are guaranteed to be preserved. r0-r3 might not have the same values as when the function was called which is why we need to move the address of string into r0 before both function calls. The initial ldr instruction is a pseudo instruction and does more work under the hood. Because of that I chose to save the result in r4 and simply move it to r0 before every function call to potentially save a cycle or two.

The first call is to printf which, like the previous example, prints our string. The second call is to our new label length. Note that I use label and function interchangeably. Here we pass in as an argument the address of the string, just like the printf call.

First thing we do in length is to push r4 and lr to the stack. In order to follow the procedure calling standard for ARM we need to make sure r4 will have the same value when our function returns as when it was called. Since we’ll be using the register we need to save the contents.

Next we move 0 into r1 which will be used to keep track of the length of the string. r4 is also loaded with 0 and this register will be used as an offset to read from the memory where we have our string. We want to start reading from the start so we begin with offset 0.

Next we have the length_loop label which denotes the start of the loop. Every iteration we load the next 4 bytes of the string and test each byte individually by isolating the byte and checking if it’s 0. For every byte that isn’t equal to 0 we increment the value in r1. When a zero byte is found, we jump to the label length_outro and out of the loop.

Now we simply load the second string into r0 to pass in as an argument to printf with the second argument (the length of the string) already present in r1. Finally we pop the saved registers from the stack which returns from our function.

ARM assembly on Android part 2

Fri, 11 Mar 2011 23:08:41 +0000

Previously I showed how I set everything up in order to run asm code on android. It was far from exciting but I would have loved to have that post when I started. In this part I show my simple Hello World code. First, have a look at the following links:

I based my code on the Hello World example and use calls to printf rather than system calls. Nevertheless, the primer posts are a very good introduction to the architecture.

Let’s get on with it, the contents of the hello.s file:

.data
string:
	.asciz  "Hello, world!\n"

.text
.global main
main:
	push		{fp, lr}
	ldr  		r0, =string
	bl   		printf
	mov		r0, #0
	pop		{fp, pc}

First line we have the assembler directive .data which specifies the beginning of the data section. Here we put all our initialized data. The second line we have a label string which is needed to grab the data from underneath. Without the label the assembler wouldn’t know where the string would be located in memory. The third line contains the .asciz directive together with our string. This directive tells the assembler the type of the data (ascii in this case) and makes sure to add a null terminator at the end, just a 0 really.

The .text directive specifies the beginning of a new section that holds all the code. The following .global directive makes the symbol main visible externally so other code (like the OS) can call it.

When some code calls our now externally visible label main it will put the program counter at the line following the label and the execution will start from there. This is where the meat of the code is.

push {fp, lr}

{fp, lr} is a list of registers containing fp and lr. The fp register is the frame pointer and lr is the link register. The link register holds the next instruction in the code that called our main label and this is were we need to return when we’re done. If we happen to call a function from our code, the call instruction will make sure to set the link register so the new function knows where to return. Because of this we don’t want the contents of this register to be lost so we push it onto the stack. In order to keep to the standard and to get optimal performance we need to keep the stack aligned on an 8 byte boundary. Pushing only the link register would cause it to advance 4 bytes so we need to push 4 more. This is the reason the frame pointer is pushed in this case, but any other register would have worked. You can read more about why this is done here.

ldr r0, =string

The ldr instruction is actually a pseudo instruction which resolves to a load relative to the program counter. The address of the string is placed (together with others if present) in a literal pool. The offset from the program counter is calculated and this is used to load that address into r0.

bl printf

When calling a function the arguments are passed in the registers r0 to r3. If more than 4 arguments are passed the rest will have to be placed on the stack. The previous line in the code loaded the address of our string into r0, which will serve as the only argument passed to printf. The bl instruction is a branch with link, meaning that we jump to the first line of the code for the printf function and at the same time we store the address of the line _after_ our bl printf in the link register. This is the reason why we had to push lr on the stack at the beginning of our code, otherwise its value would have been lost now.

mov r0, #0

When printf returns it will jump to this line. This is fairly simple, we move the value 0 into the register r0. When a function returns its return value needs to be placed in r0. We have prepared our register and the next line handles the actual jump.

pop {fp, pc}

At the beginning of our function we pushed two registers onto the stack: the frame pointer that served as a dummy register to align the stack and the link register. Since we want to return from our function we want the program counter to be set to the value of the link register when our function was called. The pop handles this by specifying the pc register as the second destination in the register list causing the saved value from the link register to be loaded directly into the register that’s used as the program counter.

Next up, some more code.

ARM assembly on Android

Fri, 11 Mar 2011 19:38:33 +0000

Having recently bought a Nexus S phone I immediately started looking into how one could play around with some assembly coding on it. Google Android apps usually use the Android SDK which is based on Java. There’s also a native development kit (NDK) which supports C/C++. The process for developing for this platform is not as clear and easy as I had expected from Google.

The workflow (as far as I’ve understood it) is either you’re on linux or you use Eclipse and Cygwin. You code in java and (optionally) create separate native libraries with C/C++ code which you call from your main app. This doesn’t interest me. And I definitely don’t want to install Eclipse and Cygwin. I simply want to code in assembly and never mind the rest. This wasn’t as easy and straight forward to do as I expected but it’s possible.

First thing’s first, there’s a few things to download:

Android SDK: needed for the emulator
Android NDK: this has all the libraries and the gcc family of apps for arm
JDK: the java development kit is required by the emulator

I have an android folder in my user folder. I put everything related to android in it. I installed the SDK and the NDK in there and created a new sub folder code which gives my the following hierarchy:

/android
/android/android-ndk-r5b
/android/android-sdk-windows
/android/code

If you follow this post and set things up like this, at this point it’s time to create an android virtual device for the emulator. There are many tutorial/articles/posts about how this is done so I won’t repeat it. If no devices can be created it’s probably because you’ll need to download some packages with the preferred android platform versions first. This can be done from the SDK manager found in the SDK folder.

In the code folder I have my hello.s file containing a small assembly application. The contents I’ll explain in the next post since I’d like to keep them short. Together with the source file I have a couple of batch files to make my life easier.

compile.bat

"../android-ndk-r5b/toolchains/arm-eabi-4.4.0/prebuilt/windows/bin/arm-eabi-gcc.exe" -I"../android-ndk-r5b/platforms/android-8/arch-arm/usr/include" -L"../android-ndk-r5b/platforms/android-8/arch-arm/usr/lib" "../android-ndk-r5b/platforms/android-8/arch-arm/usr/lib/crtbegin_dynamic.o" -fno-short-enums -nostdlib -lc -ldl -Wl,-dynamic-linker=/system/bin/linker -o hello hello.s

The line above calls the gcc compiler for the embedded arm ABI. It provides an additional include directory for the NDK includes and an additional library directory for the NDK libraries. Moreover, the dynamic library for the android crt is added.

Some included libraries seem to have been compiled with short enums so the -fno-short-enums flag simply disables them and gets rid of the compiler error. The -nostdlib flag is needed because android has a custom version of libc called bionic which we need to use instead of the regular system startup libraries.

Next, I needed to link in libc and libdl to make my code work. This will of course vary depending on what the code needs. The -Wl flag passes the following options to the linker, which simply tells it where the dynamic linker is located.

It took only 5 (ish) hours to get that stuff above working.

push.bat

"../android-sdk-windows/platform-tools/adb.exe" push hello data/misc/hello

"../android-sdk-windows/platform-tools/adb.exe" shell chmod 777 data/misc/hello

The first line calls the android debug bridge tool and calls the push command. This uploads the hello file to a specified location on the device. Or in our case the emulator. The second line calls the shell command and runs chmod on the file to make sure it’s executable.

run.bat

"../android-sdk-windows/platform-tools/adb.exe" shell data/misc/hello

This final batch file uses the adb tool to execute the file we previously uploaded to the device.

That should be it! Write a source file in beautiful arm assembly, run compile.bat to compile the file, run push.bat to upload the executable to the device and then run it. Next up, some actual coding.

OBJ triangulator

Sat, 05 Feb 2011 20:04:37 +0000

I’ve spent a lot of time on implementing my master’s thesis recently and I’ve reached a point where I need to test the results on different geometry. There are great free models to be found on the internet but unfortunately most of them are quad based. My OBJ loader doesn’t support loading quads, only triangles. Instead of adding this, I decided to do something else.

Lately I’ve started to get into Lisp and this was a great opportunity to actually do something rather than just play around. I wrote a small utility that grabs an OBJ file and converts the faces to triangles. I’m still learning to find my way around the language so i’m pretty sure I’m solving things the wrong way. Or perhaps less than optimal rather than “wrong”. But it’s been great fun so far and I’m already looking to find a new project to write.

Source code can be found here: objtri.

Heightmap generation

Tue, 15 Jun 2010 00:00:00 +0100

I’ve been playing around a bit with random number generators and heightmaps. My goal is at some point to procedurally generate as much of a limited landscape as possible. I haven’t done much work as I’m currently setting up the renderer at the same time too. But I did make some progress with the heightmaps.

I currently have three different algorithms that generate the heightmaps, with some additions and hybrids planned for later. The fault formation algorithm is the one I’m most pleased with so far. It creates pretty varied generations that end up looking pretty good in 3D.

The algorithm for the above results is as follows:

// Allocate a buffer for the height map.
// Iterate a pre-define number of times over this array and...
//        Generate a random line (two points) in the height map.
//        Calculate the height modifier for this iteration.
//        For all the points in the height map on ONE side of the line
//                Add the modifier value to the height.
//        (optional) Filter the height map.
// (optional) Apply a final filter pass.
// Normalize height map.

I store the heightmap as an array of floats. I don’t care much about memory at the moment though so it might be worth thinking about other formats. The height modifier is changed every fault iteration as

modifier = max - ( ( iteration * ( max - min ) ) / numIterations )

in order to gradually smooth it out. This won’t be enough though, hence the filtering. For filtering I use a simple FIR filter applied to every band of the heightmap in all four directions. For the random lines I use a Mersenne Twister implementation that has a great distribution and gives some kick-ass random numbers.

The perlin results I’m not so proud over, but that’s mainly my fault. I still need to find some proper values for the seeds. The implementation is fairly naive and at core uses a simple pseudo random number generator instead of proper lookup tables. The algorithm goes as follows:

// Allocate a buffer for the height map.
// For every element of the array...
//        For every octave...
//                Modify the frequency by a pre-defined modifier.
//                For the current (floating) point and its 3 discreet neighbors in the other quadrants...
//                        Sample the 8 points around the current point and average the result.
//                Use the fractions of the coordinates of the (floating) point to bilinearly interpolate the four values.
//                Amplify the result of the interpolation by the current amplitude.
//                Accumulate the result.
//                Modify the amplitude by a pre-defined value.
//        Save the final value as the height at the current element in the heightmap.
// Normalize height map.

When “sampling” the 8 points the algorithm actually generates 8 pseudo random numbers with the given coordinates. Since the coordinates are effectively the seed, the result will always be the same and we don’t need to store lookup tables. The interpolation is a bilinear cosine interpolation. I tested linear and cubic too but in the end stuck with cosine. I don’t believe I have a reason for that though.

The plasma algorithm is a vanilla midpoint displacement implementation. I’m not going to bother writing it down since I’m not doing anything special, other than applying some heavy filtering to smoothen out the results.

At the moment the results are OK but I’m not terribly impressed. The generated meshes look tame and I’d like to expand them a bit more. Perhaps blend between different heightmaps or otherwise use some sort of heuristics to mix different types. I can imagine a low octave perlin map could be used to blend between other heightmaps to create cliffs and the like. More on this later…

Overloading macros

Sun, 02 May 2010 21:52:00 +0100

How do I overload macros you ask? Well, you can’t! But that would be a short post so I’ll show something else you can do. Imagine working with a code base that uses a function call for a specific purpose, for instance AllocateMemory( Heap h, int size ) is used to do all your allocations. One day, you decide that you want to do some memory tracking and would like to print out where all the allocations happen from. Since you don’t want to change how this function is called in your entire code base, you go ahead and modify the actual function to do something like this:

void* AllocateMemory( Heap h, int size ) {
#if defined( MEMORY_TRACKING )
    printf( "%s:%d: Alloc %d bytes on heap %d\n", __FILE__, __LINE__, size, h );
#endif

    // do normal alloc here
}

This would work just fine and it would require only a quick modification to one function and a define to be set in order to get this primitive memory tracking working. Only it wouldn’t give you much useful information since __FILE__ and __LINE__ will always give you the same values. When these two tokens are replaced by the preprocessor, it will aways be in the AllocateMemory function, probably somewhere in a memory manager class. It won’t tell you where the allocation comes from. Ideally what you’d want is for the preprocessor to replace the call to AllocateMemory with a call that contains the __FILE__ and __LINE__ variables as arguments. You don’t want to change every instance of AllocateMemory in the entire code, so you decide to use macros.

#if defined( MEMORY_TRACKING )
void* _AllocateMemory( Heap h, int size, const char* file, int line );

#define AllocateMemory( h, size ) \
    _AllocateMemory( h, size, __FILE__, __LINE__ );

#else
void* AllocateMemory( Heap h, int size );
#endif

There you go. When the tracking define is used, rename the core function and give it its new signature which includes the file name and the line number. Define a macro with the function’s original name which catches the calls and forwards them to the function, appending the preprocessor variables as arguments. Since the macro will be expanded in place, __FILE__ and __LINE__ will correctly contain the filename and line number of the AllocateMemory() call. Now to the actual point. What if the original AllocateMemory function was overloaded? What if in addition to the version above there’s a second version with the signature AllocateMemory( int alignment, int size )? This would obviously work when calling the two functions but replacing them with a macro will cause compile errors since macros can’t be overloaded. Turns out there’s an easy way around this.

#if defined( MEMORY_TRACKING )
void* _AllocateMemory( Heap h, int size, const char* file, int line );
void* _AllocateMemory( int alignment, int size, const char* file, int line );

#define AllocateMemory( ... ) \
    _AllocateMemory( __VA_ARGS__, __FILE__, __LINE__ );

#else
void* AllocateMemory( Heap h, int size );
void* AllocateMemory( int alignment, int size );
#endif

Above we replaced the tracking macro with a variadic one. This uses the ellipsis to indicate that the macro can receive zero or more arguments as input. The __VA_ARGS__ variable expands to the sequence of symbols that were passed in between the parentheses of the above macro. Since these arguments get inserted just like you’d have typed them, the _AllocateMemory() function can have any signature and it would compile correctly.

Not really overloaded macros, but it gets things done. The example in this post was off the top of my head. For a memory tracking system it’s worth it to spend the time and write some solid code. You won’t regret it when the leaks and corruptions start showing up.

I just remembered I never put up the Airborn teaser here. So...

Sat, 24 Oct 2009 00:00:00 +0100

I just remembered I never put up the Airborn teaser here. So here goes… The great soundtrack is made by the awesome Ian Dorsch.

Airborn

Sun, 12 Oct 2008 00:00:00 +0100

I’ve been really busy lately. When I’m not working late I’m always coding something in the evenings. I’ve started to learn quite a bit about the Cell processor, since the beautiful PS3 devkits are idle in the office after work, and I’ve even started to learn some UnrealScript.

I don’t know why but I’ve never really been into modding. I’ve always wanted to code my games from scratch but I always failed to finish projects either because it was too much work to code the engine before the game or because I didn’t have the assets I needed for my game. To be fair I never really attempted to make any FPS games or the like, but still. You don’t really have those problems when making mods, depending on what kind of mod you’re making of course.

Recently I started helping out some friends with a mod they’ve started. Unfortunately they are all artists and not programmers so I thought I could give them a hand. They are all extremely talentful and the mod is already looking great. I just started a week or so ago so there’s not much to show yet but we might have a video or two to show very soon. The mod is called Airborn and you can read more about it at our Mod DB page.

Video

Mon, 26 May 2008 00:00:00 +0100

Video

Sun, 13 Jan 2008 00:00:00 +0000

Signed angle between two 2d vectors

Sun, 06 Jan 2008 00:00:00 +0000

So I’m sitting at my computer and writing on some fun new game in XNA and I need to play around with some angles for rotating some sprites. Right now I have a ship which moves around a world. It works very well and it’s pretty cute, but need to make it more badass so I want to put a cannon on it. The cannon should be able to rotate all 360 degrees because I want to be able to shoot with my ship in all directions. Moreover, I also want to rotate the cannon with the mouse. For this, I would need the signed angle between the Up-vector, which was the initial direction for my cannon (and is also 0 radians in XNA) and the vector going from the center of my ship towards the mouse pointer.

It’s pretty easy to get the signed angle but if you’re not familiar with trigonometry or just haven’t needed this stuff before, it could be kind of hard to get what you need.

protected float signedAngle(Vector2 v1, Vector2 v2)
{
      float perpDot = v1.X * v2.Y – v1.Y * v2.X;
 
      return (float)Math.Atan2(perpDot, Vector2.Dot(v1, v2));
}

Right, so you obviously need two vectors and the result will be the angle between those two. First you need to find out the perpendicular dot product between the two. Doing this is pretty easy as you can see from the first line in the method. Second, you need to use atan2 to get the signed angle and just send the result from the perp dot product and the return from the dot product and out comes the angle. As I’m using XNA I jumped over the dot product calculation and use the one coming with the Vector2 class.

For my problem above, the first vector (v1) is the Up-vector which in XNA would be

Vector2 v1 = new Vector2(0, -1);

The second vector (v2) is the vector going from the center of my ship towards the position of the mouse cursor. Remember that the ship’s coordinates need to be in the same space as the mouse’s coordinates. I usually keep my mouse in screen space and my ship in world space so I need to convert one of those.

Vector2 v1 = new Vector2(0, -1);
Vector2 v2 = Camera.getWorldPos(mousePos) – p1.PlayerShip.Position;
float angle = signedAngle(v1, v2);

And there we go, we now have the signed angle. Hope it was helpful in anyway.