[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f4bd00b437de0873dd4974aca79abe39@smtp.hushmail.com>
Date: Thu, 02 Apr 2015 18:36:16 +0200
From: magnum <john.magnum@...hmail.com>
To: john-dev@...ts.openwall.com
Subject: Re: New SIMD generations, code layout
On 2015-04-02 18:05, magnum wrote:
> On 2015-04-02 17:47, Lei Zhang wrote:
>> BTW, I have a question on how the lookup table is constructed. In
>> kUsedBytesTable, from my observation, each subarray corresponds to a
>> SIMD vector and those vectors are consecutively shifted left by one
>> byte in order. But in the lower middle of the table, I find a "jump"
>> that breaks my observation:
>>
>> // for SSE
>> static const __aligned_simd uint32_t kUsedBytesTable[][4] = {
>> ...
>> { 0x00000000, 0x00000000, 0xFF000000, 0xFFFFFFFF },
>> { 0x00000000, 0x00000000, 0x00000000, 0xFFFFFF00 },
>> ...
>> };
>>
>> The lower subarray is supposed to be shifted left by one bytes from
>> the upper subarray, but actually it's shifted left by two bytes. I
>> don't know if this is a mistyping or something intentionally done.
>> Could you give me some explanation?
>
> I agree it looks like a bug and I can't see any reason it would be
> intended. OTOH it's strange that the Test Suite hasn't catched it (it
> should test all lengths - I guess it does not). I will investigate.
I did some tests but se no difference (and no problem) with this bug
fixed or not. I'm yet to prove this, but I guess what happens is we're
not masking the byte right after the data but this byte is overwritten
with 0x80 anyway. So the bug never surfaces.
magnum
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.
