On 24.09.20 15:30, Richard Henderson wrote:
> On 9/24/20 12:56 AM, David Hildenbrand wrote:
>> I do wonder if a type for Int256 would make sense - instead of > manually
>> passing these arrays.
>
> I could do that. It does name better, I suppose, in passing. So long as
> you're happy having the guts of the type be public, and not wrapping
> everything
> like we do for Int128...
We can do that once we have hardware+compiler support for 256bit ;)
>
> Either is better than the softfloat style, which would pass 12 arguments to
> these helpers... ;-)
Indeed
>
>>> +static void shortShift256Left(uint64_t p[4], unsigned count)
>>> +{
>>> + int negcount = -count & 63;
>>
>> That's the same as "64 - count", right? (which I find easier to get)
>
> In this case, yes.
>
> Of course, more hosts have a "neg" instruction than they do a
> "subtract-from-immediate" instruction. When the shift instruction only
> examines the low N bits, the "& 63" is optimized away, so this can result in 1
> fewer instruction in the end.
>
> Which is why I almost always use this form, and it's already all over the code
> inherited from upstream.
>
>> Wow, that's a beast :)
>
> But not much worse than muladd_floats(), I'm pleased to say.
Definitely!
--
Thanks,
David / dhildenb
