General purpose and integer registers

Full register bit 0-63 Partial register bit 0-31 Partial register bit 0-15 Partial register bit 8 – 15 Partial register bit 0-7 Callee IN OUT
RAX EAX AX AH AL 1
RBX EBX BX BH BL X
RCX ECX CX CH CL 4
RDX EDX DX DH DL 3 2
RSI ESI SI SIL 1
RDI EDI DI DIL 2
RBP EBP BP BPL X
RSP ESP SP SPL
R8 R8D R8W R8B 5
R9 R9D R9W R9B 6
R10 R10D R10W R10B
R11 R11D R11W R11B
R12 R12D R12W R12B X
R13 R13D R13W R13B X
R14 R14D R14W R14B X
R15 R15D R15W R15B X
RFlags Flags
RIP

Assembly macros!

When writing assembly code, I inevitably find myself writing the same code again and again. I don’t like that. You might think I don’t have to: I could put my code in a new subroutine and call it whenever I need whatever it is that happens whenever that code runs to happen. This would work most times, but it doesn’t work all of the times. Here’s an example:

Let’s say you have the following subroutine:

mySub1:
	pushq	%rbp
	movq	%rsp, %rbp
# DO STUFF HERE
	movq	%rbp, %rsp
	popq	%rbp
	ret

The next subroutine I write will probably have a lot of the same stuff:

mySub2:
	pushq	%rbp
	movq	%rsp, %rbp
# DO OTHER STUFF
	movq	%rbp, %rsp
	popq	%rbp
	ret

As we can see, these subroutines begin with the same two instructions, and end with the same three instructions. The problem is that I can’t really put these instructions in subroutines, because storing and restoring the base pointer has to happen in the scope of the subroutine – not outside the scope, and not in a nested scope!

Macros to the rescue!
A macro is simply a named number of instructions that is actually expanded inline wherever it is referenced. This definition is important and we’ll come back to it, but let’s look at some code:

.macro	_ENTER_FRAME
	pushq	%rbp
	movq	%rsp, %rbp
.endm

.macro	_EXIT_FRAME
	movq	%rbp, %rsp
	popq	%rbp
	ret
.endm

mySub1:
        _ENTER_FRAME
# DO STUFF HERE
        _EXIT_FRAME

mySub2:
        _ENTER_FRAME
# DO OTHER STUFF
        _EXIT_FRAME
	ret

Our code starts with two macro definitions, and they are pretty self-explanatory. The macro starts with “.macro” followed by it’s name. Then come the instructions and, finally, “.endm” denotes the end of the macro definition.
As we can see, using a macro is as simple as using its name where we want the macro to be expanded. To be clear, a macro is not subroutine. It is nothing more than a way to group a number of instructions that we want to reuse.

This is why the definition is important: a macro can contain whatever instructions we put in it. So it can also contain labels. But our code cannot contain multiples of the same label… If we use the macro only once, nothing will happen. If we use it twice, we’ll get errors!

Now that we’ve had the warning, let’s look at more things we can do with macros.

Macros can also have parameters. For example, the following code shows how to define a macro that calls printf.

.macro	write	str
	movq	$0, %rax
	movq	\str, %rdi
	call	printf
.endm

Now, instead of using these three instructions to send a line to console, we can use one:

write $MESSAGE

where message is:

MESSAGE: .string "Hello World!"

If we wanted to use more arguments, it’s easy:

.macro	write	str, arg1, arg2
# DO STUFF
.endm

All our arguments have to be prefixed by ‘\’!

If we have a lot of macros that we want to use again and again, we can put them in a separate file, say “macros.inc”. We can then include it in our code as follows:

.include "macros.inc"

Afterthoughts: Intel vs. AT&T

While I’m bound to the AT&T syntax for the foreseeable future, I have to say I would much prefer to work with the Intel syntax. I have only one reason for this, and it’s a simple one: pretty much all of the books – and I do mean all of them, not just books currently in print, e-books, etc. – use the Intel syntax. Translating what I read in my assembly books to AT&T requires some mental juggling, and I don’t always care for it.

Having said that, I do believe the AT&T syntax is the better one. That’s an unusual preference for me, because I prefer the syntaxes (and languages) that are simpler and cleaner. The Intel syntax has definitely less clutter than the AT&T syntax. However, when I’m programming assembly, I rather appreciate a syntax that is more explicit in its choices of opcodes, registers, and so on. It makes reading code just a bit easier, and what you read is just a bit less ambiguous.

As is always the case with such things, a preference for a specific syntax is just a matter of taste. Caveat lector.

How to change the wallpaper on windows with C#

The following code can be used as follows:

var screen = Screen.PrimaryScreen;
var bounds = screen.Bounds;
var workingArea = screen.WorkingArea;

var bitmap = new Bitmap(bounds.Width, bounds.Height);
using (var g = Graphics.FromImage(bitmap))
{
    g.Clear(Color.White);
    // Draw stuff... or scrap the graphics and load from a file or stream!
}
Wallpaper.Set(bitmap, Wallpaper.Style.Centered);

Continue reading “How to change the wallpaper on windows with C#”

Seakable Stream

If you’ve been programming anything that’s even a little bit interesting, you know streams. There are streams that can write, there are streams that can read, there are streams that can do both, there are streams that can seek, and there are streams that cannot. Here’s where SeakableStream comes in: if you have a stream that cannot seek and you need to be able to go back and have another look, then you can use my SeakableStream class.
Continue reading “Seakable Stream”