Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Date: Sun, 9 Dec 2012 03:37:37 +0400
From: Solar Designer <solar@...nwall.com>
To: john-dev@...ts.openwall.com
Subject: Re: bitslice DES on GPU

On Sun, Dec 09, 2012 at 01:31:39AM +0200, Milen Rangelov wrote:
> I don't know the exact situation well, so you are probably right. However
> you should consider that you'd have to support that binary replacement for
> both VLIW and GCN hardware (both are very different) and since it is a
> literal constant, the compiler might either decide to keep it in a hardware
> register or "embed" it in the instruction (yes, that's possible for a range
> of compile-time constants).

I am hoping/assuming that it'd be embedded as an immediate offset in a
load instruction - so, yes, it may be some range of bits inside a VLIW
or GCN instruction.  Hopefully, this range will be consecutive, although
that depends on instruction encoding of a specific native ISA.

> Sayantan wrote that this is a simple case (as
> compared to the BFI_INT patching), I tend to disagree though, I think it is
> in fact more complex.

Yes, it is more complex than the BFI_INT case.

Alexander

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.