Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABob6iqb8_bvU6CA15Cpu+JKLssM6Nfw9X0cy_Gti02ithEsSg@mail.gmail.com>
Date: Tue, 14 May 2013 01:44:12 +0200
From: Lukas Odzioba <lukas.odzioba@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: AMD GCN ISA development

2013/5/13 Dániel Bali <balijanosdaniel@...il.com>:
> -   v_add_i32     v1, vcc, 42, v1                             // 00000058:
> 4A0202AA
> -   tbuffer_store_format_x  v1, v0, s[4:7], 0 offen
> format:[BUF_DATA_FORMAT_32,BUF_NUM_FORMAT_FLOAT] // 0000005C: EBA41000
> 80010100
> -   s_endpgm                                                  // 00000064:
> BF810000
> +   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
> 80010100
> +   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
> numbers:

This sounds weird to me, can you confirm that this occurs in binary too?

> 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.

This document is linked on our ideas page, V_ADD_I32 is on page 11-67.
To better understand notation you can take a look at AMD 6900 family
ISA document.

> 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.

This sounds ok, but have in mind why we want to patch those binaries,
this will help you avoid roaming in your research.

Meanwhile I found more docs:
http://www.opengpu.net/EN/attachments/154_HiPEAC2012_OpenGPU_AMD.pdf
http://www.nada.kth.se/~tomaso/Stream2008/M6.pdf - try M*.pdf to get
other documents
http://devgurus.amd.com/thread/140503
http://www.haifux.org/lectures/267/2908_AdvancedOpenCLDebuggingAndProfiling.pdf
https://github.com/rakadam/AMD-GPU-Asm-Disasm

Last one was mentioned in qhasm-cuda paper references.

Lukas

Powered by blists - more mailing lists

Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.