[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABh=JRGHObPithOv1suJOqfOjuZy77fN_22Dh+JgA=0nqn_8Lg@mail.gmail.com>
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.
