Callum's Code Blog

Bug Blog: Affine Transformations

Sun, 10 Oct 2010 06:40:37 +0000

I am implementing a mouse based graph editor as part of an assignment. I am of course taking about mathematical graphs with nodes and edges, not statistical charts.

An important feature of this application is the ability to pan the canvas by shift dragging the mouse. This seems quite easy at first, since good graphics libraries can automatically map between logical coordinates (the locations of objects on the canvas), and physical coordinates (the locations of the objects on the screen).

This is done using an affine transformation, a concept from linear algebra. An affine transformation combines translation, rotation, reflection, scaling, and shear into a single operation. The affine transformation in a graphics library usually maps logical coordinates into physical coordinates.

The trick is to arrange for an affine transformation to be applied by the graphics library. As the user shift drags the mouse, the translation component of the transformation is updated to reflect the motion.

Simple.

The bug

The question though is by how much should the translation be adjusted. The obvious answer is to subtract the previous mouse position from the current position to obtain the vector [x - x0, y - y0].

However, I also want to add zooming functionality to this application. If the user zooms out, the physical coordinates will get smaller relative to the logical coordinates, and vice versa when the user zooms in. This means that when zoomed in, the canvas will pan too slow, and when zoomed out, the canvas will pan too fast.

Recall that the affine transformation maps logical coordinates into physical coordinates. Clearly the answer to my problem is to apply the inverse transformation (mapping physical coordinates to logical coordinates) to [x - x0, y - y0].

This succeeds in adjusting the scale, but the canvas jumps around, seemingly at random, as soon as I start dragging!

Why?

At this point I remembered something from linear algebra class: Affine transformations aren't linear. What does that mean? Well, a linear transformation is one where T(a + b) = T(a) + T(b) and nT(a) = T(na), where a and b are vectors, and n is a scale factor. Rotations, reflections, scaling, and shearing are linear, which is quite easy to prove.

Translation, however, is not linear. T(a - b) â� T(a) - T(b). This is also clear if you visualize it right. Imagine finding the vector from point a to point b, then adding some translation vector (which is essentially what the inverse affine transformation is doing). The resulting vector is very definitely not what you intended. Now imagine adding the same translation vector to a and b, then finding the vector between them. Much better.

I guess the lesson here is that it pays to pay attention in maths class. It really can matter whether an operation is linear or not.

Bug Blog: execing a shell

Thu, 01 Apr 2010 22:30:50 +0000

I just spent an hour tracking down a bug involving the exec syscall. I was trying to implement a "shell" function for my programming language project. Something like this:

exitcode = shell("ls -l");

On UNIX-like systems, this involves forking off a child process that will exec the command. The parent process then waits for the child to finish and returns the exit status. Simple.

However, unlike CreateProcess under Windows, the UNIX style exec syscall requires the caller to parse the command line arguments for the new image. Since I want the user of my shell function to be able to pass anything they could type on the command line, parsing the command line arguments is not a trivial matter.

The bug

Not to worry though, I can use the sh command to do the parsing for me. I simply transform the argument to the shell function into "/bin/sh -c '<command>'". Now the problem is reduced to execing /bin/sh with 2 arguments.

But it didn't work. I got mysterious errors of the form "-c: can't open <command>".

Why?

The execve syscall (the low level exec syscall on Linux) takes as one of it's parameters an array of arguments for the new image. I was passing the array ["-c", "<command>"]. Wrong!

The command line arguments array on UNIX always starts with the name under which the binary was invoked, as any C programmer will tell you. So the shell was being invoked under the name "-c" with the single argument "<command>" which it tried to interpret as a shell script. Hence the error "-c: can't open <command>". The "-c" shell couldn't run the "shell script" called "<command>".

x86-64 assembly on Linux - syscalls

Thu, 21 Jan 2010 03:56:49 +0000

There are plenty of tutorials showing how write Linux programs in x86 assembler, a good resource is http://asm.sourceforge.net. However, there is very little on 64bit x86 assembler (x86-64). x86-64 is very similar to its 32bit counterpart. The main difference is that the registers are wider and there are more of them. You might think this would make it easy to adapt 32bit code to run in 64ibt mode under Linux.

Of course, there are a few gotchas. Linux has a completely different system call ABI under 64bit mode. The syscalls have different numbers and are called in a completely different way. Depending on how your kernel was compiled though, the 32bit interface may be present and usable as well (lkml).

In ignorance of this situation, I wrote a whole lot of code making simple 32bit syscalls from 64bit mode. It worked just fine on my Ubuntu system. Then I tried it under 64bit ttyLinux, a minimalist Linux distribution. My programs crashed as soon as they hit the first syscall.

If you want your assembler programs to work reliably across different kernels and distributions, you ought to use the correct ABI.

So, how does it work? It's based on the x86-64 UNIX C ABI which goes like this: arguments 1-6 are passed in the registers RDI, RSI, RDX, RCX, R8, R9. The result comes back in the RAX register, if 64bits isn't enough the high bits are in RDX. The parameter registers plus R10 and R11 are clobbered, the rest are saved. C's int type is 32bits, C's long type is 64bits. It's all described in this document.

For the 64bit syscalls, parameter 4 is passed in R10 instead of RCX. RCX is still clobbered. The syscall number is passed in RAX, as in 32bit mode, but instead of the "int 0x80" used in 32bit mode, 64bit syscalls are made with the "syscall" instruction. The syscall numbers can be found in the Linux source code under arch/x86/include/asm/unistd_64.h.

I'll finish this off with an example:

[bits 64]

section .text
global _start
_start:                ; ELF entry point
mov rax, 1             ; sys_write
mov rdi, 1             ; STDOUT
mov rsi, message       ; buffer
mov rdx, [messageLen]  ; length of buffer
syscall

mov rax, 60            ; sys_exit
mov rdi, 0             ; 0
syscall

section .data
messageLen: dq message.end-message
message: db 'Hello World', 10
  .end:

compile with "nasm -felf64 filename" followed by "ld filename.o". No libraries needed, this code stands alone.

Happy Hacking

GTKSourceView language definition for NASM

Tue, 25 Nov 2008 03:43:41 +0000

Update 22/7/2010: high register/hex number confusion cured

Although I generally like gedit (GNOME Editor), I was disappointed to discover that it doesn't have syntax highlighting for x86 assembler. It turns out that adding a new syntax highlighter is as simple as writing a little xml file and putting it in GTKSourceView's directory. On my Ubuntu system this is /usr/share/gtksourceview-2.0/language-specs/.

Here's the file in case you're interested.

Centering a div in the window

Thu, 10 Jul 2008 04:55:21 +0000

Ever wanted to center a panel in the middle of the browser window? There's a lot of code out there that claims to do this, but it isn't standards compliant and doesn't work on all browsers. But never fear, there is an easy way to do it without any browser specific hacks.

First, you need a couple of styles:

body {
  background-color: #000000;
}

.reference {
  background-color: transparent;
  position: absolute;
  top: 50%;left: 50%;
  width: 1px;height: 1px;
}

#panel {
  position:absolute;
  left:-485px;top:-256px;
  width:970px;height:512px;
  background-color:#FFFFFF;
}

Now the html:

<div class="reference">
  <div id="panel">
    Your content here
  </div>
</div>

The reference style creates a 1px by 1px div centered in the middle of the window. Inside this div is the panel. Normally this would place the upper left hand corner of the panel in the center of the window. To correct for this, the left and top properties are set to -(width/2) and -(height/2) respectively. Since the width and height of the panel is known these can be hard coded into the styles.

Happy Hacking