Follow @Openwall on Twitter for new release announcements and other news
[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <107364D9-27C0-469B-B3A4-2C1D58461AAA@gmail.com>
Date: Wed, 8 Jul 2015 23:00:03 +0800
From: Lei Zhang <zhanglei.april@...il.com>
To: john-dev@...ts.openwall.com
Subject: Re: extend SIMD intrinsics


> On Jul 8, 2015, at 12:50 AM, Solar Designer <solar@...nwall.com> wrote:
> 
> On Tue, Jul 07, 2015 at 11:22:54PM +0800, Lei Zhang wrote:
>> On Jul 7, 2015, at 10:49 PM, Solar Designer <solar@...nwall.com> wrote:
>>> On Tue, Jul 07, 2015 at 10:37:14AM +0800, Lei Zhang wrote:
>>>> Using a union type, the pseudo-intrinsics would be written this way (for AltiVec):
>>>> 
>>>> #vadd_epi32(x, y)	(vtype)vec_add(x.v32, y.v32)
>>>> #vadd_epi64(x, y)	(vtype)vec_add(x.v64, y.v64)
>>>> 
>>>> Does the type casting here violate strict aliasing? 
>>> 
>>> I find it weird.  Why would you need it?  Instead, assign the vec_*()
>>> intrinsics outputs to .v fields.
>> 
>> You mean, in-place updating like this(?):
>> 
>> #vadd_epi32(z, x, y)	z.v32 = vec_add(x.v32, y.v32)
>> 
>> or just change the user code:
>> 
>> z.v32 = vadd_epi32(x, y)
> 
> I have no preference between these two.  I'll defer to magnum.
> 
> In DES_bs_b.c, it's the former (accepting the destination as a macro
> parameter), so maybe we should do the same elsewhere for consistency.

BTW, I think one drawback of these forms is that it's not as convenient to write nested expressions. Like
	a = b + c - d
which, with the current form, could be written as
	va = vec_sub(vec_add(vb, vc), vd)


Lei

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.