[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20121208233736.GA352@openwall.com>
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.
