Date: Sun, 9 Dec 2012 01:31:39 +0200 From: Milen Rangelov <gat3way@...il.com> To: john-dev@...ts.openwall.com Subject: Re: bitslice DES on GPU 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). 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. On Sun, Dec 9, 2012 at 1:22 AM, Solar Designer <solar@...nwall.com> wrote: > On Sun, Dec 09, 2012 at 01:09:34AM +0200, Milen Rangelov wrote: > > Any change in the binary would not have any effect unless you release the > > kernel and create it again (which would involve a memory transfer again). > > But that of course involves the transfer costs. > > That's fine. I'd expect such transfer costs to be relatively minor - > way lower than the savings from having the right offsets substituted > into code instead of wasting registers on them and having to use more > complicated addressing. > > Alexander > Content of type "text/html" skipped
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.