Openwall GNU/*/Linux - a small security-enhanced Linux distro for servers
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Mon, 13 May 2013 12:29:08 +0200
From: Dániel Bali <>
Subject: Re: AMD GCN ISA development


It's me again. I wrote a small sample program that saves the binary and
then looked at the generated isa files.
The sample kernel I made incremented each element of an array by 42. Then I
changed this value (in the kernel source) to 99 and checked the difference.
This is what (the relevant part of) the diff looked like:

-   v_add_i32     v1, vcc, 42, v1                             // 00000058:
-   tbuffer_store_format_x  v1, v0, s[4:7], 0 offen
format:[BUF_DATA_FORMAT_32,BUF_NUM_FORMAT_FLOAT] // 0000005C: EBA41000
-   s_endpgm                                                  // 00000064:
+   v_add_i32     v1, vcc, 0x00000063, v1                     // 00000058:
4A0202FF 00000063
+   tbuffer_store_format_x  v1, v0, s[4:7], 0 offen
format:[BUF_DATA_FORMAT_32,BUF_NUM_FORMAT_FLOAT] // 00000060: EBA41000
+   s_endpgm

So it looks like smaller numbers are optimized and larger numbers require a
whole dword argument after the instruction.
The instruction that increments the array's elements by 42 is 4A0202AA. The
"AA" part is what identifies the number 42. I tried it with different

+42 - 0xAA
+63 - 0xBF
+64 - 0xC0
+65 - not optimized

Then I rewrote a binary by hand, changing the 0xAA value to 0x81, which
resulted in a kernel that increments the array elements by 1. I tried
numbers below 0x80 but the results were unpredictable.

So I guess this was the easy part, but to advance I would need to find a
documentation for ISA's byte code. I also wonder whether such document
publicly exists. I checked the AMD Souther Islands architecture docs but I
didn't find much about the v_add_i32 instruction. Maybe I was looking in
the wrong place, I'll definitely look at it closer and not just Ctrl+F for
things that might be interesting.

I think from now I will work out a way to change any parts of the byte code
and take care of the changing byte code size. Unless of course someone
points out a different direction for me.



Powered by blists - more mailing lists

Your e-mail address:

Powered by Openwall GNU/*/Linux - Powered by OpenVZ